PHP2Shell: en kritisk PHP-sårbarhet — är din webbplats utsatt?

Alla PHP-versioner som i sin egen gren är äldre än 8.5.12, 8.4.27, 8.3.36 och 8.2.35 är berörda, och det betyder nästan varje PHP-webbplats som ingen har uppdaterat den här veckan. Dagens första arbete är att ta reda på vilken version som betjänar din webbplats och att uppdatera den: en fullständig kringgående lösning finns inte, och PHP:s eget meddelande säger att uppdatering är det enda säkra valet.

Onsdagen den 21 oktober släppte PHP-teamet fyra nödversioner samtidigt; paret av sårbarheter som de åtgärdar har fått namnet PHP2Shell, och namnet beskriver resultatet exakt: från en nätverksförfrågan till körning av kod på servern. Den här artikeln handlar om vad som faktiskt har hittats, hur du ser om det gäller dig och i vilken ordning du ska agera, också när du inte kan uppdatera genast.

Vad PHP2Shell är och vad som hände den 21 oktober

I det officiella meddelandet står att 8.5.12, 8.4.27, 8.3.36 och 8.2.35 åtgärdar två kritiska sårbarheter som kan låta en oautentiserad angripare utföra fjärrkörning av kod (RCE), och att alla PHP-användare starkt rekommenderas att uppdatera omedelbart. Där står också den mening som bestämmer resten av den här artikeln: en fullständig kringgående lösning finns inte, och uppdatering är det enda säkra valet.

Båda sårbarheterna har PHP gett en CVSS v4.0-klassning på 9,2 av 10, men de är två skilda fel med olika mekanism och, som du ser längre fram, också med olika grad av bekräftelse — och just den andra skillnaden avgör i praktiken vilken server du börjar med.

CVE-2026-109618 — skadat minne efter out-of-memory (OOM): När PHP får slut på minne använder det longjmp() för att avbryta behandlingen av förfrågan; den officiella beskrivningen anger att förfrågans minne i vissa ögonblick är nåbart innan det är helt initierat; om minnesallokeringen misslyckas just då hanteras avbrottet inte korrekt, och det blir kvar ogiltigt minne som koden som körs när förfrågan avslutas fortfarande läser, eller som den fattar ett beslut utifrån.

En viktig detalj ändrar vem det här hotet gäller: att minnet tar slut åstadkoms med en särskilt förberedd multipart-förfrågan, och i den behöver ingen uppladdad fil finnas. Den officiella beskrivningen nämner flera problem i multipart-hanteringen — en förfrågan utan användbar angiven längd, en del med obegränsat antal huvuden, tomma filfält som inte räknas in i gränserna. Det betyder att förfrågan kan vara mycket liten och rymmas inom de vanliga gränserna för post_max_size och memory_limit.

CVE-2026-109619 — föråldrat globalt tillstånd: I PHP-processen finns ett globalt tillstånd kvar mellan förfrågningar: data om fel, sessioner, objekt och utökningar; den officiella beskrivningen säger att det här tillståndet måste nollställas innan förfrågans minne frigörs. Om nollställningen avbryts av ett fatalt fel, eller om diagnostiken när förfrågan avslutas fyller i det på nytt, frigörs minnet men pekaren till det finns kvar; den här felklassen kallas internationellt Use After Free (UAF).

Därefter kommer det villkor som gör den här sårbarheten svårare än den låter: den föråldrade pekaren kan bara användas av en åtgärd som sker före den vanliga initieringen av förfrågan, och den officiella beskrivningen nämner två bekräftade sådana fall — INI-diagnostik och hantering av sessionens uppladdningsförlopp. Dessutom måste angriparens senare förfrågan hamna i just samma process där det skadade tillståndet uppstod, så ett enstaka försök lyckas sällan, och beskrivningen säger uttryckligen att flera processer och att de byts ut minskar oddsen men inte tar bort själva villkoret.

Hur lätt det är att utnyttja, och mot vad det är bevisat

Här lönar det sig att vara precis, eftersom det är just på det här stället som merparten av artiklarna på nätet överdriver, antingen åt det ena hållet eller åt det andra.

