PHP2Shell: het PHP-lek van 21 oktober uitgelegd

Hoe het PHP-lek aan het licht kwam

Het begon niet pas woensdag, maar al de avond ervoor. Op 20 oktober om 15:20 uur UTC dook er een Hacker News-post op die twee aankomende PHP RCE-meldingen aankondigde. RCE staat voor remote code execution: een aanvaller voert dan op afstand eigen code uit op jouw server.

Woensdag 21 oktober kregen websites wereldwijd die PHP gebruiken het dringende advies om uit voorzorg offline te gaan vanwege de kwetsbaarheden. Voor technische teams betekende dat ineens keuzes maken onder tijdsdruk, nog zonder volledig beeld van het probleem. Later die middag, om 15:55 uur, rolde PHP de patch uit. PHP liet weten dat elke site die webverzoeken afhandelt risico heeft gelopen en riep iedereen op zo snel mogelijk te updaten. Sansec bevestigde diezelfde dag dat er fixes uitkwamen voor twee kritieke RCE-bugs. Binnen een paar uur ging het dus van een eerste tip tot een wereldwijd advies.

Waarom PHP2Shell zo een hoog risico vormde

Dat dit lek zoveel impact had, komt deels door de schaal van PHP: de taal draait achter bijna 70% van alle websites, meldt Cloudflare. Dat is niet een select groepje nichesites, maar een flink deel van het internet zoals we dat kennen.

PHP zelf vond twee kritieke fouten, allebei gemarkeerd met de hoogste risicoscore die security-experts hanteren: CVSS v4.0 9,2. Een score van 9,2 van de 10 is geen kleine bug, maar een zwaar securityprobleem. Beveiligingsonderzoekers noemden de bevindingen een van de ernstigste kwetsbaarheden ooit in PHP, mogelijk zelfs in de geschiedenis van software. Omdat beide lekken een 9,2 scoren, kon je er simpelweg niet omheen. Voor een digital lead die net een nieuw platform gelanceerd heeft is dat precies het soort bericht waar je niet op zit te wachten.

Wat de twee lekken technisch deden

Onder de motorkap gebruikten beide lekken dezelfde zwakte: PHP verwerkte gegevens die niet klopten. Dat opende de deur voor aanvallers om een inlogsysteem te omzeilen en eigen code op de server uit te voeren.

Het eerste lek ontstond bij geheugentekort. Had PHP niet genoeg geheugen meer, dan stopte het soms halverwege met het klaarzetten van gegevens voor een verzoek. Bij het opruimen daarna dacht PHP alsnog dat alles in orde was en werkte het verder met kapotte gegevens die een aanvaller kon misbruiken.

Het tweede lek zat in gegevens die blijven hangen. Een PHP-worker handelt meestal meerdere verzoeken na elkaar af en soms bleef na zo’n verzoek een verwijzing naar oude gegevens bestaan. Bij het volgende verzoek kon PHP die verouderde verwijzing per ongeluk gebruiken, nog voordat alles opnieuw was ingesteld. Beide routes klinken technisch, maar het resultaat was hetzelfde: een server die deed wat een aanvaller wilde, niet wat de eigenaar had bedacht.

Welke grote organisaties stillagen

De gevolgen van deze twee lekken waren niet abstract. In Nederland gingen DigiD, MijnOverheid en de Tweede Kamer tijdelijk plat door het PHP-lek, schreef tpo.nl. Ook RTL Nieuws, het RIVM en de ANWB hoorden bij de grote organisaties die geraakt werden, aldus RTV Focus Zwolle.

Zelfs het Nationaal Cyber Security Centrum haalde uit voorzorg de eigen website, NCSC.NL, tijdelijk offline, meldde Dutch IT Leaders. Als de instantie die andere partijen adviseert over cybersecurity zelf voorzichtig is, weet je dat het menens is. Een vergelijkbare golf zag je eerder al bij Odido, Basic-Fit en ChipSoft, waar andere kwetsbaarheden grote organisaties raakten. Telkens blijkt dat techniek die jaren ongemoeid blijft, op een dag toch een zwakke plek laat zien.

Wat WIZ ontdekte bij WordPress-sites

Securitybedrijf WIZ ging na wat deze twee lekken in de praktijk konden losmaken. Bij WordPress-installaties slaagde WIZ erin om wachtwoorden, tokens en API-keys te bemachtigen. Dat zijn precies de gegevens waarmee een aanvaller verder kan, zonder dat jij het meteen merkt.

Volgens WIZ gaan de onderliggende fouten terug tot PHP 5.4. WIZ geeft zelf aan dat updaten naar een nieuwe PHP-versie de enige oplossing is. Draait jouw site nog op een oude PHP-versie met WordPress erbovenop, dan is dit precies het soort risico waar je niet omheen kunt.

Wat je nu moet doen om te updaten

Updaten is dan ook de logische volgende stap. Controleer of je PHP-versie nog ondersteund wordt en zet de patch zo snel mogelijk door op je server.

Zelf zet ik zo’n update het liefst niet meteen live, maar probeer ik hem eerst uit op een aparte omgeving, zodat de rest van het platform blijft werken zoals het hoort. Twijfel je of dit goed geregeld is op jouw platform? Dan is dit een goed moment om ook te kijken naar de upgrade naar PHP 8, zodat je niet nog een keer met een verouderde basis blijft zitten.

Wat dit lek betekent voor de toekomst

Dit soort incidenten gaat niet vanzelf minder worden. Met de komst van AI zullen we dit soort kwetsbaarheden ongetwijfeld vaker zien, misschien niet meer in PHP maar morgen in Java. Als developer maakt me dat kritischer op wat AI oplevert, niet minder.

Juist daarom is doorontwikkeling na livegang net zo belangrijk als de eerste bouw. Een digitaal product dat vandaag veilig is, moet dat ook over een jaar nog zijn. Dat vraagt om een team dat niet verdwijnt zodra een project live staat, maar blijft meekijken naar wat er technisch verandert.