PHP lek controleren en oplossen op je website

Een PHP lek op je website vraagt om een update van PHP op de server. Alleen WordPress, plugins of thema’s bijwerken verhelpt dit lek niet. De melding van oktober 2026, ook bekend als PHP2Shell, gaat over twee kritieke kwetsbaarheden waarvoor het PHP-team beveiligingsupdates heeft uitgebracht. Vraag je hoster welke reparatie jouw website gebruikt en of die al actief is.

Deze controlehulp is voor website-eigenaren die het PHP lek willen laten oplossen. Je vindt hier de gerepareerde versies, een checklist voor je beheerder en een voorbeeldbericht aan je hoster. Je hoeft zelf geen serverinstellingen te wijzigen. Het artikel stelt niet vast of jouw website kwetsbaar is of eerder is misbruikt; daarvoor zijn gegevens over je eigen omgeving nodig.

Zoek je vooral wat het nieuws betekent en waarom websites offline gaan? Lees PHP lek voor dummies. Die beginnersuitleg is voor bezoekers zonder technische kennis. Hieronder gaat het om de controle en reparatie van je eigen website.

Samenvatting

• Dit PHP lek betreft PHP op de server. Een update van WordPress, plugins of thema’s werkt PHP niet automatisch bij.
• De PHP versie in WordPress geeft een beginpunt voor een gesprek met de hoster over de gebruikte software.
• Een beveiligingsbericht, de volledige pakketversie en informatie over de uitrol helpen om de reparatiestatus te beoordelen.
• Leveranciers beschrijven tijdelijke filtering als aanvulling op een reparatie. Onderzoek naar mogelijk eerder misbruik is een afzonderlijk onderwerp.

Welke websites moet je op dit PHP lek laten controleren?

Dit PHP lek raakt software die veel websites delen. WordPress gebruikt PHP om onder andere pagina’s op te bouwen en het beheer mogelijk te maken. Ook systemen zoals Drupal, Magento, Joomla en Laravel gebruiken PHP. Het risico hangt af van de PHP omgeving waarop zo’n toepassing draait.

Het officiële PHP beveiligingsbericht bevestigt dat beide kwetsbaarheden uitvoering van code op afstand mogelijk kunnen maken, zonder eerst in te loggen. PHP noemt alle installaties die webverzoeken verwerken als risicogroep, waaronder PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Dat kan gevolgen hebben voor bestanden of gegevens die voor het getroffen proces toegankelijk zijn.

Hoeveel schade mogelijk is, hangt onder meer af van de rechten waarmee PHP draait. Code uitvoeren via PHP betekent niet automatisch dat een aanvaller alle beheerdersrechten van de volledige server heeft. PHP beoordeelt het risico bij mod_php als het hoogst: daar is een aanval aangetoond die al vóór het uitvoeren van applicatiecode kan worden gestart.

Hoe ernstig is een score van 9,2?

PHP kent beide kwetsbaarheden een CVSS score van 9,2 toe. Die score valt in de categorie kritiek en beschrijft de technische ernst volgens dat beoordelingssysteem. Het is geen kansberekening: je kunt er niet uit afleiden dat een website 92 procent kans heeft om gehackt te worden. De score alleen bepaalt ook niet de situatie van een specifieke website.

Wat zeggen meldingen van aanvallen over een website?

Patchstack meldt incidenten bij hostingpartners. Die melding bevat geen betrouwbaar totaal van overgenomen websites en is geen beoordeling van jouw website. In berichtgeving kunnen de volgende begrippen voorkomen:

• Kwetsbaar: de fout is aanwezig en kan onder bepaalde voorwaarden bereikbaar zijn.
• Aangevallen: iemand probeert de fout te gebruiken.
• Gecompromitteerd: er is aantoonbaar ongewenste toegang of uitvoering geweest.

De bereikbaarheid van je website bewijst niet dat het PHP lek is verholpen. Vraag om gegevens over de gebruikte software en om een afzonderlijke beoordeling van eventuele aanvalssporen. Een bevestigde update vertelt welke fout is gerepareerd; die bevestiging zegt niet of er vóór de update al misbruik heeft plaatsgevonden.

Waarom verhelpt een WordPress update het PHP lek niet?

Het updateoverzicht in WordPress laat zien welke updates voor WordPress, plugins en thema’s klaarstaan. PHP draait op de server en heeft een eigen updateproces. Uit het WordPress overzicht alleen kun je daarom niet afleiden welke PHP reparaties zijn toegepast. De onderstaande taakverdeling is gebruikelijk, maar kan per onderhoudsovereenkomst verschillen.

Bij beheerde hosting verzorgt de hostingpartij doorgaans het PHP onderhoud. Bij een eigen server kan die taak bij de eigenaar of ontwikkelaar liggen. Je onderhoudsovereenkomst beschrijft wie waarvoor verantwoordelijk is. Een websitebouwer en hoster kunnen ieder een ander deel van de omgeving beheren; de naam van het hostingpakket geeft daar niet altijd volledig inzicht in.