Ett lösenord behövs inte, och det behövs inte heller att någon klickar på något på webbplatsen — i CVSS-vektorn syns det som PR:N och UI:N; i samma vektor står ändå AC:H och AT:P: Angreppets komplexitet är bedömd som hög och det har ytterligare förutsättningar; i praktiken betyder det upprepade försök, och om det lyckas beror på PHP-bygget, utökningarna, frontendens beteende och minneslayouten; alltså nej: En enda vanlig förfrågan räcker inte, men det kostar inte heller angriparen något, eftersom ingenting begränsar antalet försök.

Bevisgraden skiljer sig mellan de två felen, och den skillnaden spelar roll när du väljer hur bråttom det är. För CVE-2026-109618 är fullständig RCE bekräftad mot mod_php med standardgränser för indata och minne; för PHP-FPM säger samma beskrivning att källkodsanalysen betraktar det som sårbart, men att ett fullständigt angrepp mot PHP-FPM inte har demonstrerats. FrankenPHP nämns där som en motsvarighet till mod_php, medan LSAPI nämns som en motsvarighet till PHP-FPM, i båda fallen utan ett verifierat angrepp.

För CVE-2026-109619 har vägen genom sessionens livscykel kontrollerats både mot mod_php och mot PHP-FPM, medan den andra vägen, som går genom spårningen av ett fatalt fel, bara är bekräftad mot mod_php.

Av det följer en praktisk ordning: om din webbplats körs på mod_php står du först i kön, eftersom det är just där båda felen är bekräftade; med PHP-FPM och LiteSpeed är risken verklig, men än så länge bara delvis bekräftad, och i inget av fallen är det ett skäl att vänta — det är ett skäl att veta vilken server du börjar med.

Hur den här veckan såg ut, timme för timme

Kronologin är ingen kuriosa: den förklarar varför råden under de första timmarna skilde sig från dem som gäller nu, och varför en del artiklar på nätet fortfarande är föråldrade.

På kvällen den 20 oktober var det känt att något var på väg, men inte vad det var: PHP hade meddelat en kommande nödversion, och CloudLinux statussida noterade samma kväll att de tekniska uppgifterna och de berörda versionerna var planerade att publiceras vid nästa dags släpp; den tekniska beskrivningen var då ännu inte offentlig.

Till nästa dag hade läget förändrats, och inte till det bättre: på morgonen den 21 oktober noterade CloudLinux att ett angreppsmönster redan fanns i offentlig cirkulation, och klockan 9.08 UTC spreds en regeluppsättning för webbapplikationsbrandväggen (WAF) som blockerar det kända mönstret i den förfrågan som utnyttjar sårbarheten. Arton minuter senare dök det på samma sida upp en mening som beskriver den här veckan bäst — försök som motsvarar det här mönstret observeras redan, alltså letade någon redan efter servrar som ännu inte hade säkerhetsuppdateringen.

PHP:s säkerhetsuppdateringar kom klockan 14.00 UTC, vilket betyder att det gick flera timmar mellan ett offentligt tillgängligt angreppsmönster och en offentligt tillgänglig säkerhetsuppdatering, och under de timmarna pågick redan angreppsförsök.

En reservation ska sägas rent ut här: världen var inte helt utan åtgärd, eftersom PHP:s meddelande säger att Linux-distributioner och leverantörer med långtidssupport fick säkerhetsuppdateringarna i förväg, så för en del servrar fanns uppdateringen tidigare än för de övriga — offentligt tillgänglig var den däremot inte för någon.

Därefter började den längre delen, som fortfarande pågår: paketspridningen, och de som underhåller operativsystemen och hostingplattformarna bygger sina paket för sig, och paketen dyker upp inom timmar eller dagar, vart och ett i sin egen takt. Det är i det här skedet som en stor del av användarna på webbhotell befinner sig, och just därför är frågan ”har säkerhetsuppdateringen kommit” och frågan ”finns säkerhetsuppdateringen på min server” den här veckan två olika frågor med olika svar.

Är din webbplats utsatt

I de officiella varningarna är intervallen för berörda versioner skrivna så här: allt som är äldre än 8.2.35, allt som är äldre än 8.3.36, allt som är äldre än 8.4.27 och allt som är äldre än 8.5.12 — var och en i sin egen gren.

