Op 21 oktober 2026 maakte PHP twee kritieke kwetsbaarheden bekend die uitvoering van code op afstand zonder authenticatie mogelijk kunnen maken. Diezelfde dag bracht het project patches uit voor branches 8.5, 8.4, 8.3 en 8.2 en adviseerde het gebruikers om direct bij te werken. Installaties die webverzoeken verwerken, kunnen kwetsbaar zijn, waaronder PHP-FPM, Apache mod_php, php-cgi, FrankenPHP en LiteSpeed, meldt PHP.

De gepatchte versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. De releases verhelpen CVE-2026-109618, die verband houdt met beschadiging van de toestand bij geheugentekort, en CVE-2026-109619: een fout waarbij de toestand van één verzoek in het workerproces kon achterblijven en bij de verwerking van het volgende verzoek kon worden gebruikt. Versies lager dan de genoemde versies zijn getroffen. Voor PHP 8.1 en oudere branches brengt het project geen eigen updates meer uit; beheerders van zulke systemen moeten daarom nagaan of hun distributieleverancier of LTS-aanbieder patches beschikbaar heeft.
Twee fouten in de levenscyclus van webverzoeken
Bij CVE-2026-109618 kan de verwerking van een verzoek worden onderbroken door geheugentekort voordat de interne gegevens volledig zijn geïnitialiseerd. Bij het afsluiten kan PHP vervolgens een ongeldige toestand aanspreken. In het beveiligingsadvies beschrijven de ontwikkelaars onder meer scenario’s met multipart-verzoeken en het bereiken van de geheugenlimiet. Voor Apache mod_php is een scenario bevestigd waarin het probleem al optreedt voordat de applicatiecode wordt uitgevoerd; PHP merkt ook op dat het risico voor deze configuratie groter is.
CVE-2026-109619 heeft betrekking op toestand die een workerproces tussen verzoeken bewaart. Als een bewerking mislukt voordat de gegevens worden gewist, wordt het geheugen van het vorige verzoek vrijgegeven, maar blijft de verwijzing ernaar bestaan. Het volgende verzoek dat in hetzelfde proces terechtkomt, kan deze verouderde toestand aanspreken voordat de normale initialisatie plaatsvindt. In het beveiligingsadvies van het project beschrijft PHP bevestigde aanvalspaden via vroege diagnostische bewerkingen en de verwerking van voortgangsinformatie bij bestandsuploads. Of een specifiek pad van toepassing is, hangt af van de configuratie, de applicatie en de gebruikte extensies.
Beide kwetsbaarheden kregen een score van 9,2 volgens CVSS 4.0. Volgens PHP omvat de bevestigde impact uitvoering van code met de rechten van de webworker. In het advies is voor de geheugentekortfout een volledig HTTP-scenario tegen mod_php bevestigd; voor PHP-FPM beschrijft de bron codeanalyse en voorwaarden voor kwetsbaarheid. Het is daarom belangrijk dit onderscheid mee te nemen bij de beoordeling van een concrete implementatie.
Wat beheerders moeten controleren
Bepaal eerst welke PHP-versies daadwerkelijk webverkeer verwerken: op één server kunnen afzonderlijke CLI-, FPM- en Apache-builds draaien, terwijl containers en clusterknooppunten onafhankelijk van elkaar worden bijgewerkt. Installeer voor elke ondersteunde branch de bijbehorende gepatchte release of een pakket van de leverancier waarvan bevestigd is dat het de patch bevat. Herstart vervolgens alle PHP-workers en controleer na de herstart hun versies: alleen de bestanden vervangen laat oude processen actief.
Controleer voor PHP 8.1 en ouder de ondersteuningsstatus en of de distributie of LTS-aanbieder een backport heeft uitgebracht. Is zo’n pakket niet beschikbaar, plan dan een overstap naar een ondersteunde branch. PHP geeft aan dat leveranciers van Linux-distributies de patches vooraf hebben ontvangen. Hun pakketversienummer kan afwijken van de officiële PHP-release; controleer daarom specifiek of de patch is opgenomen.
Tijdelijke instellingen en filtering van verzoeken kunnen afzonderlijke aanvalspaden beperken, maar volgens het project is bijwerken de enige volledige oplossing voor beide problemen. Voor teams ligt de praktische prioriteit bij het inventariseren van alle webworkers, het installeren van het gepatchte pakket, het herstarten van de processen en het controleren van het resultaat op elk knooppunt. Daarmee worden de bevestigde kwetsbaarheden verholpen, in plaats van uitsluitend op de configuratie van de webserver te vertrouwen.