Een inventarisatie kan ook een testsite, webshop op een subdomein of los beheerpaneel omvatten. Die onderdelen kunnen andere PHP versies gebruiken dan de hoofdwebsite. Aan de zichtbare voorkant van een website kun je niet altijd herkennen welke software erachter draait. Je beheerder kan toelichten welke omgevingen actief zijn en welke daarvan onder het onderhoud vallen.

Onze uitleg over WordPress onderhoud beschrijft welke werkzaamheden en afspraken daarbij kunnen horen. Voor dit PHP lek is daarnaast informatie nodig over het PHP pakket dat de website gebruikt. Dat is een andere vraag dan welke WordPress updates zijn uitgevoerd.

Je PHP versie controleren na de melding van het PHP lek

Je kunt de PHP versie die WordPress ziet meestal zelf vinden in Sitediagnose. Dit helpt je om je hoster de juiste informatie te geven. Het scherm bewijst nog niet dat de reparatie voor het PHP lek is toegepast.

1. Log in op het beheer van je eigen WordPress website.
2. Ga naar Gereedschap → Sitediagnose.
3. Open het tabblad Informatie.
4. Klap Server open en zoek naar PHP versie.
5. Noteer het volledige nummer, het websiteadres en het tijdstip van je controle.

Sitediagnose is niet voor ieder account toegankelijk. Als je het onderdeel niet ziet, kan de beheerder de gegevens mogelijk voor je opzoeken. De PHP versie bekijken is iets anders dan de versie wijzigen. Voor een wijziging beoordeelt een beheerder doorgaans eerst of de gebruikte websiteonderdelen ermee kunnen werken en welke controle achteraf nodig is.

Wat kun je met dat versienummer?

Je weet nu welke PHP versie WordPress rapporteert. Je hoster kan die vergelijken met het officiële beveiligingsbericht en met de eigen pakketgegevens. Zet een screenshot eventueel in je bericht aan de beheerder, maar deel geen volledig overzicht met servergegevens openbaar.

Een controle in de terminal is niet automatisch hetzelfde. Een server kan meerdere PHP installaties hebben. Vraag daarom naar de omgeving die bezoekersverzoeken voor jouw website verwerkt. Ook een PHP versienummer in een HTTP header, informatie die een server meestuurt, is geen volledige beveiligingscontrole.

Waarom een ouder versienummer toch gerepareerd kan zijn

Een leverancier kan een beveiligingsreparatie verwerken in een bestaand softwarepakket. Dat heet een backport. Het zichtbare PHP versienummer lijkt dan misschien oud, terwijl het pakket wel een reparatie bevat. Red Hat legt uit waarom alleen op versienummers controleren misleidend kan zijn.

De algemene uitleg over backports zegt nog niets over jouw hostingpakket. Voor een beoordeling zijn de volledige pakketversie, eventuele revisie en het beveiligingsbericht van de leverancier relevant. Daarin kan staan welke reparatie bij welk CVE nummer hoort. Als die informatie ontbreekt, blijft de reparatiestatus op basis van alleen het versienummer onduidelijk.

Welke PHP updates verhelpen dit PHP lek?

PHP heeft de officiële updates voor dit PHP lek gepubliceerd: PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Het beveiligingsbericht noemt alle PHP installaties die webverzoeken verwerken als risicogroep en roept gebruikers op direct bij te werken. Een bepaalde hostingvorm, zoals PHP-FPM, is dus op zichzelf geen reden om de update over te slaan.

Onderstaand overzicht noemt de releases die beide kwetsbaarheden verhelpen. De ondersteuningsstatus komt van PHP zelf. Ondersteuning betekent dat een reeks nog updates ontvangt, niet dat iedere geïnstalleerde versie al tegen dit PHP lek beschermd is.

Gecontroleerd op 21 oktober 2026 om 15.45 uur Nederlandse tijd aan de hand van het officiële PHP beveiligingsbericht, de changelogs en de ondersteuningspagina. De minimale broncodepatches voor oudere reeksen zijn geen hervatting van de reguliere ondersteuning.

De septemberreleases 8.2.34, 8.3.35, 8.4.26 en 8.5.11 bevatten deze reparaties niet. Voor leverancierspakketten kan een beveiligingsreparatie in een oudere pakketversie zijn verwerkt. Vraag je hoster daarom om het eigen beveiligingsbericht en de volledige pakketversie; alleen het zichtbare PHP versienummer is dan niet genoeg.

Het PHP lek oplossen en de reparatie met je hoster controleren

