PHP-lek (PHP2Shell): welke update is nodig en wat doet u?

Wat is het PHP-lek, ook wel PHP2Shell genoemd?

PHP2Shell is de naam die in de berichtgeving wordt gebruikt voor twee ernstige PHP-kwetsbaarheden: CVE-2026-109618 en CVE-2026-109619. Via deze fouten kan een aanvaller zonder inloggen eigen code op een webserver uitvoeren. PHP is de software waarmee veel websites onder meer formulieren, accounts en aanvragen verwerken.

Het PHP-project waarschuwt voor installaties die webverzoeken verwerken, waaronder PHP-FPM en Apache met mod_php. PHP noemt het risico bij mod_php het hoogst. De gevolgen voor uw website hangen af van de installatie, toegepaste reparaties en eventuele aanvallen. De algemene waarschuwing vertelt nog niet of uw website daadwerkelijk is misbruikt.

Bron: PHP: beveiligingsadvies en releases van 21 oktober 2026

Welke PHP-versies bevatten de oplossing?

De eerste officiële versies met beide oplossingen zijn PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. PHP publiceerde deze beveiligingsupdates voor de ondersteunde stabiele reeksen op 21 oktober 2026.

Een leverancier kan de reparaties ook verwerken in een eigen onderhoudspakket, met een ander versienummer. Vraag daarom naar bevestiging voor beide CVE-nummers. Het nummer van een WordPress-versie of een losse plug-in zegt niet welke PHP-reparatie op de server is toegepast.

PHP 8.1 en ouder krijgen geen gewone beveiligingsupdates meer van het PHP-project. Sommige leveranciers leveren langer onderhoud. Het PHP-team heeft voor deze noodsituatie ook minimale broncode-aanpassingen voor 7.4, 8.0 en 8.1 beschikbaar gesteld. Dat maakt die reeksen niet opnieuw ondersteund. Laat uw beheerder de passende leverancieroplossing of overstap naar een ondersteunde reeks regelen.

Bron: PHP: beveiligingsadvies en releases van 21 oktober 2026

Hoe controleer ik mijn WordPress-site of webshop?

Controleer eerst welke PHP-versie uw website gebruikt. In WordPress vindt u die bij Gereedschap > Sitediagnose > Informatie > Server. De namen verschillen per taal. Kijk bij een webshop ook in het hostingpaneel of vraag uw beheerder naar de PHP-installatie van de winkel. Vraag daarna of beide kwetsbaarheden op juist die installatie zijn verholpen.

Een WordPress-update of beveiligingsplug-in lost dit PHP-lek niet op. Volgens WordPress zitten deze kwetsbaarheden in PHP zelf en is hiervoor een PHP-update nodig. Een update van WordPress, een thema of een plug-in verhelpt die onderliggende fout niet. Tijdelijke filters vervangen de PHP-reparatie evenmin.

Het versienummer is een eerste controle, geen bewijs dat uw site niet is gehackt. Uw hoster kan beveiligingsreparaties in een eigen pakket verwerken. Laat bij onbekende beheerdersaccounts, onverwachte bestandswijzigingen of andere aanwijzingen voor misbruik onderzoek doen. Alleen een geslaagde scan of een werkende website geeft geen zekerheid over eerder misbruik.

Bron: WordPress: Critical PHP Security Release (21 oktober 2026) · PHP: beveiligingsadvies en releases van 21 oktober 2026 · WordPress: wat te doen bij een vermoedelijk gehackte website

Hoe werk ik de PHP-versie van mijn server bij?

Bij gedeelde of beheerde hosting regelt u de PHP-update via uw hoster of het hostingpaneel. Er is geen universele WordPress-knop die PHP op de server bijwerkt. De precieze stappen hangen af van uw hostingpakket. De beheerder van een eigen server installeert de beveiligingsupdate via de gebruikte leverancier en controleert ook de actieve webserverprocessen.

Laat bij een mislukte update de bereikbaarheid beperken en zoek met de hoster een veilige oplossing. Zet een publiek bereikbare site niet zomaar terug naar een kwetsbare PHP-versie. Houd de technische reparatie en eventueel onderzoek naar eerder misbruik allebei op de actielijst.

• Leg met de hoster vast welke gerepareerde versie of pakketupdate voor uw installatie nodig is. Gebruik de versies hierboven als uitgangspunt.
• Zorg voor een herstelbare back-up. Controleer vooral bij een overstap naar een andere PHP-reeks of WordPress, thema, plug-ins en webshop die ondersteunen. Stel de noodreparatie niet onnodig uit.
• Laat de hoster of beheerder de update toepassen en bevestigen dat alle relevante websites en processen de reparatie gebruiken.
• Controleer daarna de PHP-versie en test inloggen, formulieren, bestellen en betalen. Spreek af wie fouten opvolgt en herstel bevestigt.

