PHP bracht fixes uit voor twee kritieke kwetsbaarheden: wat beheerders moeten doen

Op 21 oktober 2026 bracht PHP fixes uit voor twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619. Volgens het PHP-beveiligingsadvies kunnen de fouten in PHP-installaties die webverzoeken afhandelen leiden tot uitvoering van code op afstand zonder authenticatie. De fixes zijn beschikbaar in vier upstream-releases; welke pakketupdate je nodig hebt, hangt af van de PHP-branch en de leverancier van je software.

Welke PHP-installaties lopen risico?

PHP noemt PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed als webserverconfiguraties. Het project bestempelt Apache met mod_php als de configuratie met het hoogste risico. Beheerders moeten daarom inventariseren waar PHP webverzoeken afhandelt, niet alleen welke versie op de hoofdserver staat.

De twee kwetsbaarheden hebben verschillende oorzaken. Bij CVE-2026-109618 kan een onderbreking door geheugentekort PHP treffen terwijl aanvraaggegevens nog niet volledig zijn geïnitialiseerd; de opruimroutine kan die ongeldige gegevens vervolgens als geldig behandelen. Bij CVE-2026-109619 kan interne status van een aanvraag achterblijven nadat het bijbehorende geheugen is vrijgegeven. Een volgende aanvraag op dezelfde worker kan die verouderde status gebruiken.

Welke PHP-versies bevatten de fixes?

PHP publiceerde de volgende gecorrigeerde upstream-releases:

Controleer de branch van iedere installatie en werk bij naar de bijbehorende release. Een pakket uit een Linux-distributie of van een leverancier met langetermijnondersteuning kan een eigen versienummer of backport gebruiken, dus vergelijk de pakketstatus met de advisering van de partij die het pakket onderhoudt.

Oudere branches en PHP in andere software

PHP 8.1 en oudere branches krijgen geen updates meer van het PHP-project. Sommige distributies en leveranciers met langetermijnondersteuning brengen wel backports uit. PHP publiceerde daarnaast minimale broncodebackports voor 7.4, 8.0 en 8.1; dat zegt op zichzelf niet of een specifieke installatie of een leverancierspakket al is bijgewerkt.

Neem ook apparaten en diensten mee waarin PHP is ingebouwd. Het Britse National Cyber Security Centre adviseert organisaties PHP-systemen in hun infrastructuur te inventariseren, internetgerichte systemen voorrang te geven en updates van leveranciers van gebundelde software te volgen. Bij hosting of een beheerde dienst moet de beheerder de partij die de PHP-runtime of het pakket verzorgt bij de patch betrekken.

Wat als direct updaten niet lukt?

PHP noemt tijdelijke instellingen voor specifieke aanvalspaden, maar zegt dat die geen volledige oplossing bieden. Voor CVE-2026-109618 noemt het project memory_limit=-1 in een configuratie die toepassingen niet kunnen overschrijven en het beperken van de aanvraaggrootte. Een onderliggende allocatiefout kan het kwetsbare pad echter nog steeds bereiken.

Voor CVE-2026-109619 adviseert PHP session.upload_progress uit te schakelen vóór het verwerken van aanvragen en de workers opnieuw te starten. Voor een bevestigd pad via fatal backtraces noemt PHP 8.5 ook fatal_error_backtraces=0. De juiste maatregel hangt dus af van de kwetsbaarheid en de configuratie; geen van deze instellingen vervangt de update.

Het NCSC adviseert om eerst PHP-installaties in kaart te brengen en systemen die vanaf internet bereikbaar zijn prioriteit te geven. Pas de update toe of gebruik waar nodig de tijdelijke maatregelen van PHP. Als noch bijwerken noch een maatregel op tijd mogelijk is, overweeg dan het systeem offline te halen. Wanneer directe updates of uitschakeling niet mogelijk zijn, adviseert het NCSC vóór of tijdens de aanpak te controleren op compromittering en achterdeurtjes.

Wat kunnen bezoekers van websites doen?

De kwetsbaarheden zitten in PHP aan de serverkant. De organisatie die de PHP-installatie beheert, of de leverancier die dat voor haar doet, moet de update toepassen; een websitebezoeker kan de PHP-versie van de server niet zelf bijwerken.