De geraadpleegde beveiligingsmeldingen wijzen naar een PHP update als reparatie voor de gemelde fouten. Wat zo’n update voor een website inhoudt, hangt af van het gebruikte pakket en de hostingvorm. Het PHP lek oplossen vraagt daarom ook om controle van de uitrol: welke software is geïnstalleerd en welke software verwerkt de verzoeken van bezoekers?

Checklist voor de reparatie van het PHP lek

1. De omgeving. Welke websites, testsites en toepassingen zijn gecontroleerd? Welke PHP pakketten gebruiken ze?
2. De reparatie. Welk officieel bericht of leveranciersbericht bevestigt dat beide kwetsbaarheden zijn verholpen?
3. De uitrol. Wanneer is het gerepareerde pakket op jouw omgeving geïnstalleerd?
4. De actieve software. Is gecontroleerd dat de processen die jouw website bedienen de nieuwe code gebruiken?

Installatie en actief gebruik zijn afzonderlijke stappen. Een proces kan na installatie nog eerder geladen code gebruiken; afhankelijk van de omgeving kan een herstart nodig zijn. Bij containers, afzonderlijk verpakte softwareomgevingen, is ook van belang welke versie in gebruik is genomen. De beheerder kan aangeven welke stappen voor jouw hostingomgeving gelden.

Een functionele controle laat zien of bijvoorbeeld formulieren en afrekenen na een update nog werken. Dat geeft andere informatie dan een controle op de reparatiestatus. Bij een website met bestellingen zijn andere functies relevant dan bij een eenvoudige informatieve site. In onderhoudsafspraken kan staan welke controles worden uitgevoerd en hoe problemen worden teruggekoppeld.

Dit bericht kun je naar je hostingprovider sturen

Hallo, willen jullie voor mijn website controleren of het PHP lek bekend als PHP2Shell is verholpen? Het gaat om CVE-2026-109618 en CVE-2026-109619.

Ik ontvang graag de PHP versie en volledige pakketversie, het beveiligingsbericht dat de reparatie bevestigt en het tijdstip waarop de update voor mijn omgeving is uitgerold. Willen jullie ook bevestigen dat mijn website de bijgewerkte PHP software daadwerkelijk gebruikt?

Neem eventuele testsites, subdomeinen en andere PHP toepassingen mee. Als repareren nog niet mogelijk is, hoor ik graag welke tijdelijke maatregelen gelden en wat de beperkingen zijn. Zijn er aanvalspogingen of aanwijzingen voor geslaagd misbruik gevonden?

Met “alle updates zijn uitgevoerd” kan een leverancier verschillende onderdelen bedoelen. Een toelichting op de PHP pakketversie en de twee registratienummers maakt het antwoord beter te beoordelen. Zo’n bevestiging beschrijft de uitgevoerde werkzaamheden. Ze is geen algemene garantie dat een omgeving vrij is van andere kwetsbaarheden of van eerder ontstaan misbruik.

Heb je vragen over deze uitleg? Je kunt contact opnemen met webwrk om websiteonderhoud te bespreken. Een websiteadres en een korte omschrijving van je vraag zijn voldoende voor een eerste gesprek. Deel geen wachtwoorden of gevoelige logbestanden via het algemene contactformulier.

Beschermen Cloudflare, Wordfence of tijdelijke instellingen?

Bij tijdelijke maatregelen is het nuttig om onderscheid te maken tussen het filteren van verzoeken en het aanpassen van de kwetsbare software. Welke bescherming een firewall biedt, hangt onder meer af van de actieve regels en de manier waarop verkeer de server bereikt. De geraadpleegde leveranciersmeldingen geven geen algemene garantie voor iedere website.

Welke tijdelijke bescherming biedt Cloudflare bij dit PHP lek?

Volgens de door Patchstack aangehaalde melding van Cloudflare zijn regels ingesteld tegen bekende aanvalsvormen. Cloudflare beschrijft die als tijdelijke bescherming. De dekking voor een specifieke website hangt mede af van de instellingen en van eventueel rechtstreeks verkeer naar de server. Dat zijn punten die een hoster kan toelichten; uit het gebruik van Cloudflare alleen volgt geen conclusie over de reparatiestatus.

Beschermt Wordfence tegen het PHP lek?

De aanwezigheid van een Wordfence plugin bewijst niet dat je website tegen het PHP lek beschermd is. Een WordPress plugin werkt binnen de applicatie, terwijl bepaalde verwerking door PHP al eerder kan plaatsvinden. Zonder informatie over de specifieke bescherming en de PHP omgeving kunnen we daarom niet vaststellen wat de plugin in een individuele situatie tegenhoudt.

Kun je een instelling aanpassen of de website offline zetten?

