Michael JohnsonDen 21 oktober 2026 meddelade PHP att två kritiska sårbarheter kan möjliggöra fjärrkörning av kod utan autentisering. Samma dag släppte projektet korrigeringar för grenarna 8.5, 8.4, 8.3 och 8.2 och rekommenderade användarna att uppdatera omgående. Installationer som hanterar webbförfrågningar kan vara sårbara, däribland PHP-FPM, Apache mod_php, php-cgi, FrankenPHP och LiteSpeed, meddelar PHP.
De korrigerade versionerna är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Utgåvorna åtgärdar CVE-2026-109618, som är kopplad till korrupt tillstånd vid minnesbrist, och CVE-2026-109619 – ett fel där tillstånd från en förfrågan kunde bli kvar i en arbetsprocess och användas vid hanteringen av nästa. Äldre versioner än de angivna är berörda. Projektet släpper inte längre egna uppdateringar för PHP 8.1 och äldre grenar, så administratörer bör kontrollera om distributören eller en LTS-leverantör tillhandahåller korrigeringar för dessa system.
Två fel i webb förfrågningens livscykel
För CVE-2026-109618 kan hanteringen av en förfrågan avbrytas på grund av minnesbrist innan interna data har initierats fullständigt. När PHP avslutas kan det sedan komma åt ett ogiltigt tillstånd. I sin säkerhetsrådgivning beskriver utvecklarna bland annat scenarier med multipart-förfrågningar och överskridande av minnesgränsen. För Apache mod_php har ett scenario bekräftats där problemet uppstår innan applikationskoden körs. PHP påpekar också att risken är större i den här konfigurationen.
CVE-2026-109619 berör tillstånd som en arbetsprocess bevarar mellan förfrågningar. Om en operation misslyckas innan data har rensats frigörs minnet för den föregående förfrågan, men en referens till det blir kvar. En efterföljande förfrågan som hanteras av samma process kan komma åt det inaktuella tillståndet innan den normala initieringen. I projektets säkerhetsrådgivning beskriver PHP bekräftade vägar via tidiga diagnostikåtgärder och hantering av förloppet för filuppladdningar. Om en viss väg är tillämplig beror på konfiguration, applikation och använda tillägg.
Båda sårbarheterna har fått betyget 9,2 enligt CVSS 4.0. Enligt PHP omfattar den bekräftade påverkan kodkörning med webbprocessens behörigheter. I säkerhetsrådgivningen bekräftas ett fullständigt HTTP-scenario mot mod_php för minnesbristfelet. För PHP-FPM beskriver källan kodanalys och villkor för sårbarhet, så det är viktigt att skilja mellan dessa uppgifter vid bedömning av en viss driftsättning.
Vad administratörer bör kontrollera
Börja med att ta reda på vilka PHP-versioner som faktiskt hanterar webbtrafiken: en server kan köra separata CLI-, FPM- och Apache-byggen, och containrar samt klusternoder uppdateras oberoende av varandra. Installera den aktuella korrigerade utgåvan eller ett leverantörspaket med en bekräftad korrigering för varje gren som fortfarande stöds. Starta sedan om alla PHP-processer och kontrollera versionen efter omstarten – att bara byta ut filerna innebär att gamla processer fortsätter att köras.
För PHP 8.1 och äldre bör du kontrollera supportstatus och om distributören eller en LTS-leverantör erbjuder en bakåtporterad korrigering. Om ett sådant paket saknas bör du planera en övergång till en gren som fortfarande stöds. PHP uppger att leverantörer av Linux-distributioner fick korrigeringarna i förväg. Paketets versionsnummer kan skilja sig från den officiella PHP-utgåvan, så kontrollera i stället informationen om vilken korrigering som ingår.
Temporära inställningar och filtrering av förfrågningar kan begränsa vissa angreppsvägar, men projektet beskriver uppdatering som det enda fullständiga sättet att åtgärda båda problemen. Team bör prioritera att inventera alla webbprocesser, installera ett korrigerat paket, starta om processerna och kontrollera resultatet på varje nod. Det är detta som åtgärdar de bekräftade sårbarheterna, i stället för att enbart förlita sig på webbserverns konfiguration.