En viktig detalj som inbjuder till misstag: talet som php -v visar säger inte alltid allt; Linux-distributioner och hostingplattformar för ofta över säkerhetsuppdateringen till en äldre version utan att ändra dess nummer — bara paketets versionsnummer ändras; i så fall kan 8.4.26 redan vara åtgärdad, men den behöver inte vara det, och det enda sättet att veta är att titta i paketbeskrivningen eller att fråga leverantören; själva versionsnumret svarar inte på den frågan.

Särskilt om äldre versioner: PHP 8.1 och äldre får inte längre regelbundna uppdateringar från PHP-projektet, men med tanke på allvaret har säkerhetsteamet tagit fram minimala källkodsändringar för versionerna 7.4, 8.0 och 8.1 — för den som bygger från källkod eller som inte har tillgång till underhållarens support. Meddelandet rekommenderar där att du kontaktar din leverantör, eftersom en del distributioner och leverantörer med långtidssupport för över säkerhetsuppdateringarna; om din webbplats körs på PHP 7.x är det verkliga problemet inte den här veckan: det verkliga problemet är att det nästa gång kanske inte finns någon säkerhetsuppdatering, och PHP 8.2, som den här gången fick en säkerhetsuppdatering, når end of life den 31 december 2026.

Hur du kontrollerar versionen beroende på var webbplatsen ligger

Kontrollen tar minuter, och den är värd att göra för varje webbplats för sig, inte för varje server: på en och samma server ligger ofta webbplatser med olika PHP-versioner, och vanligtvis är det just den äldsta, den som alla har glömt, som är nåbar från internet.

Webbhotell med cPanel: Versionen visas i avsnittet MultiPHP Manager, där varje domän har en egen rad; Plesk använder PHP Settings för samma sak inuti varje abonnemang; i båda fallen är det värt att försäkra dig om att du tittar på den domän det gäller, inte på serverns standard.

En egen server eller en VPS (Virtual Private Server): På kommandoraden visar php -v det, men med en väsentlig reservation: PHP på kommandoraden är ofta en helt annan version än den som betjänar webbförfrågningar; det trovärdigaste svaret ger samma väg som webbplatsen arbetar längs — den körbara fil som anges i pool-avsnittet i PHP-FPM-konfigurationen.

Containrar: Om webbplatsen körs i Docker bestäms versionen av imagen, inte av värddatorn, så stegen är två: bygg om imagen från en uppdaterad basimage och starta sedan om containrarna; en image som byggdes före den 21 oktober innehåller inte säkerhetsuppdateringen, hur ofta containern än har startats om.

Om du inte har åtkomst till något av det här: Då är frågan till hostingleverantören, och den här veckan är det en helt normal fråga som de redan har ett svar förberett på; formuleringen som sparar en brevväxling: ”Vilken PHP-version betjänar min domän, finns PHP2Shell-säkerhetsuppdateringen i den, och om den inte gör det ännu, vilket datum kommer den?”

Vad du gör i dag

Dagens ordning är den här: uppdatera först PHP och starta om allt som kör det, försäkra dig sedan om att besökarna verkligen betjänas av den nya versionen, kontrollera därefter om det paketförråd du använder över huvud taget har släppt säkerhetsuppdateringen, och leta spår först efter det. Det första steget tar minuter, det sista kan ta dagar, och just därför är det inte värt att kasta om dem.

För det första, uppdatera: Med managed hosting gör leverantören det, och ditt arbete är att ställa frågan och få ett datum; om du själv administrerar servern ska det som kör PHP startas om efter paketuppdateringen: Apache, PHP-FPM eller LSAPI. Det här steget hoppas över förvånansvärt ofta — paketet är bytt, men de gamla processerna fortsätter att arbeta med den gamla koden, så kontrollen visar den nya versionen medan besökarna betjänas av den gamla.

För det andra, kontrollera att uppdateringen verkligen är tillämpad — längs samma väg som webbplatsen arbetar, inte via kommandoraden.

