php2shell: kritieke RCE in PHP (CVE-2026-109618 en CVE-2026-109619)

PHP bracht op 21 oktober 2026 noodpatches uit voor twee kritieke kwetsbaarheden in PHP zelf, samen bekend als php2shell (CVE-2026-109618 en CVE-2026-109619). Een aanvaller kan er zonder in te loggen code mee uitvoeren op een webserver die PHP draait. Beide kwetsbaarheden krijgen een CVSS-score van 9.2.

Er is nu een oplossing. Werk bij naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35. PHP noemt updaten nadrukkelijk de enige volledige oplossing. De tijdelijke maatregelen die gisteren circuleerden dekken maar een deel van de aanvalspaden af.

Lopende situatie. Dit artikel is bijgewerkt op 21 oktober 2026 om 16:45 uur, na de officiële release van PHP, de publicaties van de onderzoekers van Calif, Wiz en OpenAI, en de eerste berichten over uitval bij Nederlandse diensten.

php2shell in het kort

Wat moet u nu doen?

1. Werk PHP bij naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 en herstart daarna alle PHP-workers. Controleer na het bijwerken ook uw memory_limit en post_max_size, want de fix voegt een nieuwe harde geheugenlimiet toe die het proces beëindigt zodra die wordt bereikt.
2. Breng in kaart waar PHP nog meer draait, ook op vergeten test- en acceptatieservers. Een vulnerability scan helpt verborgen systemen te vinden. Bij shared hosting vraagt u uw hostingpartij wanneer zij patchen.
3. Draait u PHP 8.1 of ouder, dan krijgt u geen reguliere update. Vraag uw distributie om een backport of upgrade naar een ondersteunde versie. PHP heeft vanwege de ernst wel minimale source-backports voor 7.4, 8.0 en 8.1 vrijgegeven.
4. Gebruikt u het vrijwilligersrepository rpms.remirepo.net, stap dan over op distributiepakketten of bouw vanaf de broncode. Dat repository krijgt de update voorlopig niet.
5. Loop uw logbestanden na op de sporen die Wiz beschrijft: ongebruikelijke multipart-verzoeken gevolgd door memory-limit-fouten of herhaalde HTTP 500-responses, opvallend grote PHPSESSID-cookies en onverklaarde herstarts van PHP-workers.

Kunt u niet meteen bijwerken?

PHP is er duidelijk over dat alleen updaten een volledige oplossing is. PHP-coredeveloper Gina Peter Banyard zei het voor de release al tegen iemand die dacht genoeg te hebben aan een instelling: “the only mitigation is patching/upgrading PHP. I sadly know too much.” Lukt bijwerken niet direct, dan beperken deze maatregelen een deel van de aanvalspaden.

• Zet memory_limit=-1 op beheerdersniveau, bijvoorbeeld met php_admin_value in de FPM-pool of de Apache-configuratie, en controleer dat geen enkele pool, map of applicatie er alsnog een limiet voor terugzet.
• Houd post_max_size laag, 8M zonder uploads en 32M als uploads nodig zijn, met upload_max_filesize daaronder.
• Zet session.upload_progress.enabled=0 en herstart elke worker. Doe dit in php.ini, de FPM-pool of de serverconfiguratie. Een FPM .user.ini en ini_set() werken hier niet, omdat die pas worden toegepast ná het moment waarop de aanval plaatsvindt.
• Draait u PHP 8.5, zet dan ook fatal_error_backtraces=0 en herstart alle workers.
• Gebruik geen RLIMIT_AS of RLIMIT_DATA als geheugenbegrenzing. Die veroorzaken juist de allocatiefout die de kwetsbaarheid activeert.

Bent u kwetsbaar?

Eén ding bepaalt het antwoord, en dat is niet de software die u draait maar de PHP-versie eronder. Wiz demonstreerde ongeauthenticeerde code-uitvoering tegen de nieuwste WordPress, Drupal en Joomla. Een volledig bijgewerkte site was dus gewoon te pakken, zolang de PHP eronder oud was.

