PHP2Shell: welke PHP-versies zijn gepatcht en hoe controleert u de uwe

In oktober 2026 dichtte het PHP-project 2 kritieke kwetsbaarheden waarmee een aanvaller zonder in te loggen code op een server kan uitvoeren. CISA noemt ze "PHP2Shell". Ze zijn geregistreerd als CVE-2026-109618 en CVE-2026-109619, en beide krijgen een score van 9,2 op CVSS v4.0. Draait een deel van de onlinedienstverlening van uw bedrijf op PHP, dan is de actie eenvoudig: zorg dat het draait op PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 of nieuwer, of op een build van uw leverancier die de oplossing bevat.

Dit artikel legt uit wat er is opgelost, welke versies de oplossing bevatten, hoe u nagaat welke versie uw server meldt en wat u vraagt aan wie uw hosting beheert. U kunt ook in enkele seconden controleren welke PHP-versie uw website meldt.

Wat PHP2Shell is

Het PHP-beveiligingsadvies van 21 oktober 2026 beschrijft 2 fouten in de manier waarop PHP interne verzoekgegevens verwerkt:

• CVE-2026-109618, geheugencorruptie bij geheugentekort. Wanneer PHP geen geheugen meer heeft, kan het worden onderbroken terwijl interne verzoekgegevens maar gedeeltelijk zijn geïnitialiseerd, waarna de opruimroutine ongeldige gegevens als geldig kan behandelen.
• CVE-2026-109619, verouderde verzoekstatus. Interne status die bij één verzoek hoort, kan blijven bestaan nadat het geheugen is vrijgegeven, en een later verzoek dat door dezelfde worker wordt afgehandeld, kan die gebruiken.

Beide kunnen uitvoering van code op afstand zonder authenticatie mogelijk maken. Volgens het advies is elke PHP-installatie die webverzoeken afhandelt getroffen, inclusief PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het PHP-team beschouwt mod_php als het grootste risico, omdat een verzoek de aanval kan starten nog voordat er applicatiecode draait. Dat betekent ook dat de applicatie erbovenop (WordPress, een webshop, een eigen portaal) u op zichzelf niet beschermt; de oplossing zit in PHP.

Gepatchte versies en tijdlijn

• 21 oktober 2026: het PHP-project bracht 8.2.35, 8.3.36, 8.4.27 en 8.5.12 uit met de oplossing. Dezelfde dag publiceerde het Slowaakse nationale CSIRT SK-CERT een waarschuwing en gaf CISA een alert uit.
• 26 oktober 2026: CISA voegde beide CVE's toe aan zijn Known Exploited Vulnerabilities-catalogus, de lijst van kwetsbaarheden waarvoor bewijs bestaat dat ze in de praktijk worden misbruikt.

PHP 8.1 en ouder krijgen geen updates meer van het PHP-project (zie ondersteunde versies). Het advies vermeldt dat sommige Linux-distributies en leveranciers van langetermijnondersteuning oplossingen terugporteren, en dat het PHP-beveiligingsteam minimale bron-backports voor 7.4, 8.0 en 8.1 heeft gepubliceerd voor wie PHP zelf bouwt. Draait uw dienst op een van die takken, vraag dan uw leverancier of de oplossing is inbegrepen en plan een overstap naar een ondersteunde tak.

Zo achterhaalt u welke PHP-versie u gebruikt

Het definitieve antwoord komt van de server zelf, niet van buitenaf:

• Vraag wie de dienst beheert (uw hostingprovider, bureau of IT-team) naar de exacte PHP-versie en of die de oplossingen van 21 oktober bevat.
• Hebt u shelltoegang, voer dan php -v uit. De webserver kan een ander PHP-programma gebruiken dan de opdrachtregel, dus controleer ook de versie in uw hostingpaneel of in de PHP-FPM-pool.
• Pakketbeheerders tonen builds van leveranciers: op Debian en Ubuntu dpkg -l | grep php, op RHEL en vergelijkbare systemen rpm -qa | grep php. Vergelijk de pakketversie met het beveiligingsbericht van uw leverancier, want leveranciers behouden vaak het oorspronkelijke versienummer en voegen de oplossing toe.

Van buitenaf melden sommige servers hun versie in de HTTP-antwoordheaders:

X-Powered-By: PHP/8.3.12
Server: Apache/2.4.62 (Debian)

Uw eigen headers ziet u met curl -sI https://www.example.com/. Onze PHP2Shell-controle leest dezelfde 2 headers, X-Powered-By en Server, en vergelijkt het nummer met de gepatchte versies.

Wat de header wel en niet vertelt

Lees de header zorgvuldig, in beide richtingen:

• Een oud nummer bewijst niet dat de server kwetsbaar is. Veel hostingproviders passen de oplossing op systeemniveau toe en behouden de oorspronkelijke versietekst.
• Een actueel nummer is een goed teken, geen bewijs. De header kan worden aangepast of worden ingesteld door een proxy voor de server.
• Geen nummer betekent geen informatie. De meeste servers sturen hun PHP-versie helemaal niet mee. Toen we op 31 oktober 2026 8.221 domeinen van Slowaakse bedrijven maten, meldden slechts 332 van de 8.171 die antwoordden een PHP-versie in hun headers (4,1 %). Voor de rest zegt de header niets, in welke richting ook, en gaat de vraag naar wie de dienst beheert.

Wat u nu doet

1. Werk PHP bij naar 8.2.35, 8.3.36, 8.4.27, 8.5.12 of nieuwer, of installeer het gepatchte pakket van uw leverancier. Herstart PHP-FPM of de webserver, zodat de nieuwe versie ook echt draait.
2. Vraag uw hostingprovider schriftelijk welke PHP-versie uw dienst draait en of die de oplossingen voor CVE-2026-109618 en CVE-2026-109619 bevat. Vraag hetzelfde voor stagingservers en oudere projecten; zie vergeten staging- en testservers.
3. Plan de overstap weg van PHP 8.1 en ouder als er geen teruggeporteerde oplossing beschikbaar is.
4. Maak de versie niet langer bekend. Zet expose_php = Off in php.ini om X-Powered-By te verwijderen en beperk de Server-header (ServerTokens Prod voor Apache, server_tokens off voor nginx). Dat lost op zichzelf niets op, maar geautomatiseerde scanners krijgen zo minder details te zien. Meer in HTTP security headers die elke zakelijke website hoort te sturen.

Kunt u niet meteen bijwerken, dan noemt het advies tijdelijke maatregelen die bepaalde aanvalspaden beperken, en stelt het duidelijk dat alleen de update een volledige oplossing is.

Hoe Datahorses helpt

We bewaken uw bedrijf dagelijks van buitenaf, zoals een aanvaller het zou zien, en we hebben geen toegang tot uw systemen nodig. Begint een server een verouderde softwareversie te melden, dan krijgt wie de server beheert bij de bevinding de precieze stappen. Bekijk wat wij bewaken of vraag een offerte aan.