Kort gezegd: Het PHP-beveiligingslek PHP2Shell bestaat uit twee kritieke fouten in PHP, de basis van de meeste websites en webshops. Aanvallers kunnen daarmee zonder wachtwoord schadelijke code op webservers uitvoeren. Het BSI (de Duitse federale dienst voor informatiebeveiliging) waarschuwt met niveau Oranje en adviseert: direct bijwerken, anders getroffen servers tijdelijk van het net halen. Voor de directie betekent dat vandaag: verantwoordelijkheid regelen, update en bewijs eisen, beslissen over een uitschakeling en alles documenteren.
De situatie in drie zinnen
Op 21 oktober 2026 heeft het PHP-project updates gepubliceerd voor twee kritieke beveiligingslekken, bekend onder de naam PHP2Shell. Getroffen is PHP zelf, niet een bepaald product, dus potentieel elke website, elke webshop en elk portaal dat met PHP draait. Het BSI heeft waarschuwingsniveau 3 / Oranje uitgeroepen, beveiligingsbedrijven melden aanvalspogingen, bevestigde geslaagde aanvallen op grote schaal waren volgens het BSI aanvankelijk niet bekend.
Instanties zoals het BKA (de Duitse federale recherche) en meerdere steden hebben hun websites volgens mediaberichten preventief uitgeschakeld. Dat was voorzorg, geen teken van een aanval.
Wat het PHP-beveiligingslek voor directie en bedrijf betekent
De vraag is niet of u PHP gebruikt. Vrijwel elk bedrijf doet dat ergens: website, webshop, sollicitantenportaal, klantenomgeving, intranet, ticketsysteem, microsite van een bureau. De vraag is of die systemen actueel zijn en wie ervoor verantwoordelijk is.
Slaagt een aanval, dan kan de aanvaller in het ergste geval de server overnemen. Mogelijke gevolgen zijn gegevenslekken, gemanipuleerde inhoud, doorverwijzingen naar oplichtingssites, uitval van de webshop of misbruik van de server voor verdere aanvallen. Als persoonsgegevens getroffen kunnen zijn, komen er meldplichten bij; de termijn volgens art. 33 AVG bedraagt in de regel 72 uur. Details daarover staan onder AVG-meldplicht. Dit is geen juridisch advies.
Welke kosten er in een noodgeval typisch ontstaan, plaatst de bijdrage Kostenposten van een hack in perspectief.
Waar PHP in bedrijven vaak over het hoofd wordt gezien
De hoofdwebsite hebben de meesten in beeld. Over het hoofd gezien worden eerder systemen aan de rand: het sollicitantenportaal van een externe aanbieder, de landingspagina van een eerdere campagne, een partnergedeelte voor dealers, het ticketsysteem van de support, een bestands-cloud op een eigen server of de webinterface van een netwerkopslag. Ook testsystemen van bureaus zijn vaak openbaar bereikbaar en draaien op dezelfde server als de echte website.
Voor de directie is de les eenvoudig: de vraag aan de IT luidt niet „Is onze website gepatcht?”, maar „Zijn al onze systemen met PHP gepatcht, ook die van dienstverleners?”. Het verschil tussen beide vragen is vaak precies de plek waar een aanval slaagt.
Wat de situatie niet is
Even belangrijk is de nuancering naar beneden. PHP2Shell is geen reden voor actiedrang die de bedrijfsvoering meer verstoort dan nodig. Wie aantoonbaar heeft gepatcht, alle PHP-processen heeft herstart en bij de controle geen bijzonderheden vindt, kan terugkeren naar de normale bedrijfsvoering. Een tijdelijke uitschakeling is een optie voor onduidelijke gevallen, geen verplichting voor iedereen.
Vijf vragen aan uw IT of dienstverlener
Deze vragen kunt u vandaag stellen. De antwoorden moeten schriftelijk komen.
- Welke van onze systemen draaien met PHP? Een lijst met adres, doel en beheerder.
- Is elk systeem gepatcht? Verholpen versie 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of een door de aanbieder bevestigde backport.
- Zijn alle PHP-processen herstart? Zonder herstart werkt de update niet.
- Wat is er met systemen op PHP 8.1 of ouder? Daarvoor zijn geen officiële updates. Wat is het plan?
- Is gecontroleerd of er vóór de update iets is gebeurd? Logs vanaf 20 oktober veiliggesteld, sporen gezocht?
Staat uw website bij een hostingprovider, dan helpt een formeel verzoek. Een voorbeeld biedt de gids PHP-updatebevestiging van de hostingprovider opvragen.
De beslissingen die vandaag moeten vallen
| Beslissing | Opties | Grondslag |
|---|---|---|
| Wie leidt? | een verantwoordelijk persoon intern, een externe partner | Verantwoordelijkheid moet eenduidig zijn |
| Niet-gepatchte systemen | direct patchen, tussentijdse maatregelen, tijdelijk uitschakelen | BSI-advies, gegevenssituatie, omzetrelevantie |
| Controle op sporen | intern, extern, alleen bij bijzonderheden | Beschermingsbehoefte van de gegevens op de server |
| Communicatie | intern informeren, klanten voorbereiden, afwachten | Situatie na de controle |
| Oude systemen | migratie plannen, isoleren, uitschakelen | PHP 8.1 en ouder zonder officiële updates |
Leg vast wie wat wanneer heeft besloten en op welke informatiegrondslag. Een korte, gedateerde notitie volstaat. Achteraf is ze tegenover verzekeraars, klanten of toezichthouders vaak meer waard dan elke latere verklaring.
Waarom deze documentatie voor de leiding belangrijk is, licht de pagina Aansprakelijkheid van de directie bij IT-beveiligingslekken toe. Dit is algemene informatie en geen juridisch advies.
Wat u niet moet geloven
Drie uitspraken horen bestuurders momenteel vaak, en alle drie zijn onjuist:
- „We hebben WordPress bijgewerkt, dus we zijn veilig.” Het lek zit in PHP, niet in het CMS. Een CMS-update dicht het niet.
- „We zijn te klein, ons valt niemand aan.” Aanvallen verlopen geautomatiseerd. Er wordt gezocht naar kwetsbare servers, niet naar bekende namen.
- „De update staat erop, dus het onderwerp is afgedaan.” Een patch verwijdert geen schadelijke software die eerder is binnengebracht en bewijst niet dat er niets is gebeurd.
Hoe helpt PHP SOS concreet?
- Overzicht voor de leiding: Wij maken een kort overzicht van uw PHP-systemen met status en advies per systeem.
- Uitvoering: Wij patchen, herstarten of stellen tussentijdse maatregelen in waar een update nog niet mogelijk is.
- Controle: Wij stellen logs veilig en controleren op sporen van een aanval.
- Bewijs: U ontvangt een documentatie die u intern en tegenover derden kunt gebruiken.
Het verloop beschrijft de PHP2Shell-noodhulp.
Conclusie
PHP2Shell is een technisch lek met een managementtaak. De techniek handelen vakmensen af. De directie zorgt ervoor dat iemand verantwoordelijk is, dat de vijf vragen worden beantwoord en dat beslissingen bewust vallen en worden gedocumenteerd. Dat past in één ochtend, als het vandaag begint.
Veelgestelde vragen
Moet de directie zich zelf met PHP2Shell bezighouden?
Niet met de technische uitvoering, wel met de aansturing. De directie moet erop toezien dat verantwoordelijkheden duidelijk zijn, het BSI-advies wordt uitgevoerd en beslissingen zoals een tijdelijke uitschakeling bewust worden genomen en gedocumenteerd.
Hoe leg ik het lek in één zin uit?
In PHP, de software waarop de meeste websites en webshops draaien, zitten twee kritieke fouten waardoor vreemden zonder wachtwoord programma's op de server kunnen starten; er is een update beschikbaar die moet worden ingespeeld.
Wat kost het om niets te doen?
Dat is niet algemeen te becijferen. Mogelijke gevolgen van een geslaagde aanval zijn uitvaltijd, gegevenslekken, meldplichten, kosten voor opschoning en forensisch onderzoek en vertrouwensverlies bij klanten. Een update met controle is in de regel aanzienlijk minder werk.
Volstaat het als de hostingprovider het regelt?
Bij shared hosting speelt de hostingprovider de update in de regel in. Laat u dat schriftelijk bevestigen, inclusief herstart van de PHP-processen. Of er vóór de update iets is gebeurd, beantwoordt de bevestiging niet; daarvoor is een controle van de website nodig.