Korrigeringen för PHP2Shell har släppts, men för de flesta webbplatser som behöver den finns det ingen knapp att trycka på. Bristerna finns i själva PHP, motorn som kör alla WordPress-, Joomla- och Drupal-sidor, under CMS:et, dess tillägg och inloggningssida. Att uppdatera WordPress gör ingen skillnad. Den korrigerade PHP-tolken måste komma från den som driver servern: webbhotellet, Linuxdistributionens paket eller containeravbildningen. Fram till dess får webbplatsen vänta, oavsett vad ägaren gör.

Det är den delen av historien som rubrikerna om att ”installera korrigeringen nu” utelämnar. PHP-teamet har gjort sitt jobb. Att få ut korrigeringen på en viss server beror på en leveranskedja som rör sig i samma takt som sin långsammaste länk, och redan den första dagen blev det tydligt hur långt ifrån varandra länkarna befinner sig. Den som inte vet var webbplatsens PHP kommer ifrån kan inte avgöra hur utsatt den fortfarande är.

Därför löser inte en WordPress-uppdatering problemet

Eftersom buggarna finns i PHP-tolken omfattar PHP:s säkerhetsmeddelande alla installationer som hanterar webbförfrågningar, från PHP-FPM och Apaches mod_php till php-cgi, FrankenPHP och LiteSpeed. The Hacker News noterar att även en enkel ”Hello World”-sida på en sårbar version kan angripas. Värst är det med mod_php, där en enda förfrågan från någon utan konto kan utlösa angreppet innan någon programkod körs. Då hinner varken ett säkerhetstillägg eller en inloggningssida märka något.

Wordfence, säkerhetsleverantören för WordPress, uppgav för webbplatsägare, enligt The Verge, att korrigeringen inte kan komma via automatiska uppdateringar och att de måste ta reda på vem som ansvarar för deras PHP. Laravel Forge gav samma besked till sina kunder om sina servrar: de automatiska säkerhetsuppdateringarna korrigerar inte PHP, och Ubuntus obevakade uppdateringar hämtar bara paket från Ubuntus eget arkiv – inte från tredjepartsarkivet som Forge använder för att installera PHP.

Paketkällorna uppdaterades inte samtidigt. På släppdagen rapporterade webbplatshanteringstjänsten mySites.guru att cPanels EasyApache 4 hade korrigerade versioner inom några minuter efter säkerhetsmeddelandena, medan Ondřej Surýs PPA, paketkällan som Laravel Forge självt förlitar sig på, och Remis arkiv ännu inte hade några. InMotion Hosting uppgav att deras delade servrar och WordPress-servrar väntade på CloudLinux-versionerna. Bland de aktiva webbplatser som mySites.guru övervakar rapporterade 0,08 procent en korrigerad PHP-version klockan 13.52 UTC.

Versionsnumret kan vara missvisande

Det är inte så enkelt som att bara läsa av ett versionsnummer. Ubuntu, Debian och Red Hat bakåtporterar säkerhetskorrigeringar utan att ändra den ursprungliga versionen, så en korrigerad Ubuntu 24.04-server rapporterar fortfarande paketversion 8.3.6. The Hacker News hänvisar till Debian och rekommenderar att man letar efter CVE-numret i paketets ändringslogg i stället för att lita på versionssträngen. mySites.guru pekar på ytterligare en fallgrop: PHP-binären som svarar på php -v i kommandoraden är ofta inte den som kör webbplatserna. Kontrollera därför vilken version själva webbplatsen rapporterar.

Sedan måste korrigeringen också börja användas. I sitt säkerhetsmeddelande betonar PHP, liksom Forge, att Apache, PHP-FPM och alla långlivade processer måste startas om. Köarbetare och liknande bakgrundsprocesser fortsätter att köra den gamla tolken tills de startas om, oavsett om filerna på disken har korrigerats eller inte.

Vilka får ingen officiell korrigering?

