Kort gezegd: PHP2Shell zijn twee kritieke kwetsbaarheden in PHP zelf, waarmee aanvallers zonder inloggen schadelijke code kunnen uitvoeren. Hebt u snel hulp nodig bij dit PHP-beveiligingslek, dan nemen wij op afstand de inventarisatie, het patchen of een overbruggingsmaatregel, de herstart van alle PHP-processen en een eerste sporenonderzoek over. Aan het eind ontvangt u een schriftelijk bewijs van de stand van zaken.
Hulp bij het PHP-beveiligingslek: waarom nu handelen nodig is
Op 21 oktober 2026 om 16 uur Duitse tijd publiceerde het PHP-project patches voor CVE-2026-109618 en CVE-2026-109619. Beide kwetsbaarheden zijn met CVSS v4.0 beoordeeld met 9,2 en maken het op afstand uitvoeren van schadelijke code mogelijk, zonder dat iemand hoeft in te loggen. Getroffen zijn de gangbare werkwijzen: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed.
Het BSI (de Duitse federale dienst voor informatiebeveiliging) heeft waarschuwingsniveau 3 (oranje) afgegeven. Het adviseert direct te updaten en, als dat niet meteen kan, de webservers tijdelijk van het netwerk te halen. Palo Alto Networks (Unit 42) telde meer dan 22,6 miljoen blootgestelde, mogelijk kwetsbare instanties. Bevestigde succesvolle aanvallen op grote schaal waren volgens het BSI aanvankelijk niet bekend, maar Cloudflare meldde al wel aanvalspogingen.
Voor directie en eigenaren betekent dit: elke openbaar bereikbare PHP-server is een kandidaat totdat het tegendeel is aangetoond. Een begrijpelijke uitleg van het lek vindt u onder Wat is PHP2Shell?.
Voor wie is de PHP2Shell-spoedhulp bedoeld?
Voor bedrijven, bureaus en overheidsinstanties die PHP-toepassingen draaien en de situatie niet alleen op het vereiste niveau kunnen of willen aanpakken. Dat geldt voor eigen rootservers en vServers, maar ook voor servers met Plesk of cPanel, containeromgevingen en managed servers waarbij de verantwoordelijkheid onduidelijk is.
Ook wie een hoster heeft, kan vaak ondersteuning gebruiken. Veel aanbieders installeren backports; Plesk toont dan bijvoorbeeld nog steeds 8.2.34, terwijl de pakketstand gepatcht is. Omgekeerd kan er een nieuw versienummer worden getoond terwijl oude PHP-processen nog in het geheugen draaien. Welke standen als verholpen gelden, staat op Welke PHP-versies zijn getroffen?.
Hoe helpt PHP SOS concreet?
- Inventarisatie: wij leggen alle PHP-installaties, werkwijzen en versies op uw servers vast, inclusief pakketstand en lopende processen. Het resultaat is een lijst van systemen die getroffen, verholpen of onduidelijk zijn.
- Patch of overbruggingsmaatregel: waar mogelijk installeren we de verholpen versies (8.5.12, 8.4.27, 8.3.36, 8.2.35) of de pakketten van uw distributie. Lukt dat niet meteen, dan voeren we de overbruggingsmaatregelen volgens php.net door en zeggen we eerlijk dat ze geen volledige bescherming bieden.
- Herstart en controle: wij herstarten alle PHP-workers en -processen en controleren daarna dat er geen oud proces meer draait. Nieuwe bestanden alleen dichten het lek niet.
- Eerste sporenonderzoek: we beveiligen de serverlogs vanaf 20 oktober en zoeken naar opvallende zaken zoals nieuwe PHP-bestanden, onbekende cronjobs of ongebruikelijke processen. Omdat er geen gepubliceerde, bevestigde Indicators of Compromise zijn, berust deze controle op gedragsanalyse.
- Bewijs en vervolgstappen: u ontvangt een schriftelijk rapport. Bij vermoeden van een compromittering adviseren we de passende vervolgstappen, zoals malwareverwijdering of een forensisch onderzoek.
Een patch verwijdert geen reeds binnengebrachte schadelijke software en bewijst niet dat er eerder niets is gebeurd. Daarom hoort bij de spoedhulp altijd een blik op de periode vanaf 17 oktober 2026.
Wat u van ons krijgt
- een overzicht van alle gecontroleerde servers met PHP-versie, pakketstand, werkwijze en patchstatus
- de documentatie van de geïnstalleerde updates of de ingestelde overbruggingsmaatregelen
- het bewijs dat alle PHP-processen zijn herstart
- een inschatting van het sporenonderzoek, gescheiden in aangetoond, waarschijnlijk en onbekend
- een lijst met openstaande punten, bijvoorbeeld systemen met PHP 8.1 of ouder
Dit rapport kunt u doorgeven aan directie, functionarissen voor gegevensbescherming of verzekeraars. Een juridische beoordeling is het niet.
Wat wij van u nodig hebben
- Toegang: SSH- of paneeltoegang met voldoende rechten, of anders een machtiging voor uw hoster om ons informatie te geven
- Aanspreekpunt: een persoon die beslissingen mag nemen, bijvoorbeeld over een korte offlineperiode of een herstart
- Overzicht: welke websites, shops en toepassingen op welke servers draaien
- Onderhoudsvenster: uw voorwaarden voor wanneer herstarts mogen plaatsvinden
- Back-ups: informatie over waar actuele back-ups staan
Voor beheerders die vooraf zelf willen controleren, volstaat vaak al deze ongevaarlijke blik op de stand van zaken:
php -v
# Debian/Ubuntu: geïnstalleerde PHP-pakketten met versie
dpkg -l | grep -i php
# lopende PHP-processen en hun starttijd
ps -eo pid,lstart,cmd | grep -i php
Wat we niet beloven
Wij beloven geen absolute veiligheid en geen uitspraak dat uw server nooit is aangevallen, als de bewijzen dat niet toelaten. We blijven aan het incident werken totdat het is afgesloten en gedocumenteerd. Of er een meldplicht geldt op grond van de AVG of dat uw verzekering moet worden ingelicht, bespreekt u met de functionaris voor gegevensbescherming, uw advocaat of verzekeraar. Wij leveren daarvoor de technische feiten.
Hebt u alleen de update met bewijs nodig, dan past onze PHP-patchservice. Zijn er al aanwijzingen voor een aanval, dan is de noodhulp bij een gehackte website de juiste start.
Veelgestelde vragen
Is het genoeg als mijn hoster PHP heeft bijgewerkt?
Dat kan volstaan als de hoster de pakketstand schriftelijk bevestigt en alle PHP-processen zijn herstart. Het getoonde versienummer alleen is geen bewijs, omdat distributies backports installeren. Of de server al eerder is aangevallen, beantwoordt een patch sowieso niet.
Moet mijn website voor de spoedhulp offline?
Niet per se. Het BSI adviseert webservers tijdelijk van het netwerk te halen als de update niet direct mogelijk is. Of dat bij u nodig is, beslissen we samen na de inventarisatie.
Beschermt een WordPress- of Shopware-update tegen PHP2Shell?
Nee. PHP2Shell zit in PHP zelf, niet in het CMS. Een CMS-update blijft zinvol, maar dicht dit lek niet.
Wat gebeurt er bij PHP 8.1 of ouder?
Voor deze versies zijn er geen officiële updates meer van het PHP-project, alleen minimale broncode-backports voor 7.4, 8.0 en 8.1. Wij beveiligen de server tijdelijk en plannen met u de overstap naar een ondersteunde versie.