CVE-2026-109618 en CVE-2026-109619: wat moet je nu doen?

PHP heeft patches uitgebracht voor 2 kritieke kwetsbaarheden. Stel vast wat er werkelijk in productie draait, werk PHP bij en controleer alle draaiende workers. Een applicatie-update alleen is niet genoeg.

Kort antwoord

Beheer je een PHP-applicatie? Bepaal vandaag welke PHP-runtime, SAPI, package en webserverconfiguratie echt in productie draaien. Laat de verantwoordelijke beheerder de officiële patch of een aantoonbaar gepatcht distributiepakket installeren. Herstart daarna alle relevante workers en processen en verifieer de actieve versie vanuit de draaiende webomgeving, niet alleen vanuit een terminal.

Wat gebeurde er op 20 en 21 oktober?

Op 20 oktober kondigde PHP een beveiligingsrelease aan voor 21 oktober om 14:00 UTC. Beide kwetsbaarheden kregen CVSS v4.0 9.2. Op 21 oktober publiceerde PHP de patches en de advisories voor CVE-2026-109618 en CVE-2026-109619.

PHP bevestigt dat beide fouten remote code execution zonder vooraf inloggen mogelijk kunnen maken. Daarbij kan een aanvaller code uitvoeren met de rechten van het webworker-account. Dat kan gevolgen hebben voor data, applicatiecode en beschikbaarheid. Het betekent niet automatisch dat elk systeem is aangevallen of overgenomen.

Bij de eerste fout kan geheugenafhandeling interne aanvraagdata in een ongeldige toestand achterlaten. Bij de tweede kan een worker verwijzingen naar vrijgegeven aanvraaggeheugen bewaren. Een volgende aanvraag kan die verouderde toestand gebruiken. De oplossing zit in PHP zelf, onder de applicatie.

Reuters meldt dat overheidsorganisaties in Nederland en Finland websites uit voorzorg offline haalden, waaronder de Nederlandse cybersecurityorganisatie. Dat is bewijs van voorzorgsmaatregelen en verstoring, niet van bevestigde compromittering bij deze organisaties.

Welke omgevingen lopen risico?

PHP noemt installaties die webrequests verwerken: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP en LiteSpeed. Het PHP-team beschouwt het risico voor mod_php als het hoogst. Daar is uitvoering op afstand aangetoond, ook voordat applicatiecode draait.

De onderbouwing is niet voor iedere SAPI en CVE gelijk. Voor CVE-2026-109618 onderbouwt broncodeanalyse risico bij FPM, maar de advisory meldt geen volledig aangetoonde FPM-exploit. FrankenPHP wordt op basis van broncodeanalyse als waarschijnlijk vatbaar genoemd; bij LSAPI zijn applicatiespecifieke varianten waarschijnlijk maar niet gevalideerd. Voor CVE-2026-109619 is een sessie-gerelateerd RCE-pad juist wel gevalideerd bij mod_php en FPM, afhankelijk van applicatiegedrag. Andere varianten zijn configuratie- en toestandsafhankelijk. Niet bewezen is niet hetzelfde als veilig.

Schrijf dus niet iedere PHP- of WordPress-site af als aantoonbaar overneembaar. Controleer de echte runtime, configuratie en officiële packagepatch. WordPress-, Shopware-, Laravel- of Symfony-updates werken PHP zelf niet bij. Composer beheert PHP-afhankelijkheden en platformvereisten, maar vervangt de PHP-runtime niet.

Welke versies bevatten de fixes?

Gebruik binnen jouw ondersteunde branch ten minste de onderstaande gepatchte release, of een latere officiële release die de fixes behoudt. Deze tabel gaat over beide CVE’s, niet over gegarandeerde veiligheid van de hele applicatie.