Uw applicatie bijwerken helpt dus niet. De PHP-runtime komt van uw serverpakket, uw hostingpartij of uw container-image.

Welke PHP-versies zijn geraakt?

PHP 8.1 en ouder krijgen geen reguliere update meer, en PHP 8.2 bereikt op 31 december 2026 het einde van zijn levensduur. Vanwege de ernst heeft het PHP-securityteam wel minimale source-backports voor 7.4, 8.0 en 8.1 vrijgegeven.

Hoe groot is het risico in uw situatie?

Zo controleert u welke versie u draait

Kijk naar de PHP-versie die uw webserver gebruikt, want php -v op de commandoregel kan een andere versie tonen dan de versie die uw site bedient. Distributies leveren de fix vaak onder een oud ogend versienummer. Controleer daarom op het CVE-nummer in de changelog van het pakket, zoals Debian adviseert, en niet op het versienummer zelf.

ps -eo args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'   # welke PHP bedient uw site?
php -i | grep '^PHP Version'                            # welke versie draait er?

Wat is php2shell?

php2shell is de verzamelnaam voor twee losse kwetsbaarheden die allebei tot remote code execution leiden. PHP publiceerde bij de release voor elk een advisory met de volledige technische details.

CVE-2026-109618 draait om geheugencorruptie bij out-of-memory. PHP gebruikt longjmp() om een request af te breken zodra het geheugen opraakt. Op sommige momenten is het requestgeheugen al bereikbaar terwijl het nog niet volledig is geïnitialiseerd. Breekt PHP daar af, dan blijft dat geheugen in een ongeldige staat achter en verwerkt de opruimroutine het alsof het klopt. Een aanvaller kan dat geheugentekort zelf uitlokken, bijvoorbeeld met een multipart-verzoek met een onbeperkt aantal headers dat ruim binnen uw ingestelde limieten blijft.

CVE-2026-109619 draait om hergebruik van vrijgegeven geheugen. PHP bewaart interne status in een worker die eigendom is van één request. Wordt die status niet gewist voordat het requestgeheugen wordt vrijgegeven, dan verwijst de worker naar geheugen dat niet meer van hem is. Een volgend request op dezelfde worker kan die verouderde status gebruiken voordat de normale initialisatie hem vervangt. Dat is een use-after-free, en met een zorgvuldig opgebouwde heap levert dat code-uitvoering op.

Voor die tweede kwetsbaarheid zijn twee paden bevestigd. Het ene loopt via waarschuwingen over ongeldige of verouderde INI-instellingen die vóór de normale initialisatie worden toegepast. Het andere loopt via session upload progress, een functie die standaard aanstaat en die geen session_start() in uw eigen code nodig heeft. Op PHP 8.5 is de backtrace bij een fatale fout het sterkst bewezen pad.

Het grootste risico ligt bij Apache met mod_php. Die roept de opruimroutine altijd aan, ook als het opstarten van het request al is mislukt. Daardoor slaat een aanvaller toe nog voordat uw eigen code ook maar begint. PHP-FPM, php-cgi, FrankenPHP en LiteSpeed zijn eveneens geraakt, al is daar meer voor nodig. Op GitHub circuleren intussen repositories die claimen de kwetsbaarheid te misbruiken. Voer geen code van onbekende accounts uit op uw servers.

Waarom raakt php2shell zo veel servers?

De kwetsbaarheid zit niet in de software erbovenop, maar in PHP zelf, de laag eronder. Een update van bijvoorbeeld WordPress helpt dus niet. En PHP draait vrijwel overal:

• 69,3% van alle websites met een bekende servertaal draait op PHP (W3Techs).
• 39,6% van alle sites draait op WordPress. Ook andere kant-en-klare software is in PHP geschreven, zoals Joomla, Drupal, Magento, WooCommerce, Nextcloud, MediaWiki (Wikipedia) en Moodle.
• Ook uw eigen maatwerk valt eronder: applicaties gebouwd met frameworks als Laravel of Symfony, plus de beheerpanelen cPanel en Plesk van veel hosters.