För det tredje, om du använder ett paketförråd som underhålls av frivilliga, kontrollera om det har släppt säkerhetsuppdateringen; i PHP:s meddelande finns en särskild varning om rpms.remirepo.net: dess användare rekommenderas att gå över till distributionens paket eller att bygga från källkod.

För det fjärde, först därefter kontrollerar du om det finns spår på webbplatsen; uppdateringen stänger dörren, men den svarar inte på frågan om någon redan har gått in genom den.

Om du inte kan uppdatera genast

Det här avsnittet är värt att läsa med klart medvetande om att inget av stegen som nämns här ersätter uppdateringen — PHP:s meddelande säger det rakt ut.

Mot CVE-2026-109618 nämner meddelandet att minnesgränsen tas bort: memory_limit=-1, och dessutom så att applikationen inte kan skriva över det — till exempel med php_admin_value i PHP-FPM- eller Apache-konfigurationen, med en kontroll av att ingen annan inställning lägger tillbaka den slutliga gränsen. Du behöver förstå vad det valet kostar: på en delad server byter det en risk mot en annan, eftersom en enda förfrågan då kan äta upp allt tillgängligt minne. I sårbarhetsbeskrivningen finns också en varning om att inte använda RLIMIT_AS och RLIMIT_DATA, eftersom de kan få minnesallokeringen att misslyckas och därmed leda just till den sårbara vägen.

Mot CVE-2026-109619 nämner meddelandet session.upload_progress.enabled=0 och, för PHP 8.5, fatal_error_backtraces=0 — i båda fallen med anvisningen att därefter starta om alla processer. I själva sårbarhetsbeskrivningen finns också pm.max_requests=1, som får PHP-FPM att byta ut PHP-FPM-workern efter varje förfrågan; det är en inställning i PHP-FPM-poolen, och där nämns den med reservationen ”om prestanda inte är en faktor”. Där sägs också det som håller åtgärden inom sina rätta gränser: att byta ut processen minskar oddsen för en enstaka förfrågan, men tar inte bort själva villkoret.

Nyttigt är också det som inte är en kringgående lösning men som minskar angreppsytan: ett återhållsamt post_max_size, ett rimligt djup i nästlingen av indata och en begränsad uppladdningsstorlek, och det är bra värden vilken vecka som helst, inte bara den här.

Hur du ser om du redan är drabbad

Efter uppdateringen är det värt att gå igenom webbserverns loggar för de senaste dagarna: Det du letar efter är ett ovanligt stort antal multipart-förfrågningar mot en och samma adress — och här är det lätt att leta fel: de brukar vara små och rymmas inom de vanliga gränserna, så du hittar dem inte efter volym. Mer talande är plötsliga serier av 500-fel som börjar och slutar utan synlig orsak: ett angrepp som bygger på att minnet tar slut misslyckas mycket oftare än det lyckas, och varje misslyckat försök lämnar ett fel.

I filsystemet är ändringstiderna det som betyder något: en PHP-fil som har ändrats på natten, när ingen arbetade, måste förklaras. Det är också värt att kontrollera schemalagda uppgifter och poster som ser till att något startar automatiskt efter en omstart — för en angripare med kodkörning är det första arbetet att befästa sig, så att åtkomsten överlever just den uppdatering du precis installerade.

För sig är det värt att kontrollera listan över administratörskonton och applikationens lösenord och nycklar; om kod har körts ska allt som servern känner till betraktas som läst — också databasens anslutningsuppgifter och API-nycklarna i konfigurationsfilen.

Om något av det inte ser rätt ut är rensningen ett eget arbete med en egen ordning, och den är värd att göra metodiskt, inte genom att radera misstänkta filer en och en. Vi har beskrivit det för sig — hur återställning av en hackad webbplats går till, och om du vill att någon annan gör det är återställning av hackade webbplatser en egen tjänst med en fast ordning: isolering, rensning, att orsaken åtgärdas och en kontroll av att webbplatsen har tagits bort från sökmotorernas varningslistor.

När händelsen blir en anmälningspliktig incident

