← Al het nieuws
ARTIKEL
Geruchten
23 oktober 2026 3 min leestijd

PHP2Shell-kwetsbaarheid: update PHP vandaag, beide RCE-lekken al misbruikt

Twee kritieke PHP-lekken, CVE-2026-109618 en CVE-2026-109619, maken code-uitvoering zonder authenticatie mogelijk en worden al misbruikt. De fixes kwamen op 21 oktober uit.

In dit artikel
  1. Wat bevestigd is
  2. PHP2Shell-kwetsbaarheid: welke PHP-versies veilig zijn
  3. Wat er gezegd wordt
  4. Waarom het ertoe doet
  5. Wat je vandaag moet doen

De PHP2Shell-kwetsbaarheid bestaat eigenlijk uit twee kritieke lekken in de programmeertaal PHP, CVE-2026-109618 en CVE-2026-109619, waarmee een aanvaller zonder inloggegevens code kan uitvoeren op een webserver. Het PHP-project bracht op 21 oktober 2026 gefixte releases uit, en dezelfde dag werden de eerste aanvallen waargenomen. Draait er PHP op een server van jou of van een klant, update dan vandaag nog.

Een grote serverzaal van bovenaf gezien, met rijen serverrekken en bordjes voor mailservers en webservers.
Foto: Florian Hirzinger - www.fh-ap.com (CC BY-SA 3.0), Wikimedia Commons.

Wat bevestigd is

Het PHP-project ontving de eerste meldingen op 11 augustus 2026. Amazon Threat Intelligence meldde op 17 oktober een poging tot misbruik, vóór de openbare bekendmaking. Op 20 oktober lekten de details eerder dan afgesproken online, waarna PHP de noodrelease naar voren haalde naar 21 oktober. Op die dag zag watchTowr actief misbruik op zijn honeypot-netwerk.

CVE-2026-109618 zit in de afhandeling van out-of-memory-fouten: als PHP tijdens het opzetten van de requestgegevens geen geheugen meer heeft, blijven die gegevens deels geïnitialiseerd en behandelt de laatste opruiming ze als geldig. CVE-2026-109619 is een bug met verouderde globale toestand die leidt tot een heap use-after-free, met geheugenlekken en code-uitvoering. Beide maken remote code-uitvoering mogelijk, zonder authenticatie, met de rechten van het account van de webserver. In de adviezen van beveiligingsleveranciers krijgen ze 9,2 op CVSS v4.0.

Elke PHP-installatie die webverzoeken afhandelt valt eronder: Apache met mod_php, PHP-FPM, php-cgi, LiteSpeed en FrankenPHP. Het PHP-project ziet het risico als het hoogst bij mod_php, omdat de aanval kan slagen voordat er applicatiecode draait. Om dezelfde reden houdt een webapplicatiefirewall of een RASP-agent binnen het PHP-proces de aanval mogelijk niet tegen.

PHP2Shell-kwetsbaarheid: welke PHP-versies veilig zijn

  • PHP 8.5: update naar 8.5.12.
  • PHP 8.4: update naar 8.4.27.
  • PHP 8.3: update naar 8.3.36.
  • PHP 8.2: update naar 8.2.35.
  • PHP 8.1, 8.0 en 7.4: geen officiële release. Minimale backports bestaan alleen als broncode, of als pakketten van distributies en LTS-leveranciers.
  • PHP 7.3 en ouder, inclusief PHP 5: geen fix, je moet overstappen op een ondersteunde tak.

Linuxdistributies verhelpen een lek vaak zonder het versienummer te wijzigen: controleer de changelog van het pakket, niet alleen de uitvoer van php -v.

Gerucht

Wat er gezegd wordt

Over de stand van de exploit zijn de bronnen het oneens. Sommige onderzoekers beweren dat de twee lekken al aan elkaar gekoppeld zijn in één werkend script en dat er openbare analyses en een tool bestaan. Huntress schreef dat het geen proof of concept had kunnen reproduceren, en JFrog waarschuwde dat er nepexploits circuleren. Wie een zogenaamde PHP2Shell-exploit van een forum downloadt, loopt het risico malware te installeren.

Op 22 oktober stonden de lekken volgens watchTowr niet in de CISA KEV-catalogus. Het Britse National Cyber Security Centre (NCSC) riep organisaties op om meteen te updaten of blootgestelde systemen offline te halen. VirusTotal schat dat er meer dan 5,1 miljoen PHP-hosts bereikbaar zijn vanaf het internet.

Waarom het ertoe doet

Beheer je de IT voor een mkb-bedrijf of voor meerdere klanten, dan zit PHP niet alleen in de sites die je zelf hebt gebouwd. Het zit in WordPress, Joomla, Magento, PrestaShop, webmail, oude bedrijfsapplicaties en in elke container waarvan de basisimage PHP bevat. Een container houdt de PHP-versie waarmee hij is gebouwd: je moet opnieuw bouwen, of een gefixte image ophalen, en opnieuw deployen.

Wat je vandaag moet doen

  1. Maak een inventaris: php -v op elke host en docker exec <container> php -v op elke container die PHP draait.
  2. Update naar de gefixte versie, of naar het gefixte pakket van je leverancier, en herstart daarna PHP-FPM of Apache.
  3. Kun je niet meteen updaten, haal dat systeem dan van directe internettoegang af.
  4. Als noodmaatregelen die niet volledig beschermen: session.upload_progress.enabled=0 met een herstart van de workers, een lage post_max_size (8M, of 32M als je uploads nodig hebt) en geheugenlimieten op containerniveau.
  5. Bekijk de toegangslogs vanaf 17 oktober en roteer wachtwoorden, tokens en API-sleutels als je vermoedt dat het procesgeheugen is uitgelezen.

Het PHP-project is duidelijk: geen enkele configuratie verhelpt deze lekken volledig, en updaten is de enige blijvende verdediging. Voor hulp bij het bepalen van prioriteiten en snel patchen, zie onze cybersecurity-diensten.

Bronnen: watchTowr, PHP2Shell FAQ; BleepingComputer; Qualys; JFrog; Huntress.