Distributies en LTS-leveranciers kunnen fixes terugporteren zonder het zichtbare PHP-versienummer gelijk te trekken met upstream. Controleer de volledige packageversie, package-revisie en vendor advisory. Vraag je hostingpartij expliciet of beide CVE’s zijn opgelost en in welke actieve omgeving.

PHP 8.1 en ouder krijgen geen reguliere releases meer van het PHP-project. Er is bij dit incident wel een uitzondering: PHP heeft minimale broncodebackports voor 7.4, 8.0 en 8.1 beschikbaar gemaakt. Dat hervat de reguliere ondersteuning niet en is geen automatisch gepatcht hostingpakket. Laat je vendor de patch bevestigen of stap over op een ondersteunde branch.

PHP 8.2 bereikt op 31 december 2026 end-of-life. Patch nu en leg daarnaast een upgradepad vast. Deze beveiligingsrelease verlengt de ondersteuning niet.

Praktische controlelijst voor vandaag

1. Inventariseer alle internet-facing PHP-applicaties, inclusief oudere omgevingen en afzonderlijke containers. Leg vast welke producten erbij horen.

2. Benoem wie runtime en hosting beheert. Het productteam bepaalt kritieke functies; hostingpartij of platformbeheerder patcht de runtime; een leverancier bevestigt de status van systemen die hij beheert. Wijs één persoon aan die de afronding bewaakt.

3. Controleer de actieve runtime, SAPI, het volledige package en de vendorstatus voor beide CVE’s. Een CLI-versie kan afwijken van de versie achter de webserver.

4. Maak waar nodig een herstelpunt of backup volgens je bestaande beheerprocedure. Bepaal vooraf hoe je een mislukte update opvangt zonder de kwetsbare omgeving onnodig publiek te houden.

5. Installeer de officiële patch of een door je vendor bevestigde backport. Werk alle replicas, containers en relevante hosts bij.

6. Herstart alle relevante PHP-workers en processen. Een pakket op schijf bijwerken bewijst niet dat bestaande processen de nieuwe code gebruiken.

7. Verifieer de actieve versie of packagepatch vanuit de draaiende omgeving, achter dezelfde webserverconfiguratie als productie. Bewaar bewijs in je wijzigingsregistratie zonder diagnostische gegevens publiek te maken.

8. Test login, sessies, uploads, imports, formulieren, API’s en kritieke transactiestromen. Laat productverantwoordelijken bevestigen dat het essentiële gedrag nog klopt.

9. Controleer bestaande logging en monitoring op afwijkingen. Dit artikel geeft geen indicators of compromise. Schakel bij mogelijke compromittering gespecialiseerde incident response in.

10. Leg vast wie toekomstige runtime- en dependencyupdates volgt, beslist en valideert. Kan patchen echt niet direct, dan is isoleren of tijdelijk offline halen veiliger dan volledige bescherming aannemen van een WAF of configuratiewijziging.

Wat tijdelijke maatregelen wel en niet doen

PHP noemt tijdelijke maatregelen voor specifieke aanvalspaden. Geen daarvan is een volledige oplossing. Laat een beheerder de officiële advisory lezen en de gevolgen voor beschikbaarheid en applicatiegedrag afwegen; kopieer geen losse instelling als vervanging van patchen.

Voor CVE-2026-109618 noemt PHP administratief afgedwongen uitschakeling van de PHP-geheugenlimiet, conservatieve aanvraag- en uploadlimieten en grenzen bij frontend of container. Dat is geen volledige oplossing: onderliggende geheugentoewijzing kan nog falen. PHP waarschuwt dat bepaalde procesgeheugenlimieten juist de kwetsbare fout kunnen uitlokken.

Voor CVE-2026-109619 noemt PHP uitschakeling van session upload progress en, op PHP 8.5, fatal-error-backtraces, gevolgd door herstart van iedere worker. Die maatregelen blokkeren bevestigde paden, niet alle varianten. Ze zijn geen volledige oplossing en moeten vóór request parsing van kracht zijn.