Bron: PHP: beveiligingsadvies en releases van 21 oktober 2026 · WordPress: Critical PHP Security Release (21 oktober 2026) · WordPress: PHP bijwerken via uw hostingbedrijf

Welke vragen stel ik nu aan mijn hostingbedrijf?

Vraag om een antwoord voor uw eigen website of server. Alleen de mededeling dat de hoster met updates bezig is, bevestigt nog niet dat uw installatie is bijgewerkt. Met deze checklist maakt u het antwoord controleerbaar:

Een korte eigen mail volstaat. Bijvoorbeeld: 'Wilt u voor mijn website bevestigen welke PHP-versie of pakketupdate beide kwetsbaarheden verhelpt, wanneer die is toegepast en of onderzoek naar mogelijk eerder misbruik nodig is?' Bewaar het antwoord en spreek af wie open punten opvolgt.

• Welke PHP-versie of welk onderhoudspakket gebruikt mijn website?
• Zijn CVE-2026-109618 en CVE-2026-109619 beide verholpen, en wanneer?
• Zijn alle relevante sites en serverprocessen meegenomen en gecontroleerd?
• Moet toegang tijdelijk worden beperkt zolang de reparatie niet bevestigd is?
• Zijn er aanwijzingen voor eerder misbruik, wie onderzoekt die en wanneer krijg ik een update?

Bron: PHP: beveiligingsadvies en releases van 21 oktober 2026 · WordPress: Critical PHP Security Release (21 oktober 2026) · WordPress: wat te doen bij een vermoedelijk gehackte website

Moet mijn website offline zolang de update ontbreekt?

Laat uw beheerder per systeem beoordelen of tijdelijke afscherming nodig is zolang de reparatie ontbreekt. Het NCSC adviseerde op 21 oktober zo'n risicoafweging voor PHP-systemen die via internet bereikbaar zijn. Het haalde ook de eigen website uit voorzorg tijdelijk offline.

Een gewone onderhoudspagina in WordPress is niet vanzelf een veilige afscherming: volgens PHP kan een aanval plaatsvinden voordat de toepassing zelf wordt uitgevoerd. Laat uw beheerder de toegang op het juiste niveau beperken. Spreek ook af hoe klanten of medewerkers u tijdens de onderbreking kunnen bereiken.

Bron: NCSC via Rijksoverheid: ernstige kwetsbaarheden in PHP (21 oktober 2026) · PHP: beveiligingsadvies en releases van 21 oktober 2026

Waar controleer ik of een website of app nog offline is?

Controleer de eigen storingspagina, appmelding of helpdesk van de dienst. Voor DigiD en MijnOverheid kunt u beginnen bij het officiële overzicht Storing en onderhoud van Logius, via de bron hieronder. Kijk naar de genoemde dienst, datum, laatste update en de melding dat een storing is afgelopen. Een melding van eerder vandaag kan alweer achterhaald zijn.

Is ook de statuspagina onbereikbaar, gebruik dan een bekend contactkanaal van de organisatie en controleer later opnieuw. Een foutmelding op uw eigen apparaat bewijst geen landelijke storing. Een werkende homepage bewijst evenmin dat inloggen, betalen of alle onderdelen van een app weer werken. Deze blog houdt daarom geen live lijst met getroffen diensten bij.

• Controleer bij een dringende aanvraag of betaling of er een officieel alternatief is en of een termijn blijft gelden. Bewaar uw bevestigingen en noteer wanneer u contact zocht.
• Gebruik een bekend webadres of contactkanaal. Geef geen wachtwoord of inlogcode door via onverwachte berichten over het PHP-lek.

Bron: Logius: officieel overzicht Storing en onderhoud · Veiliginternetten.nl: wat kan ik doen als ik gehackt ben?

Mijn site werkt weer of is bijgewerkt: is onderzoek nog nodig?

Een bereikbare website bewijst niet dat eerder misbruik is uitgebleven. De PHP-update verhelpt de bekende kwetsbaarheden, maar beantwoordt niet vanzelf of iemand daarvoor toegang heeft gehad. Laat bij aanwijzingen voor een incident de hoster of een deskundige onderzoeken wat er is gebeurd.

Noteer waarnemingen, tijdstippen, uitgevoerde maatregelen en ontbrekende informatie. Bewaar relevante logbestanden en bewijs met beperkte toegang. Spreek af wie controleert of herstel is geslaagd en wanneer de volgende beoordeling volgt. WordPress adviseert bij een vermoedelijke hack onder meer documentatie, contact met de hoster en onderzoek naar de oorzaak.

Bron: PHP: beveiligingsadvies en releases van 21 oktober 2026 · WordPress: wat te doen bij een vermoedelijk gehackte website

Welk document past: incidentresponsplan of beveiligingsbeleid?

