Kort gezegd: Of u door PHP2Shell bent getroffen, hangt af van drie dingen: de PHP-versie, de uitvoeringsmodus en of en hoe er is gepatcht. Bent u onzeker, neem dan nu contact op. Bent u getroffen? Bel ons. Wij helpen. Wij zoeken het op afstand uit op de server zelf, niet op gevoel, en dichten het lek als het open staat.
Verwijder nu niets en zet niets opnieuw op. Ook als u alleen wilt weten of u bent getroffen: is de server mogelijk al aangevallen, dan hebben wij bestanden en logboeken ongewijzigd nodig. Meld uw noodgeval, dan lopen we de controle samen met u door.
Bent u getroffen? Deze gevallen horen op de controlelijst
PHP2Shell zijn twee kritieke kwetsbaarheden in PHP zelf (CVE-2026-109618 en CVE-2026-109619, beide met de hoogste score 9.2 volgens CVSS v4.0). Ze maken het mogelijk om zonder inloggen op afstand schadelijke code uit te voeren. Alle uitvoeringsmodi kunnen getroffen zijn: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Controleer elk van deze systemen:
- eigen servers, vServers en rootservers met PHP
- hostingpakketten en managed servers, ook als u geen toegang hebt tot de configuratie
- containers en platformdiensten die een PHP-image meebrengen
- testsystemen, stagingomgevingen en vergeten oude systemen die vanaf internet bereikbaar zijn
- NAS-systemen, appliances of software van dienstverleners die intern PHP gebruiken
Juist vergeten systemen vormen het risico. Volgens Unit 42 zijn er meer dan 22,6 miljoen blootgestelde, mogelijk kwetsbare instanties, en het BSI (de Duitse federale dienst voor informatiebeveiliging) verwachtte snel grootschalig misbruik.
Wat u nu direct doet
- Maak een inventaris. Schrijf alle servers, domeinen en hostingcontracten op waarop PHP draait, en wie ervoor verantwoordelijk is.
- Stel per systeem de PHP-versie vast. Op servers met
php -v. Houd er rekening mee dat de opdrachtregel een andere versie kan gebruiken dan de webserver. - Bepaal de uitvoeringsmodus. Draait PHP als PHP-FPM, als mod_php of via LiteSpeed? Bij mod_php schat het PHP-team het risico het hoogst in.
- Vraag het uw hostingprovider en dienstverleners. Schriftelijk: welke versie draait er, is de correctie doorgevoerd, zijn alle processen herstart?
- Bewaar de logboeken. De vakpers adviseert logboeken vanaf 20-10-2026 te bewaren.
- Wacht niet te lang. Staat een systeem open en is de patch niet direct mogelijk, dan adviseert het BSI de webserver tijdelijk van het netwerk te halen.
Hoe helpt PHP SOS concreet?
Wij stellen op afstand en met bewijs vast of u bent getroffen.
- Situatie opnemen: Wij laten ons uw inventaris toelichten en ordenen de systemen naar bereikbaarheid en risico.
- Veiligstellen en dichten: Waar het open staat, zetten we eerst de toestand veilig en dichten we daarna het lek met een update inclusief herstart. Waar dat niet direct kan, treffen we tussentijdse maatregelen die geen volledige bescherming bieden.
- Controleren en opschonen: Wij controleren of het lek vóór de patch is misbruikt en ruimen zo nodig op. Of een server is getroffen en mogelijk al is aangevallen, houden we duidelijk gescheiden.
- Beveiligen en rapporteren: U krijgt een lijst per systeem: versie, uitvoeringsmodus, bewijs van de patch, openstaande punten.
Hoe u kunt aantonen dat u bent getroffen
Een versienummer alleen volstaat niet, omdat aanbieders correcties terugporteren. Ubuntu 24.04 toont volgens berichten bijvoorbeeld ook na de update nog steeds 8.3.6. Drie wegen zijn betrouwbaar:
| Weg | Wat het laat zien | Beperking |
|---|---|---|
| Versie vergelijken met de gecorrigeerde versies | 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of hoger is verholpen | geldt alleen voor originele versies, niet voor backports |
Test op memory_hard_limit_percent |
bool(false) betekent: directive onbekend, dus getroffen |
per versie en uitvoeringsmodus afzonderlijk uitvoeren |
| Pakketchangelog doorzoeken op CVE-nummers | bewijst backports bij distributies | bron is het beveiligingsarchief van de aanbieder |
De test ziet er zo uit:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Hoe u versie en patchstatus goed controleert, staat op de pagina PHP-versie en patchstatus goed controleren. Een overzicht van de takken geeft Welke PHP-versies zijn getroffen?. Waarom de weergave ondanks de patch oud kan lijken, legt het artikel php -v toont een oud nummer uit.
Getroffen en niet meer te patchen: PHP 8.1 en ouder
Voor PHP 8.1 en ouder zijn er geen officiële updates van het PHP-project meer, alleen minimale broncode-backports voor 7.4, 8.0 en 8.1. Wie zo'n versie gebruikt, heeft meestal twee wegen: een aanbieder met aangetoonde backport of de migratie naar een onderhouden versie. Er bestaan commerciële aanbiedingen voor langetermijnondersteuning; of en wanneer die PHP2Shell dekken, moet de aanbieder schriftelijk bevestigen. Wij helpen bij de beoordeling onder PHP 8.1 en ouder: wat nu geldt en bij de uitvoering in de PHP-patchservice.
Wat u ons het best kunt sturen
- Lijst van uw servers, domeinen en hostingproviders
- PHP-versie per systeem, voor zover bekend
- Uitvoeringsmodus en webserver, voor zover bekend
- Vermelding of Cloudflare of een andere bescherming ervoor staat en of de oorspronkelijke server rechtstreeks bereikbaar is
- Antwoorden van uw hostingprovider, als u die al hebt gevraagd
- Contactpersoon voor goedkeuringen en herstarts
Waarom PHP SOS
Wij werken Made in Germany en zijn met ons partnernetwerk van cyberprofessionals al meer dan 25 jaar gespecialiseerd in IT-beveiliging. U krijgt één aanspreekpunt dat uw inventaris doorloopt en elke uitspraak onderbouwt, in plaats van alleen versienummers af te lezen. Wij werken op afstand, zonder reistijd, en documenteren wat we hebben gecontroleerd. Een uitspraak als „veilig” doen we alleen voor zover die zich laat onderbouwen. Voor grotere omgevingen komt de PHP2Shell-noodhulp in aanmerking.
Bent u getroffen? Bel ons. Wij helpen.
Weet u niet of u bent getroffen, dan is dat reden genoeg om nu contact op te nemen. Bel ons of stuur een bericht via WhatsApp. Wij nemen het over vanaf het eerste bericht en zoeken het samen met u uit op de server. Meld nu uw noodgeval.
Veelgestelde vragen
Ben ik door PHP2Shell getroffen als ik alleen WordPress of een webshop gebruik?
Mogelijk wel. De kwetsbaarheden zitten in PHP, niet in het CMS. Beslissend is welke PHP-versie en uitvoeringsmodus bij u daadwerkelijk worden gebruikt; een WordPress-update verandert daar niets aan.
Is het versienummer genoeg om te weten of ik ben gepatcht?
Niet altijd. Distributies en hostingproviders voeren correcties soms als backport door, waarna het nummer gelijk blijft. Betrouwbaar zijn de pakketchangelog met de CVE-nummers of de schriftelijke bevestiging van uw aanbieder.
Is er een snelle test om te zien of mijn PHP-versie de correctie bevat?
Volgens de PHP-handleiding is een versie die de directive memory_hard_limit_percent niet kent, getroffen. De test moet voor elke PHP-versie en uitvoeringsmodus afzonderlijk worden uitgevoerd, omdat de opdrachtregel een andere versie kan gebruiken dan de webserver.
Zijn ook oudere PHP-versies zoals 7.4 of 8.0 getroffen?
Volgens de vakpers zijn bijna alle versies tot en met PHP 5.4 getroffen. Voor 8.1 en ouder zijn er geen officiële updates meer van het PHP-project, alleen minimale broncode-backports. Of een aanbieder die heeft doorgevoerd, moet hij zelf bevestigen.
Beschermt Cloudflare mij als ik ben getroffen?
Gedeeltelijk. Cloudflare heeft beschermingsregels uitgerold, maar waarschuwt zelf dat ze de update niet vervangen. Is uw oorspronkelijke server rechtstreeks bereikbaar, dan wordt de bescherming omzeild.