Daar komt bij dat er geen authenticatie nodig is en dat de fout op dezelfde plek in elke installatie zit. Daardoor is de kwetsbaarheid eenvoudig op grote schaal te scannen. Mallory telde op 20 oktober 2026 ruim 1,5 miljoen zichtbare PHP-servers, waarvan er 883.717 een versie zonder patch draaiden. Een geslaagde aanval levert code-uitvoering op met de rechten van de webserver. Maar ook zonder die stap kan een aanvaller het werkgeheugen van een PHP-worker uitlezen, waarin wachtwoorden, sessietokens, API-sleutels en certificaten van andere bezoekers kunnen staan.

Hoe serieus organisaties het nemen, bleek op de dag van de patch. In Nederland gingen MijnOverheid, DigiD, de site van de Tweede Kamer, het Nationaal Cyber Security Centrum en verschillende onderwijssystemen uit voorzorg offline, meldde de NOS. Het NCSC had geen misbruik waargenomen, maar riep iedereen op te patchen. Ook daarbuiten gebeurde dat. Personeelsdienstverlener BambooHR haalde zijn dienst offline in de Verenigde Staten, Canada en Ierland, waardoor de salarisverwerking stil kwam te liggen.

Cloudflare meldde rond de release de eerste aanvalspogingen en noemde zijn eigen firewallregels nadrukkelijk een tijdelijke noodgreep. Een geslaagde inbraak is nog door niemand bevestigd en watchTowr zag op 21 oktober nog geen misbruik in het wild. Sansec verwachtte massale aanvallen binnen vijftien minuten na de release, dus nu de technische details openbaar zijn is het een race tegen de klok. Draait er bij u maatwerk op PHP, dan brengt een webapplicatie pentest in kaart welke systemen in de schietlijn liggen.

Wie vond php2shell, en hoe lekte het uit?

php2shell is gevonden door Ryan Austin van Calif Research, tijdens een audit van de PHP-broncode binnen het Patch the Planet-initiatief van OpenAI. Hij vond de eerste fout op 1 augustus 2026, enkele dagen na de start van die audit. Wiz stuitte er op 19 augustus onafhankelijk op en demonstreerde ongeauthenticeerde code-uitvoering tegen de nieuwste versies van WordPress, Drupal en Joomla.

Opvallend is de rol die AI daarin speelde. Beide teams zetten taalmodellen in bij het zoeken. Wiz noemt de bijdrage van Gemini 4 Argon en GPT-5.6 Sol aan het vinden van de kwetsbaarheid, het bouwen van de exploit en het valideren van de patch onmisbaar. Het gaat hier om geheugenfouten in code die al jaren op miljoenen servers draait.

De melding zelf verliep volgens de regels. Calif meldde de eerste kwetsbaarheid op 11 augustus bij PHP en leverde drie dagen later een werkende proof-of-concept. De tweede volgde op 21 augustus. Daarna werkten PHP, Calif, OpenAI en Wiz maandenlang samen aan het zoeken naar varianten, het opzetten van detectie en het valideren van de patch, met een gecoördineerde bekendmaking gepland voor eind oktober.

Op 20 oktober 2026 liep het mis. Via een bericht op Hacker News lekten de kwetsbaarheden uit, twee dagen voor die geplande bekendmaking. Kort daarna verscheen de naam php2shell op X, met screenshots en een video van een exploittool, en bevestigde watchTowr dat de kwetsbaarheden echt waren. PHP haalde de release daarop een dag naar voren.

php2shell was dus nooit een klassieke zeroday. PHP kende de kwetsbaarheden al ruim twee maanden en werkte aan een oplossing. Door het lek gedroeg het zich de laatste dag alsnog als een zeroday, met exploitcode in omloop terwijl de patch er nog niet was. Die periode is voorbij, maar wie niet snel bijwerkt blijft kwetsbaar, juist omdat de technische details nu volledig openbaar zijn.

De gebeurtenissen op een rij (Nederlandse tijd):