Een incidentresponsplan past als uw organisatie nog geen gedeelde afspraken heeft voor een digitaal incident: wie neemt de leiding, wie onderzoekt, wie besluit over afscherming en herstel, en wie communiceert? Begin gratis met de vragen aan uw hoster en een eigen bellijst. Wilt u die aanpak daarna bundelen, dan helpt ons incidentresponsplan voor cybersecurity om rollen, bereikbaarheid, opschaling, communicatie en herstel vast te leggen. Controleer en oefen het plan met uw team.

Voor vaste afspraken over het dagelijks beschermen van informatie past informatiebeveiligingsbeleid. Voor de interne aanpak van mogelijke datalekken past datalekbeleid. Onze uitleg over beveiligingsbeleid en een incidentplan helpt het verschil te bepalen. Een nieuw document is geen technische noodmaatregel en toont op zichzelf geen volledige wettelijke naleving aan.

Bron: WordPress: wat te doen bij een vermoedelijk gehackte website · EDPB: datalekken, meldtermijnen en het informeren van personen

Is het PHP-lek automatisch een datalek dat ik moet melden?

Nee. Een kwetsbaarheid betekent niet automatisch dat persoonsgegevens zijn geraakt. Laat bij aanwijzingen voor een incident onderzoeken of gegevens onbevoegd zijn ingezien, gewijzigd, verloren gegaan of onbeschikbaar zijn geworden. Onze uitleg over een vermoedelijk datalek in het eerste uur helpt de eerste acties te ordenen.

Een meldplichtig datalek meldt de verantwoordelijke organisatie zonder onnodige vertraging en zo mogelijk binnen 72 uur na kennisname aan de bevoegde toezichthouder, in Nederland doorgaans de AP. Melding hoeft niet als een risico voor personen onwaarschijnlijk is. Kennisname betekent dat u redelijk zeker weet dat een beveiligingsincident persoonsgegevens heeft geraakt. De termijn begint dus niet automatisch bij het nieuws over PHP. Ontbrekende informatie bij een verplichte melding kan later worden aangevuld.

Bij waarschijnlijk hoog risico moet u ook de betrokken personen zonder onnodige vertraging informeren, tenzij een wettelijke uitzondering geldt. De 72 uur is geen algemene wachttijd om klanten te waarschuwen. Lees daarvoor de uitleg over een datalek aan klanten melden. Ontbreekt voor toekomstige incidenten een vaste interne meld- en onderzoeksroute, dan kunt u die na de acute aanpak vastleggen in een datalekbeleid. Dat beleid verzendt geen melding en vervangt uw risicoafweging niet.

Bron: EDPB: datalekken, meldtermijnen en het informeren van personen

Ik ben klant van een getroffen website: wat doe ik zelf?

Controleer via een bekend contactkanaal of uw persoonsgegevens bij een vastgesteld incident betrokken zijn. Een offline website kan een voorzorgsmaatregel zijn. Bewaar bij een lopende bestelling of aanvraag uw bevestiging en vraag de organisatie hoe u tijdens de onderbreking contact houdt.

U kunt gratis vragen: 'Zijn mijn persoonsgegevens bij dit incident betrokken, welke gegevens zijn dat en welke maatregelen moet ik zelf nemen?' Geef geen inlogcodes door via onverwachte berichten. Zijn inloggegevens geraakt, volg dan de beveiligingsinstructies van de dienst en wijzig ook elders hetzelfde wachtwoord. Bekijk bij getroffen identiteitsbewijsgegevens of een BSN de overheidsinformatie over identiteitsfraude.

Bron: NCSC via Rijksoverheid: ernstige kwetsbaarheden in PHP (21 oktober 2026) · Rijksoverheid: ik ben slachtoffer van een datalek, wat kan ik doen? · Veiliginternetten.nl: wat kan ik doen als ik gehackt ben?

Wanneer past een AVG-inzageverzoek of privacyklacht?

Een AVG-inzageverzoek past wanneer u wilt weten welke persoonsgegevens een organisatie van u verwerkt en om de bijbehorende informatie wilt vragen, zoals doelen en ontvangers. Lees eerst de uitleg over persoonsgegevens inzien. Voor alleen de vraag of uw gegevens bij een incident betrokken zijn, kunt u beginnen met de korte eigen mail hierboven.

Wilt u een eerste of aanvullende inzagevraag schriftelijk vastleggen, dan is het AVG-inzageverzoek persoonsgegevens een optionele hulp. U mag uw verzoek ook zelf schrijven; een betaald document is niet verplicht. Heeft u concrete aanwijzingen voor verkeerd gebruik van uw gegevens, lees dan de uitleg over een privacyklacht aan de organisatie. Een inzageverzoek of klacht bewijst op zichzelf niet dat dit PHP-lek bij uw account is misbruikt.

Bron: Rijksoverheid: privacyrechten en reactietermijnen onder de AVG · EDPB: privacyrechten en verzoeken van personen