De muur tussen huurders had een scheur
De stille belofte van elke cloudserver en elke virtuele private server is scheiding. Uw machine en die van de vreemde die dezelfde aanbieder betaalt draaien op dezelfde fysieke hardware, en een laag genaamd KVM, ingebouwd in de Linux-kernel, houdt ze uit elkaar. Januscape, geregistreerd als CVE-2026-53359, is een scheur in die muur. Het is een race conditie in de manier waarop KVM shadow page tables beheert, de interne kaart die het geheugen van een gastmachine naar echt geheugen vertaalt. Door het lek kan de host een van die vermeldingen aan het verkeerde gastframe koppelen, een frame-nummer- en typeverwarring die, zorgvuldig gestuurd, een vijandige virtuele machine de host in het toewijzen van door de aanvaller gekozen geheugen laat duwen. Dat is een uitbraak van gast naar host: de huurder klimt uit zijn doos op de vloer die iedereen deelt.
Wat het ernstig maakt is het bereik. Het lek zit in code die Intel- en AMD-processoren gemeen hebben, dus het treedt op bij VMX en EPT aan de ene en SVM en NPT aan de andere kant. Het werd in 2010 ingevoerd en lag zestien jaar sluimerend, wat betekent dat vrijwel elke in die periode uitgebrachte Linux-kernel het draagt. Het werd op 6 juli op de openbare oss-security-lijst bekendgemaakt, op 16 juni upstream verholpen, en de herstelde stabiele kernels, de versies 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 en 5.10.260, kwamen pas op 4 juli.
Waarom we hebben gepatcht nu twee antwoorden heeft
Het ongewone gevaar hier is niet het lek, het is de vorm van het herstel. Januscape sluiten vergt twee gekoppelde upstream-commits, niet een: de uitbraakoplossing met CVE-2026-53359 en een begeleidende frame-nummer-oplossing met CVE-2026-46113. Past men alleen de eerste toe, die met de pakkende naam, dan blijft de deur op een kier. Een beheerder die de opvallende melding las, die ene patch doorvoerde en het ticket sloot, heeft het redelijke gedaan en is nog steeds blootgesteld. Daarom beslecht een routinematige zin, we hebben gepatcht, de zaak bij dit lek niet meer.
Voor een eigenaar is de blootstelling zelden het eigen serverrek. Het is de aanbieder onder uw leveranciers: de VPS-host die uw website draait, de private cloud die uw bedrijfssoftware draait, het beheerde platform dat uw data draait. In Nederland is het NCSC het meldkanaal en de NIS2 legt dezelfde verwachting op: u blijft verantwoordelijk voor de beveiliging van diensten die namens u worden geleverd. Een hypervisoruitbraak is precies het soort falen van gedeelde infrastructuur waarvoor die regels zijn geschreven, want een ongepatchte host kan de scheiding tenietdoen waarvoor duizend klanten betaalden.
De vraag voor uw hostingaanbieder deze week
Voor de meeste eigenaren is dit geen kernel-compileertaak, het is een inkoopvraag die helder gesteld wordt. Leg degene die uw virtuele machines draait, of dat nu een VPS-host, een intern private-cloudteam of een beheerde platformaanbieder is, drie dingen voor: draait de hostkernel nu op een herstelde stabiele versie of een live patch; bevat die oplossing beide commits, de uitbraakoplossing en zijn begeleider; en wanneer kwam die. Er is geen configuratieschakelaar die dit veilig maakt. Een gepatchte kernel met herstart, of een live patch zonder, is het enige volledige antwoord, en tot dat op zijn plaats is moet elke multi-huurderhost als bereikbaar vanaf een vijandige buur worden behandeld.
De praktische verschuiving is klein maar echt. De huurder naast u, een naam die u nooit zult kennen, ging deze maand van een abstracte zorg naar een regel in uw dreigingsmodel. De eigenaren die dat omzetten in een concreet schriftelijk antwoord van hun aanbieder, in plaats van een comfortabele aanname, zijn degenen die niet zullen gissen als dit lek ooit in een echte inbraak wordt geketend.
Lees hierna: CitrixBleed is terug, binnen een dag misbruikt | Een vervalst token opent elke pc die de tool beheert
