Twee kritieke PHP-lekken: update uw webserver direct

De PHP-projectorganisatie heeft op 21 oktober 2026 beveiligingsupdates uitgebracht voor twee kritieke kwetsbaarheden: CVE-2026-109618 en CVE-2026-109619. Beide lekken kunnen onder bepaalde omstandigheden leiden tot uitvoering van code op afstand zonder voorafgaande aanmelding. Voor organisaties met een publiek bereikbare PHP-webapplicatie is dit daarom een update die met prioriteit ingepland moet worden.

De oplossing zit in de bijgewerkte PHP-releases. Tijdelijke configuratiemaatregelen kunnen een deel van de bekende aanvalspaden beperken, maar zijn volgens het PHP-project geen volwaardige vervanging voor de update. Dit artikel is gebaseerd op de officiële PHP-advisory en beschrijft wat beheerders concreet kunnen controleren.

Wat is er aan de hand?

CVE-2026-109618 betreft een fout in de verwerking van een geheugenuitputtingsfout (out-of-memory, OOM). PHP kan een verzoek op dat moment verlaten terwijl interne aanvraagdata nog niet volledig is geïnitialiseerd. Bij het afsluiten van het verzoek kan die ongeldige toestand vervolgens toch worden verwerkt. De officiële advisory beschrijft een aangetoond, niet-geauthenticeerd aanvalspad voor Apache met mod_php, nog voordat applicatiecode wordt uitgevoerd.

Bij CVE-2026-109619 kan aanvraaggebonden interne toestand in een worker blijven verwijzen naar geheugen dat al is vrijgegeven. Een volgende aanvraag die door dezelfde worker wordt verwerkt, kan die achtergebleven toestand vóór de normale initialisatie gebruiken. De precieze voorwaarden verschillen per configuratie en applicatiepad, maar de advisory bevestigt dat een zorgvuldig samengestelde heap-layout kan uitmonden in remote code execution.

De officiële bekendmaking kwalificeert beide kwetsbaarheden als kritiek en adviseert alle gebruikers van PHP voor webverzoeken direct te updaten. De primaire bronnen doen geen uitspraak over een concrete compromise van uw eigen omgeving; behandel de situatie daarom als een urgente patchopgave en baseer incidentonderzoek op uw eigen logging en detectiegegevens.

Welke PHP-omgevingen moeten worden gecontroleerd?

Het gaat niet alleen om PHP op de command line. Het PHP-project noemt alle installaties die webverzoeken verwerken, waaronder PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Bij Apache met mod_php is het risico volgens de bekendmaking het hoogst, omdat daar een niet-geauthenticeerd verzoek de aangetoonde aanval kan starten voordat de applicatiecode draait.

Inventariseer daarom per website, container, pool en server welke PHP-versie en welke SAPI werkelijk het HTTP-verkeer verwerkt. De uitvoer van php -v op een beheershell kan afwijken van de versie achter de webserver. Gebruik een afgeschermde runtimecontrole, uw deploymentinventaris of pakketbeheer; maak een phpinfo()-pagina nooit publiek toegankelijk.

Deze versies bevatten de oplossing

PHP 8.2: update naar minimaal 8.2.35.
PHP 8.3: update naar minimaal 8.3.36.
PHP 8.4: update naar minimaal 8.4.27.
PHP 8.5: update naar minimaal 8.5.12.

Gebruikt u distributiepakketten of een managed platform, controleer dan het beveiligingsbulletin van de leverancier. Linux-distributies en LTS-leveranciers hebben de patches volgens PHP vooraf ontvangen, maar de pakketversie en backportstatus verschillen per leverancier. Ga dus uit van de door uw platformleverancier bevestigde fix, niet alleen van het eerste deel van een versienummer.

Praktische aanpak voor beheerders