PHP noemt ook het verwijderen van ongeldige of verouderde instellingen die vóór initialisatie diagnostiek veroorzaken en het oplossen van bereikbare fatale fouten en timeouts. Ook dit is geen volledige oplossing. Meldingen verbergen helpt niet. Een WAF wordt door PHP niet als volledige mitigatie bevestigd. Updaten blijft de enige volledige oplossing voor deze kwetsbaarheden.

Wat dit incident organisatorisch blootlegt

Analyse van tre plus: de eerste vertraging zit vaak in een vraag zonder eigenaar. Wie beheert PHP: het productteam, de hostingpartij of een andere leverancier? Zonder compleet runtime-overzicht kan een applicatie up-to-date lijken terwijl de laag eronder verouderd is.

Verouderde branches zonder upgradepad, vertrouwen op pluginupdates en een ongeoefende patchprocedure maken een spoedupdate lastiger. Leg daarom runtime-eigenaarschap, leveranciersafspraken, testverantwoordelijkheid en het bewijs van een geslaagde update vooraf vast. Een plugin-update is geen bewijs dat de hostinglaag gepatcht is.

Wanneer specialistische hulp nodig is

Bij mogelijke compromittering zijn forensics en incident response werk voor een gespecialiseerde securitypartij. Een penetratietest vervangt patching niet. tre plus biedt in dit artikel geen SOC, forensics, pentestdienst of noodrespons aan. Een patch sluit de fout, maar bewijst niet dat eerdere toegang of wijzigingen zijn verdwenen.

Runtimeonderhoud hoort bij het developmentproces

Structureel runtimeonderhoud, testautomatisering, code review en CI/CD-controles hebben binnen het developmentproces een eigenaar nodig. Hoe je eigenaarschap, controles en onderhoud over de hele levenscyclus inricht, staat in onze gids over secure software development. Voor wie daar blijvend mensen aan wil toevoegen beschrijft onze pagina over nearshore PHP developers het werk. Developer as a Service en Team as a Service zijn samenwerkingsvormen, geen incidentrespons; bij nearshore developers blijft producteigenaarschap bij je eigen organisatie.

Veelgestelde vragen

Is iedere PHP-website kwetsbaar?

PHP waarschuwt alle installaties die webrequests verwerken. De exacte exploitbaarheid hangt af van runtime, configuratie, build en applicatiegedrag. Controleer de patchstatus; stel niet zonder onderzoek dat iedere site overneembaar of al gehackt is.

Wordt PHP bijgewerkt via WordPress of Composer?

Nee. Een WordPress-update wijzigt WordPress. Composer beheert dependencies en platformvereisten. De PHP-runtime wordt door je hosting-, package- of containerbeheer bijgewerkt.

Is een WAF voldoende?

Nee. PHP bevestigt geen volledige bescherming door een WAF of configuratiewijziging. Installeer beide fixes. Als dat nog niet kan, beoordeel isolatie of tijdelijk offline halen.

Wat als we PHP 8.1 of ouder gebruiken?

Vraag je vendor om aantoonbare fixes voor beide CVE’s of upgrade naar een ondersteunde branch. PHP’s uitzonderlijke minimale broncodebackports voor 7.4, 8.0 en 8.1 herstellen de reguliere ondersteuning niet.

Moeten PHP-workers opnieuw worden gestart?

Ja. Herstart alle relevante workers en processen en controleer daarna de actieve omgeving. Ook de officieel genoemde tijdelijke instellingen vereisen een herstart van iedere worker.

Hoe controleer ik een backport van onze hostingprovider?

Vraag naar het volledige geïnstalleerde package inclusief revisie en naar de vendor advisory die beide CVE’s als opgelost vermeldt. Laat de provider bevestigen dat alle actieve workers en replicas het gepatchte pakket gebruiken. Alleen een zichtbaar hoofdversienummer is onvoldoende.