PHP2Shell: Twee ongepatchte kritieke PHP RCE-zwakheden (CVSS 9,2) ontketenen dringende beveiligingswaarschuwing

Dit verhaal ontwikkelt zich en is geschreven voordat de geplande PHP-release van 14:00 UTC op 21 oktober is uitgekomen. Zodra de release is uitgebracht, worden de hieronder genoemde getroffen en herstelde versies bevestigd door het officiële advies.

PHP zal vandaag om 14:00 UTC, op 21 oktober, een tussentijdse beveiligingsrelease uitbrengen voor twee kritieke kwetsbaarheden die het beveiligingsteam heeft beoordeeld met een 9,2 op de CVSS v4.0-schaal, maar niet heeft omschreven.

Beveiligingsonderzoekers van watchTowr zeggen dat de twee fouten remote code execution mogelijk maken. Alleen de vier ondersteunde PHP-branches, 8.2 tot en met 8.5, kunnen de fix ontvangen, en er zijn tot nu toe geen exploitatiemeldingen geweest.

De voorafgaande kennisgeving volgde op een lek. Op 20 oktober zei een bericht op HN dat er twee PHP remote code execution-kwetsbaarheden zouden worden onthuld op donderdag 22 oktober, beoordeeld als CVSS 10.0 en die versies vanaf PHP 5 zouden treffen. De poster zei dat ze “geen bewijs hebben behalve ‘source: trust me, bro'”.

watchTowr plaatste daarna op X dat de gelekte informatie echt was, dat de twee fouten onder embargo stonden, dat iedereen tot donderdag moest wachten en dat het voorlopig niets meer kon delen.

PHP publiceerde die avond om 19:33 UTC haar kennisgeving, met de release gepland voor woensdag, een dag eerder dan de datum die watchTowr noemde. In de kennisgeving staat dat PHP eerder kan uitbrengen “mocht informatie over een van beide kwetsbaarheden openbaar worden, of mocht er bewijs van actieve exploitatie in het wild verschijnen.”

Het lek vermeldde het bestaan van de fouten, een score, een datum en twee CVE-identifiers, maar niet hoe de fouten werken. De CVSS 10.0-waarde komt uit het lek. PHP’s beoordeling is 9,2 op versie 4.0 van de schaal.

De identifiers die onderzoekers gebruiken, CVE-2026-109618 en CVE-2026-109619, stonden ook in het gelekte bericht. PHP’s kennisgeving noemt ze niet. De bewering dat elke versie sinds PHP 5 getroffen is, is eveneens onbevestigd: watchTowr’s eigen FAQ over de fouten zegt dat de reikwijdte “niet is bevestigd door een officieel leveranciersadvies” en dat er geen vereiste configuratie of functie is beschreven.

PHP zegt: “Volledige details, getroffen versies en de gefixeerde versies zullen met de release worden gepubliceerd.” Onderzoekers zijn begonnen het paar php2shell te noemen. Die naam is van hen, niet van PHP.

Wat het uiteindelijke bereik ook blijkt te zijn, PHP geeft fixes alleen uit voor zijn vier ondersteunde branches en legt de wijzigingen per branch vast in de changelog. Versies 8.2 en 8.3 krijgen alleen beveiligingsfixes, en 8.4 en 8.5 zijn in actieve ondersteuning. Voorafgaand aan de release verwachten meerdere trackers, waaronder Alpine Linux en beveiligingsonderzoeker Kevin Beaumont, dat de fixes worden uitgebracht als PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 — de volgende point-releases van elke branch — hoewel PHP de nummers nog niet heeft bevestigd.

Alles wat ouder is, inclusief 8.1, 8.0, 7.x en 5.x, is end-of-life en krijgt geen PHP-fix. Als de kwetsbaarheden die branches bereiken, zullen installaties daarop geen leverancierpatch ontvangen.

Beveiligingsbedrijf Mallory telde ongeveer 884.000 internetzichtbare hosts waarvan de HTTP-banner op 20 oktober aan de Shodan-zoekmachine een PHP-versie van 8.1 of ouder rapporteerde, 59% van de ongeveer 1,5 miljoen hosts die een versie rapporteerden. De telling betreft banners, geen bevestigde getroffen systemen, en nog eens 740.000 hosts rapporteerden PHP zonder versie.

PHP heeft geen work-around gepubliceerd. Totdat de release uitkomt, bestaat de voorbereiding uit zes stappen, de meeste ontleend aan een rapid-responsebericht van Huntress, met aanvullend isolatieadvies van CERT-EU.

1. Maak een inventaris van elke PHP-installatie, inclusief PHP dat is meegeleverd in vendor-appliances, Windows-software en control panels zoals cPanel en Plesk.
2. Wees klaar om te upgraden om 14:00 UTC. Patch eerst systemen die aan het internet zijn gekoppeld en controleer of je Linux-distributie en hostingprovider backported pakketten aanbieden.
3. Op een end-of-life-branch: upgrade, haal het systeem van het internet, of zet het achter een VPN of een web application firewall totdat je kunt patchen.
4. Waar patchen niet direct kan, adviseert CERT-EU om “overweeg internetgerichte applicaties te isoleren van publieke netwerken totdat een fix beschikbaar is.”
5. Houd in de gaten wat PHP start. Stel alerts in voor php-fpm, php-cgi, httpd of apache2 die shells, interpreters of downloadtools starten. Op Linux-servers zonder endpoint-detectie logt Florian Roths process-watcher elk programma dat een PHP-proces start, inclusief de commandoregel. Het ziet een programma pas nadat het is gestart en, in de woorden van Roth, “voorkomt niets.”
6. Als je iets vindt: isoleer de server, bewaar de webserver- en PHP-logs en zoek naar web shells, nieuwe bestanden in de webroot, nieuwe cron-jobs, geplande taken en accounts.

Huntress zei dat het tot 20 oktober geen exploitatie van de fouten in zijn partneromgevingen had gezien, geen proof of concept had gebouwd of gereproduceerd en niet op de hoogte was van publiek exploitcode. In watchTowr’s FAQ staat dat er tot 21 oktober geen exploitatie is gerapporteerd en dat de fouten niet in CISA’s Known Exploited Vulnerabilities-catalogus staan.

Ter vergelijking: toen CVE-2024-4577, een PHP-fout in CGI-modus op Windows, in juni 2024 openbaar werd, zag Akamai binnen 24 uur exploitpogingen tegen zijn honeypot-servers.

De release zou moeten verduidelijken wat de kennisgeving heeft achtergehouden: welke versies getroffen zijn, welk deel van PHP betrokken is, of een aanval een specifieke wijze van draaien van PHP, een configuratie of een login vereist, en hoe PHP de fouten zelf beschrijft. Ten tijde van schrijven had PHP de fixes nog niet vrijgegeven.