Maak een volledige inventaris. Breng alle productie-, acceptatie- en beheerde omgevingen in kaart, inclusief afzonderlijke PHP-FPM-pools, containers en sites die een andere runtime gebruiken.
Plan de pakket- of image-update. Update naar een gepatchte release of naar het door uw leverancier bevestigde pakket. Neem eventuele extensiecompatibiliteit en de reguliere changeprocedure mee.
Vervang of herstart de draaiende workers. Een bijgewerkte package op schijf is niet voldoende als oude PHP-FPM-workers, Apache-processen of containers nog actief zijn. Laat de runtime opnieuw starten volgens uw eigen deploymentprocedure.
Controleer de daadwerkelijke web-runtime. Bevestig na de uitrol dat de PHP-versie achter het HTTP-verkeer de gepatchte release gebruikt. Controleer dit ook bij blue-green- of rolling deployments.
Test kritieke gebruikersstromen. Test minimaal inloggen, formulierverwerking, uploads en achtergrondtaken voor de applicaties die u hebt bijgewerkt. Let vooral op sites met afwijkende uploadlimieten of eigen PHP-instellingen.

Tijdelijke maatregelen zijn geen alternatief voor patchen

Kunt u niet onmiddellijk updaten, pas dan alleen tijdelijke maatregelen toe binnen uw changeproces en documenteer de resterende blootstelling. De PHP-advisory noemt de onderstaande maatregelen om specifieke bekende paden te beperken, maar benadrukt dat uitsluitend een gepatchte release de volledige oplossing biedt.

Voor CVE-2026-109618 kan een beheerde instelling van memory_limit=-1 het voorspelbare per-request geheugenlimietpad wegnemen. Configureer dit vóór het parsen van het verzoek, bijvoorbeeld op FPM-pool- of webserverniveau, en verifieer dat geen directory- of applicatie-instelling weer een eindige limiet terugzet. Dit is geen volledige mitigatie: een onderliggende allocatiefout kan het kwetsbare pad nog steeds bereiken.
Houd post_max_size laag: de advisory noemt 8 MB wanneer uploads niet nodig zijn en 32 MB wanneer die wel nodig zijn. Houd upload_max_filesize lager dan post_max_size en begrens waar mogelijk ook verzoekgrootte, multipart-onderdelen, headers en nesting bij de proxy of webserver.
Voor CVE-2026-109619 kan session.upload_progress.enabled=0, toegepast vóór het parsen van het verzoek en gevolgd door een herstart van alle workers, de bevestigde sessiepaden blokkeren. Op PHP 8.5 kan ook fatal_error_backtraces=0 een bevestigd pad beperken.
Pas deze instellingen niet per verzoek toe met ini_set() of een FPM .user.ini: daarvoor komen ze te laat. Gebruik ook geen RLIMIT_AS of RLIMIT_DATA als vervanging; de PHP-advisory waarschuwt dat die juist een relevante allocatiefout kunnen veroorzaken.

Een container- of cgrouplimiet kan helpen om de beschikbaarheidsimpact van een individuele worker te begrenzen, maar voorkomt het lek niet. Beoordeel zo’n maatregel zorgvuldig: een te breed toegepaste limiet kan meer processen raken dan alleen de verzoekworker.

Oudere PHP-versies vereisen extra aandacht

PHP 8.1 en ouder ontvangen geen reguliere releases meer vanuit het PHP-project. Voor PHP 7.4, 8.0 en 8.1 zijn minimale source-backports beschikbaar gesteld om organisaties die zelf bouwen of geen LTS-leverancier hebben te helpen. Dat betekent niet automatisch dat iedere server met zo’n versie veilig is: vraag uw leverancier naar de concrete backport, het pakketversienummer en de ondersteunde upgrade-route. Is er geen bevestigde fix beschikbaar, behandel een upgrade naar een ondersteunde versie als noodzakelijke structurele oplossing.

Wat controleert u na de update?

De gepatchte versie draait daadwerkelijk in iedere web-SAPI en niet alleen in de CLI.
Alle oude workers, containers en cachelagen zijn vervangen of herstart volgens de deploymentprocedure.
Upload-, formulier- en sessiefunctionaliteit werken nog met de aangescherpte limieten.
Uw patchregistratie bevat runtime, leverancier, toegepaste versie, herstartmoment en testresultaat.
Uw securityteam beoordeelt beschikbare webserver-, WAF- en applicatielogs op afwijkingen die passen bij de eigen omgeving, zonder die op voorhand als bewijs van misbruik te duiden.