Het officiële PHP beveiligingsbericht beschrijft tijdelijke instellingen die specifieke aanvalsroutes beperken wanneer direct bijwerken niet mogelijk is. PHP benadrukt dat deze maatregelen een installatie niet volledig beschermen. Alleen de update verhelpt de kwetsbaarheden. Laat een serverbeheerder beoordelen welke tijdelijke maatregelen bij jouw omgeving passen; rondgaande losse configuratieadviezen zijn geen vervanging voor de patch.

CERT-EU adviseert om isolatie van publiek bereikbare toepassingen te overwegen wanneer directe reparatie niet mogelijk is. Dat is geen algemeen advies dat iedere website offline moet. De afweging hangt af van de omgeving en de gevolgen van onbereikbaarheid. Een onderhoudspagina binnen WordPress kan nog steeds PHP gebruiken en zegt daardoor niet of die verwerking bereikbaar is.

Wat is het verschil tussen bijwerken, onderzoeken en onderhouden?

Een beveiligingsupdate is bedoeld om de beschreven softwarefout te verhelpen. Onderzoek naar eerdere toegang heeft een andere vraag: zijn er aanwijzingen dat iemand de omgeving al heeft misbruikt? De melding dat een update is uitgevoerd, beantwoordt die tweede vraag niet. Omgekeerd betekent een aanvalspoging in een logbestand niet automatisch dat de aanval geslaagd is.

Bij vermoedens van een inbraak kunnen logbestanden, tijdstippen en een momentopname informatie voor onderzoek bevatten. Opschonen kan die informatie veranderen of verwijderen. Een beheerder of incidentonderzoeker kan beoordelen welke gegevens eerst bewaard moeten worden. Een onverwacht account of gewijzigd bestand is een aanleiding voor nader onderzoek, maar vraagt context voordat je daar een conclusie aan verbindt.

Onderhoudsafspraken kunnen beschrijven wie software bijhoudt, beveiligingsmeldingen beoordeelt en updates controleert. Ook testomgevingen en herstel vanuit back-ups kunnen daarin worden meegenomen. Welke afspraken passen, hangt onder meer af van de websitefuncties en de hostingvorm. Ze geven inzicht in verantwoordelijkheden, zonder te garanderen dat er nooit een beveiligingsprobleem kan ontstaan.

In onze uitleg over website onderhoud lees je meer over die taakverdeling. Bij de PHP kwetsbaarheid van 21 oktober 2026 is vooral het onderscheid tussen applicatieonderhoud en serveronderhoud relevant. Welke maatregelen voor een individuele website nodig zijn, vraagt een beoordeling van de eigen omgeving.

Wat betekent de gebruikte techniek voor het onderhoud?

De term maatwerk beschrijft hoe een website is gebouwd en aangepast aan een organisatie. Hij zegt niet welke programmeertaal wordt gebruikt. Een maatwerk website kan dus PHP gebruiken, net als een website met WordPress. Het PHP lek is op zichzelf geen reden om je website te vervangen. Eerst is informatie nodig over de gebruikte software, de beschikbare reparatie en het onderhoud.

Een andere technische opzet brengt andere software en onderhoudstaken mee. Ook kan een nieuwe voorkant gekoppeld blijven aan een WordPress beheersysteem. Bij een eventuele overstap zijn daarom de volledige omgeving, functies, kosten en het beheer relevant. Dit artikel vergelijkt die oplossingen niet en doet geen uitspraak dat een bepaalde techniek een website automatisch veiliger maakt.

Wijzigingsoverzicht en bronnen

21 oktober 2026, 15.45 uur: php.net bevestigt dat de officiële patches beschikbaar zijn. Het statusblok, versieoverzicht, de uitleg over risico’s en tijdelijke maatregelen en het antwoord over gerepareerde versies zijn bijgewerkt. De onderstaande vermeldingen beschrijven eerdere controles, vóór publicatie van de patch.

21 oktober 2026, 14.04 uur: een verwijzing naar de afzonderlijke beginnersuitleg toegevoegd. De broncontrole van dit artikel blijft die van 13.37 uur.

21 oktober 2026, 13.49 uur: redactioneel aangepast naar een informatieve uitleg, met duidelijker onderscheid tussen bronmeldingen en de beoordeling van een individuele website. De broncontrole blijft die van 21 oktober om 13.37 uur; dit is geen nieuwe controle van de releasestatus.

21 oktober 2026, 13.37 uur: PHP vooraankondiging opnieuw gecontroleerd. Officiële getroffen en gerepareerde versies ontbreken nog. De controlehulp, het versieoverzicht en de vragen aan de hoster zijn opgesteld voor deze stand van zaken.

De bronlinks staan bij de betreffende uitleg. De PHP patchinformatie is bij de laatste update opnieuw gecontroleerd. Eerdere meldingen van andere organisaties zijn geen nieuwe incidentcontrole. De controletijd van dit artikel zegt niets over de reparatiestatus van een individuele website; daarvoor is bevestiging van de hoster nodig.