De korrigerade versionerna är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. De åtgärdar CVE-2026-109618 och CVE-2026-109619, som båda har fått betyget 9,2 enligt CVSS v4.0. PHP-projektet erbjuder inget för PHP 8.1 och äldre, förutom minimala bakåtporteringar i källkoden för 7.4, 8.0 och 8.1, avsedda för dem som kompilerar PHP själva. Vissa leverantörer täpper till luckan: InMotion uppger att cPanel har bakåtporterat korrigeringar till deras paket för versionerna 7.4 till 8.1 och att CloudLinux korrigerar alla versioner de distribuerar. CentOS 7 får däremot ingen korrigering alls.

Den gruppen är inte liten. Dagen före släppet körde 22,7 procent av de aktiva Joomla- och WordPress-webbplatser som mySites.guru övervakar PHP 8.1 eller äldre, och 16,6 procent använde fortfarande PHP 7 eller en äldre version. Företaget kopplar en del av detta till WordPress, som rekommenderar PHP 8.3 men fortfarande anger den sedan länge utfasade versionen 7.4 som kompatibel. PHP 8.2 fick den här korrigeringen, men säkerhetsstödet för versionen upphör den 31 december 2026.

Vad den tillfälliga inställningen stoppar

Den tillfälliga lösning som spreds före släppet, att ställa in session.upload_progress.enabled=0, fungerar men löser bara en del av problemet. PHP uppger att den blockerar de bekräftade vägarna via sessioner till CVE-2026-109619, men inte andra varianter. Inställningen måste göras i php.ini eller i server- eller poolkonfigurationen, och därefter måste alla processer startas om. I PHP 8.5 stänger fatal_error_backtraces=0 ytterligare en bekräftad angreppsväg. Inget av detta påverkar CVE-2026-109618. För den rekommenderar PHP en memory_limit=-1 som inte kan åsidosättas, ett lågt värde för post_max_size och begränsningar av förfrågningarnas storlek på webbservern eller proxyn. PHP skriver uttryckligen att det inte finns några fullständiga skyddsåtgärder. InMotion påpekar att WordPress, Joomla, Drupal, Magento och PrestaShop inte använder uppladdningsförlopp, så det får inga konsekvenser för dem att stänga av funktionen.

Cloudflare aktiverade brandväggsregler för alla abonnemang. Företagets teknikchef, Dane Knecht, kallade dem en tillfällig lösning. Som mySites.guru påpekar hjälper de bara om servern bakom Cloudflare avvisar trafik som går förbi Cloudflare och ansluter direkt till serverns IP-adress.

Hittills har angrepp upptäckts

watchTowr uppger att deras honeypotservrar registrerade försök att utnyttja båda bristerna på släppdagen, och Cloudflare såg angripare ändra sina nyttolaster för att ta sig förbi reglerna. Ingen källa har bekräftat ett lyckat intrång på någon specifik server. Vissa aktörer tog inga risker: The Hacker News rapporterar att BambooHR stängde ned sin tjänst och att nederländska offentliga tjänster, däribland DigiD, släcktes ned som en försiktighetsåtgärd. EU:s CERT och Storbritanniens National Cyber Security Centre uppmanade organisationer som inte kan installera korrigeringen att isolera utsatta appar eller ta dem offline.

Bristerna upptäcktes av Wiz Research, Calif och OpenAI:s Codex Security-team. Enligt PHP Foundation upptäcktes tecken på minnesfelet vid en granskning 2024, men arbetet med en korrigering körde fast i flera månader – en försening som organisationen kallade ”ett strukturellt misslyckande”. Forskarna säger att AI-modeller hjälpte till att omvandla de tio år gamla buggarna till fungerande exploateringar på ungefär en vecka.

PHP behövde en granskning, månader av låsning och en läcka innan korrigeringen kunde släppas. För en webbplats på ett delat webbhotell återstår det sista steget: att skicka ett supportärende.

Taggar: Cloudflare, PHP, PHP2Shell, sårbarheter, WordPress