Om det finns skäl att tro att en angripare har kommit åt personuppgifter blir den tekniska frågan också en juridisk. Dataskyddsförordningen, förordning (EU) 2016/679, sätter en frist som inte börjar vid angreppet utan vid den tidpunkt då den personuppgiftsansvarige har fått vetskap om personuppgiftsincidenten: om det är möjligt, senast 72 timmar för anmälan till tillsynsmyndigheten. Skyldigheten inträder inte om incidenten sannolikt inte medför en risk för fysiska personers rättigheter och friheter, och om risken är hög ska även personerna själva informeras — även den skyldigheten har undantag i förordningen.

Den praktiska innebörden av det här avsnittet är en enda: ögonblicket då något misstänkt har hittats i loggarna är inte ögonblicket då 72 timmar börjar ticka — det är ögonblicket då du måste ta reda på om en personuppgiftsincident över huvud taget har inträffat. En enstaka serie 500-fel, som oftast är ett misslyckat försök på det sätt som beskrivits ovan, är inte i sig en personuppgiftsincident. Men just därför är den utredningen inte värd att skjuta upp till ”när det är mindre att göra”, och just därför ska loggarna sparas innan rotationen skriver över dem: de är det enda beviset både för vad som hände och för vad som inte hände.

Om du ansvarar för flera webbplatser

För byråer och företag med flera webbplatser är den här veckan mindre en teknisk uppgift än en organisatorisk, och den ordning som fungerar är enkel: först en lista, sedan versionerna, sedan uppdatering i prioritetsordning.

Prioriteten bestäms inte av hur viktig webbplatsen är, utan av nåbarheten och av vad som betjänar den: Överst ligger offentligt tillgängliga webbplatser på mod_php, eftersom det är just där båda sårbarheterna är bekräftade; sedan det övriga offentliga, och först därefter interna system bakom en brandvägg. Test- och utvecklingsmiljöer, som alla glömmer, ska tas med i listan utan undantag — de körs ofta på en äldre PHP-version och är ofta nåbara från internet, eftersom det en gång var bekvämare så.

Webbplatser som någon annan administrerar stannar kvar i listan, men med en annan kolumn: vem frågan har skickats till och vilket datum svaret kom. Den kolumnen visar sig senare vara mer värd än de övriga, eftersom det är just den som visar vilken leverantör som reagerar och vilken som inte gör det.

Vad managed hosting betydde i det här fallet

Den här veckan visar tydligt var gränsen går mellan plattformen och applikationen, så det är ärligt att säga hur det såg ut från vårt håll.

Våra servrar körs på CloudLinux, och i dem finns Imunify360 inbyggt, och när angreppsmönstret började cirkulera offentligt noterade CloudLinux på sin statussida att regeluppsättningen för webbapplikationsbrandväggen, som blockerar det kända utnyttjandemönstret, hade spridits klockan 9.08 UTC — flera timmar innan PHP släppte själva säkerhetsuppdateringen klockan 14.00, och innan det på samma sida dök upp en notering om att försök redan observerades. Under dagen följde ytterligare två kompletteringar, varav den andra blockerar det utnyttjandeverktyg som redan är offentligt tillgängligt; allt det skedde automatiskt, utan kundens medverkan, och i branschen kallas en sådan åtgärd virtual patching: en regel i webbapplikationsbrandväggen blockerar utnyttjandet av sårbarheten utan att den sårbara koden själv ändras.

Och nu det som en sådan mening inte betyder, för det är just här branschen den här veckan sålde flest överdrifter: En regel i webbapplikationsbrandväggen blockerar kända angreppsmönster — samma ord använder också CloudLinux; samma sida kallar åtgärden en tillfällig lösning, inte en fullständig säkerhetsuppdatering; det är inte osårbarhet, och CloudLinux själv fortsätter att rekommendera att PHP uppdateras så snart paketen finns. Skillnaden mellan ”skyddad” och ”åtgärdad” är den här veckan helt konkret, och att sälja det ena som det andra vore oärligt.

