Een hete aardappel: Beveiligingsteams hebben deze week met twee afzonderlijke noodsituaties te maken, en beide raken de fundamenten van het web. De eerste is een certificaatautoriteit die privésleutels leverde die iedereen kon raden. De tweede is een paar kritieke PHP-kwetsbaarheden die lekten voordat er patches waren. Browsers losten het certificaatprobleem binnen enkele uren op. Alles wat geen browser is — van Linux-servers tot Docker-images en IoT-apparaten — vereist dat iemand inlogt en bijwerkt.
Acht intermediate-certificaten uitgegeven door de in India gevestigde certificaatautoriteit eMudhra bleken privésleutels te bevatten die zo zwak waren dat ze uit de certificaten zelf berekend konden worden. Die certificaten waren gekoppeld aan rootcertificaten die vertrouwd worden door Chrome, Firefox, Safari en Windows, evenals door besturingssystemen en talloze software-truststores. Iedereen die een van die sleutels in bezit had, kon een geldig certificaat uitgeven voor elk domein en dat gebruiken om die site te imiteren, of om het verkeer ervan te onderscheppen of te wijzigen.
Een correct gegenereerde P-384-sleutel bevat ongeveer 384 bits entropie. De sleutels van eMudhra bevatten tussen de 3 en 8 bits, en een daarvan was simpelweg het getal 4. Het terugvinden van alle acht vereist het testen van maximaal 256 waarden. eMudhra gaf de schuld aan een scriptfout tijdens het genereren van de sleutels, die daarna per vergissing werden gebruikt. Dat betekent dat de sleutels ongeveer 18 maanden blootgesteld waren voordat een onderzoeker deze maand het probleem meldde. Het bedrijf zegt dat de meeste certificaten nooit in productie zijn gegaan en dat het geen bewijs van misbruik heeft gevonden.
Browsers pakten het snel aan. Chrome en Firefox blokkeerden de sleutels binnen enkele uren via hun remote revocation-lijsten, zonder update of herstart, en Apple en Microsoft volgden op 20 oktober.
Het grotere probleem is alles wat geen browser is. Servers, containers, command-line tools en embedded apparaten vertrouwen vaak op een statische, meegeleverde lijst van vertrouwde roots en controleren nooit op intrekking. Go, Python’s certifi, curl, Node.js en de meeste grote Linux-distributies hebben fixes uitgebracht, terwijl Java, Bun en FreeBSD op het moment van schrijven nog in afwachting waren.
“Dit wordt een enorme opruimactie, groter dan Heartbleed,” zei Filippo Valsorda, beheerder van de Go-cryptografielibrary, tegen Ars Technica. Een aanval vereist nog steeds dat je tussen een gebruiker en een server zit, wat op een gedeeld netwerk gemakkelijk is.
Een tweede grote noodsituatie deze week komt van PHP. Omdat PHP bijna 70% van alle websites aandrijft (inclusief TechSpot), is de potentiële impact enorm. Websites op basis van WordPress, Drupal, MediaWiki en meer zijn allemaal getroffen. Het PHP-team bracht noodpatches uit voor twee kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619, gezamenlijk PHP2Shell genoemd en beoordeeld met ernst 9,2 van de 10.
Beide vloeien voort uit het feit dat PHP het geheugen in een gecorrumpeerde staat achterlaat wanneer een verzoek abnormaal eindigt, wat een aanvaller kan omzetten in code-executie of kan gebruiken om gevoelige gegevens zoals wachtwoorden en API-sleutels uit het servergeheugen te lezen. Omdat de bug in de PHP-runtime zit, is een site kwetsbaar, zelfs als de eigen code veilig is.
De kwetsbaarheden werden ontdekt door Wiz, Calif en OpenAI. Wiz zegt dat elke PHP-release van het afgelopen decennium door minstens één van hen is getroffen, en dat AI-tools zijn wat de complexe exploit-keten praktisch maakbaar maakten. Dat suggereert dat bugs die ooit als te moeilijk om te misbruiken werden beschouwd, mogelijk niet langer veilig genegeerd kunnen worden.
De fixes kwamen er onder grote druk nadat details op 20 oktober uitlekten, vóór de geplande openbaarmaking. PHP ging onmiddellijk over tot patchen, terwijl de CTO van Cloudflare meldde dat vroege aanvallen opdoken nog voordat patches beschikbaar waren.
Serverbeheerders moeten zo snel mogelijk overstappen op PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Servers die Apache met mod_php draaien lopen het grootste risico, omdat één enkele niet-geauthenticeerde aanvraag de aanval kan veroorzaken voordat enige applicatiecode draait. De FBI, NSA en het Britse National Cyber Security Centre hebben organisaties geadviseerd onmiddellijk te patchen of PHP-systemen offline te halen totdat dit mogelijk is.
