PHP2Shell: wat betekenen de PHP-updates voor je website?

De PHP-updates van oktober 2026 verdienen aandacht als je een website of applicatie beheert. Ook wanneer je vooral met WordPress werkt, of met AI code laat maken. De kwetsbaarheden zitten in de laag die PHP-code uitvoert. Een aanpassing aan je eigen pagina of prompt verhelpt dat probleem niet.

Ik zou bij dit nieuws beginnen met één concrete vraag aan de beheerder: welke PHP-versie verwerkt de bezoekers van mijn website, en is die inmiddels bijgewerkt? Daarmee heb je een bruikbaarder begin dan een algemeen bericht dat alle systemen worden gecontroleerd.

Op 21 oktober 2026 publiceerde het PHP-project beveiligingsupdates voor twee kritieke kwetsbaarheden: CVE-2026-109618 en CVE-2026-109619. Een aanvaller kan bij getroffen installaties mogelijk code uitvoeren zonder eerst in te loggen. De advisories beschrijven fouten bij geheugenafhandeling en achtergebleven interne toestand. Zie de eerste PHP-advisory en de tweede advisory.

PHP bracht hiervoor versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit. Het PHP-nieuwsarchief bevat de officiële aankondigingen en latere aanvullingen. Dit artikel is bijgewerkt op 27 oktober 2026.

WordPress draait op PHP. Daarom kan dit nieuws relevant zijn voor een WordPress-site, ook als je zelf nooit een regel PHP hebt geschreven. Het WordPress-project legt in zijn beveiligingsbericht van 21 oktober uit dat de kwetsbaarheden in PHP zitten. Een WordPress-update is niet de oplossing voor deze specifieke fouten.

In WordPress kun je de gebruikte PHP-versie terugvinden bij Gereedschap, Sitediagnose, Informatie, Server. Je hostingpaneel kan die informatie ook tonen. Bij beheerde hosting voert de host de runtime-update doorgaans uit; vraag wel om bevestiging voor jouw omgeving.

Let op de verschillende plekken waar een toepassing draait. Je productiesite, testomgeving en achtergrondtaken kunnen elk hun eigen configuratie hebben. Het is dus zinvol om expliciet te benoemen welke omgeving je laat controleren. Eén versienummer op een laptop zegt nog weinig over de software die een websitebezoeker raakt.

Maak de vraag zo dat je het antwoord kunt controleren. Bijvoorbeeld:

Voor een eigen applicatie voeg je de concrete onderdelen toe die je gebruikt: de website, eventuele API, formulieren en achtergrondprocessen. De beheerder kent de technische inrichting en kan vaststellen welke onderdelen door dezelfde runtime worden afgehandeld.

Vraag bij een Linux-distributiepakket of een leverancier met langetermijnondersteuning om de status van het beveiligingspakket. Een leverancier kan een patch verwerken in een eigen pakketversie. Alleen vergelijken met het upstream-versienummer geeft dan niet altijd het volledige antwoord.

Bij beveiligingsnieuws moet je ook kijken wat er na het eerste bericht is veranderd. PHP publiceerde op 23 oktober aanvullend advies over session upload progress. Op 26 oktober volgden aangepaste Windows-pakketten met een Brotli-beveiligingsfix. Die Windows-pakketten hebben een -1-achtervoegsel; de PHP-runtimeversie zelf blijft gelijk. De details en toepasselijke voorwaarden staan in het officiële PHP-archief.

Stuur daarom de actuele advisories mee aan degene die jouw hosting beheert. Neem een configuratieadvies uit een nieuwsbericht niet blind over: laat beoordelen of het bij jullie installatie en de gebruikte functies past.

ENISA en andere Europese instanties adviseren organisaties getroffen applicaties te inventariseren, met leveranciers af te stemmen en de updates toe te passen. Als directe reparatie niet mogelijk is, noemen ze het isoleren van blootgestelde toepassingen van publieke netwerken als maatregel.

Laat de verantwoordelijke beheerder bepalen wat dat voor jouw omgeving betekent. Vraag om een concreet herstelmoment en leg vast wie dat bewaakt. Een melding dat de host aan de firewall werkt, geeft je nog geen bevestiging dat de PHP-update is uitgevoerd.

Bewaar de updatebevestiging bij je projectdocumentatie. Dan kan een collega later terugvinden wat is gecontroleerd en welke onderdelen nog aandacht vragen.

Als je zelf een applicatie bouwt, hoort de omgeving waarin die draait bij je verantwoordelijkheid. Een werkend formulier of een geslaagde code-review vertelt je niet automatisch of de runtime bijgewerkt is.

Ik zou dat meenemen in de afspraken rond een project. Wie beheert de hosting? Waar komen beveiligingsmeldingen binnen? Wie voert een update uit? En hoe controleer je daarna of aanmelden, formulieren en andere belangrijke handelingen nog werken? Je kunt AI vragen die inventarisatie op te stellen. Vraag steeds om controleerbare uitkomsten.

Voor die manier van werken gebruiken we bij VCA ook de begrippen guardrails en verification: vooraf bepalen welke grenzen gelden en welk bewijs bij oplevering hoort. Meer over het bouwen zelf lees je in onze uitleg over vibe coding. Wil je leren je eigen applicaties zorgvuldig op te bouwen, bekijk dan de cursussen.