Kort gezegd: Of u een website vanwege het PHP-lek offline moet halen, hangt aan één vraag: draait PHP op deze server aantoonbaar op een verholpen stand en zijn alle processen herstart? Zo ja, dan is uitschakeling niet nodig. Als de update niet direct mogelijk is, adviseert het BSI de webserver tijdelijk van het netwerk te halen. Afwachten is alleen verdedigbaar als het systeem geen PHP gebruikt, niet openbaar bereikbaar is of de aanbieder de patch schriftelijk heeft bevestigd.
De situatie waarin u moet beslissen
PHP2Shell omvat twee lekken in PHP zelf, CVE-2026-109618 en CVE-2026-109619, beide beoordeeld met CVSS v4.0 9.2. Ze maken uitvoering van schadelijke code op afstand mogelijk zonder aanmelding. Verholpen versies zijn beschikbaar sinds 21 oktober 2026: 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor PHP 8.1 en ouder bestaan geen officiële updates meer.
Het BSI (Duitse federale dienst voor informatiebeveiliging) heeft waarschuwingsniveau Oranje afgegeven en adviseert de directe update, bij gebrek daaraan de tijdelijke uitschakeling. Volgens mediaberichten hebben de stad Mainz, diensten van de Hessische landsregering en andere openbare instellingen websites preventief offline gehaald; de Hessische Staatskanzlei meldde geen aanval. Wat bedrijven daaruit kunnen afleiden, staat onder Overheden halen websites offline.
Voor verantwoordelijken in bedrijven is de vraag praktischer: wat doen we vandaag met onze shop, ons portaal, onze bedrijfswebsite?
Website offline halen, patchen of afwachten: de drie opties vergeleken
De volgende tabel zet de opties naast elkaar. Ze vervangt niet de beoordeling van uw individuele geval, maar maakt de afweging zichtbaar.
| Criterium | Direct patchen | Tijdelijk uitschakelen | Afwachten |
|---|---|---|---|
| Bescherming tegen PHP2Shell | Hoog, als patch en herstart zijn aangetoond | Hoog voor de duur van de uitschakeling | Geen, zolang niet gepatcht |
| Bedrijfsonderbreking | Kort, voor update en herstart | Uren tot dagen | Geen |
| Voorwaarde | Ondersteunde PHP-versie, toegang, onderhoudsvenster | Besluit van de directie, statische vervangende pagina | Aangetoonde reden waarom er geen risico bestaat |
| Inspanning | Laag tot middel | Technisch laag, organisatorisch hoog | Laag, maar controle-inspanning voor het bewijs |
| Typisch geval | Server met PHP 8.2 tot 8.5 | Oud systeem met PHP 8.1 of ouder, onduidelijke stand | Systeem zonder PHP of alleen intern bereikbaar |
| Restrisico | Eerdere inbraak blijft mogelijk | Eerdere inbraak blijft mogelijk | Volledig aanwezig |
Eén regel verdient aandacht: noch patch noch uitschakeling verduidelijkt of er eerder al iets is gebeurd. Volgens mediaberichten was de eerste waargenomen aanvalspoging op 17 oktober 2026, dus vóór de patch. Een blik op mogelijke sporen hoort daarom bij elke optie.
In vijf vragen naar het besluit
Werk de vragen de een na de ander af. Het eerste duidelijke antwoord leidt meestal tot de beslissing.
- Draait er op het systeem überhaupt PHP, en is het vanaf internet bereikbaar? Zo nee, dan is het systeem niet direct door PHP2Shell getroffen. Documenteer hoe u dat hebt vastgesteld.
- Is de patchstatus aangetoond? Aangetoond betekent: verholpen versie of backport met CVE-nummers in de pakket-changelog en herstart van alle PHP-processen. Een versieweergave in het paneel volstaat niet. Hoe u dat controleert, leest u onder PHP-versie en patchstatus juist controleren.
- Kan de update de komende uren worden geïnstalleerd? Zo ja: patchen, herstarten, controleren. Tot dan kunnen overbruggende maatregelen helpen.
- Is dat niet mogelijk, bijvoorbeeld door PHP 8.1 of ontbrekende toegang? Dan is de tijdelijke uitschakeling volgens het BSI de weg. Overbruggende maatregelen volgens php.net verlagen het risico, maar beschermen niet volledig; de details staan onder Noodmaatregelen als u nog niet kunt patchen.
- Zijn er tekenen van compromittering? Dan is de vraag niet meer „patchen of uitschakelen“, maar „incident afhandelen“. Uitschakelen, bewijs veiligstellen, niet voorbarig verwijderen.
Als u uitschakelt: juist uitschakelen
Een uitschakeling moet het aanvalsoppervlak verwijderen, niet alleen de startpagina verbergen. Een onderhoudspagina die nog door PHP wordt gegenereerd, vervult dit doel niet. Beter is een statische HTML-pagina die de webserver zonder PHP uitlevert, of een doorverwijzing naar een andere server.
Denk aan alles wat aan dezelfde PHP hangt: subpagina's, koppelingen voor apps of warenbeheer, beheerdersomgevingen, betalingscallbacks. Overleg vooraf met betaalaanbieder en logistiek als een shop is getroffen. En informeer medewerkers en klanten in heldere taal: de pagina is preventief offline, contact verloopt via telefoon en e-mail. Dat is beter dan zwijgen, dat speculaties voedt.
Belangrijk is ook het einde van de uitschakeling. Leg vast onder welke voorwaarde de pagina weer online gaat, bijvoorbeeld „PHP op verholpen stand, herstart gecontroleerd, eerste sporencontrole zonder bevinding“. Zo wordt van een noodrem een geordend proces.
Uitschakelen is geen nederlaag. Meerdere openbare instanties hebben volgens mediaberichten precies dat gedaan zonder dat er een aanval was. Een preventieve uitschakeling betekent niet automatisch dat een website is gehackt.
Wanneer u geen dienstverlener nodig hebt
Niet elke beslissing vereist externe hulp. Als uw website bij een hoster staat die de patchstatus en de herstart schriftelijk bevestigt, en er geen bijzonderheden zijn, bent u met een korte documentatie goed gedekt. Hetzelfde geldt als uw eigen IT een server met ondersteunde PHP-versie zelf kan patchen en de controle beheerst.
Hulp loont als systemen met een oude PHP-versie draaien, de stand onduidelijk is, meerdere servers zijn getroffen of er tekenen van een inbraak zijn.
Hoe helpt PHP SOS concreet?
- Wij stellen met u in korte tijd vast welke systemen zijn getroffen en welke patchstatus is aangetoond.
- Wij leveren de directie een beslisgrondslag op één pagina: opties, risico's, aanbevolen weg.
- Wij voeren de gekozen weg uit, dus patch met herstart, overbruggende maatregelen of een nette uitschakeling met statische vervangende pagina, als onderdeel van onze PHP2Shell-noodhulp.
- Wij controleren op sporen sinds 17 oktober 2026 en documenteren het resultaat.
Conclusie
Patchen is de normale gang van zaken, uitschakelen de juiste noodrem, afwachten alleen met bewijs verdedigbaar. Wie de vijf vragen eerlijk beantwoordt en het besluit schriftelijk vastlegt, handelt in de geest van het BSI-advies en kan later laten zien waarom.
Veelgestelde vragen
Moet ik mijn website vanwege PHP2Shell offline halen?
Niet als PHP al op een verholpen stand draait en alle processen zijn herstart. Het BSI adviseert de tijdelijke uitschakeling voor het geval dat een directe update niet mogelijk is.
Wat kost een uitschakeling meer: omzet of risico?
Dat is alleen per geval te beantwoorden. Een uitval van uren is meestal beter te plannen dan een inbraak waarvan niemand de gevolgen en duur kent. Leg de afweging schriftelijk vast, ongeacht hoe ze uitpakt.
Mag een onderhoudspagina via dezelfde server draaien?
Ja, als ze als statisch bestand zonder PHP wordt uitgeleverd. Wordt de onderhoudspagina nog door PHP gegenereerd, dan blijft het aanvalsoppervlak bestaan.
Is afwachten ooit de juiste keuze?
Ja, in duidelijk afgebakende gevallen: als op het systeem geen PHP draait, als het niet vanaf internet bereikbaar is of als de aanbieder patch en herstart schriftelijk heeft bevestigd. Afwachten zonder zulk bewijs is geen optie, maar een risico.
Wie moet de beslissing nemen?
De persoon die het bedrijfsrisico verantwoordt, in de regel directie of eigenaar. De IT levert de feiten. Wie beslist, moet vooraf in het noodplan staan.