Hur själva säkerhetsuppdateringen ser ut är en bra illustration av det vi varnade för tidigare: Våra servrar fick ett nytt bygge av ea-php84 på kvällen samma dag, några timmar efter PHP-släppet; versionsnumret ändrades inte — php -v skriver fortfarande 8.4.26, inte 8.4.27, och det enda som utifrån visar att något har ändrats är byggets datum, som hoppade från den 9 till den 21 oktober, och precis så ser en överförd säkerhetsuppdatering ut, och just därför är frågan till hostingleverantören mer värd än talet som skärmen visar.

Därför är värdet som managed hosting köpte här inte osårbarhet, utan ett smalare tidsfönster: timmarna då angreppsmönstret redan cirkulerade och försök redan pågick täcktes med blockering av det kända mönstret, i stället för att inväntas, och därefter att någon följer paketen och startar om processerna, i stället för att vänta tills kunden märker det. Vårt managed hosting börjar från 45 € i månaden, och det är just veckor av det här slaget som den summan betalar för.

Om din webbplats just nu ligger någonstans där du inte får svar på frågan om PHP-versionen och datumet för uppdateringen, är det i sig ett svar: Låt oss prata om flytten — en migrering går vanligtvis att göra utan driftstopp.

Efter uppdateringen ska du starta om mer än det verkar

En process som förblir vid liv mellan förfrågningar är ingen exotisk sak — det är precis så en vanlig PHP-FPM-pool och mod_php arbetar, och det är just mot dem som kodkörningen är bekräftad. Därför är CVE-2026-109619 inte något särskilt konfigurationshot; det är ett problem i den vanliga konfigurationen.

Av det följer det steg som oftast hoppas över: ett paketbyte påverkar inte en process som redan kör. Efter uppdateringen måste varje process som kör PHP startas om, och det gäller också dem som ingen vanligtvis rör. PHP-processer som har kört länge brukar inte startas om på flera veckor, så efter uppdateringen är det värt att räkna upp dem för sig och försäkra dig om att var och en av dem har startats på nytt.

Den rätta kontrollfrågan är därför inte ”vad visar php -v”, utan ”har varje process som kör PHP startats efter att paketet byttes”.

Varför det inte räcker med ”vi laddar ju inte upp något”

En vanlig invändning låter ungefär så: vår webbplats är ett visitkort, den har varken ett uppladdningsformulär eller användarkonton, alltså gäller det här inte oss; tyvärr gör det det, och skälet är just det som beskrivits ovan: angreppet behöver ingen uppladdad fil, det räcker med en förberedd multipart-förfrågan, och den kan skickas till vilken adress som helst som svarar med PHP; att ett formulär finns på sidan är inte en förutsättning, eftersom angriparen inte fyller i formuläret.

Lika lite spelar det någon roll om webbplatsen är liten: Angrepp mot sårbarheter av det här slaget sker i ett brett nät och automatiskt, och ingen gör ett urval efter antalet besökare. Palo Alto Networks enhet Unit 42 rapporterade på publiceringsdagen mer än 22,6 miljoner PHP-instanser som är nåbara på internet och som potentiellt är berörda; ingen av dem är särskilt utvald.

Den andra invändningen handlar om WordPress och tillägg: Inte heller den håller den här gången, bara i motsatt riktning: sårbarheten sitter i PHP självt, inte i WordPress, Laravel eller något tillägg; det betyder att uppdatering av tillägg inte löser det här problemet, och samtidigt att varje PHP-webbplats är berörd oavsett vad den är byggd på.

Vad från den här veckan som är värt att behålla

För dem som hade allt i ordning var det inte en snabb reaktion som gjorde jobbet, utan tre saker som hade ordnats tidigare: det var känt vilken webbplats som körde vilken PHP-version, det var känt vem som ansvarar för uppdateringen, och det fanns säkerhetskopior som det verkligen är kontrollerat att webbplatsen kan återställas från. Ingen av dem går att ordna den dag varningen redan är publicerad, och just därför var den här veckan en halvtimmes arbete för vissa team och två dagar för andra.

Om en uppgift ska tas med från den här veckan för att nästa gång ska bli lättare, är det en lista: varje webbplats, dess PHP-version, sättet den körs på, dess hostingleverantör och den person som får trycka på ”uppdatera”. Nästa varning av det här slaget kommer, och den enda frågan är hur lång tid det då tar att svara på frågan ”gäller det oss”.