PHP2Shell är samlingsnamnet för två kritiska sårbarheter i PHP: CVE-2026-109618 och CVE-2026-109619. Om en angripare lyckas utnyttja dem kan hen köra kod på en berörd server utan att logga in. Rättningar släpptes den 21 oktober 2026, och säkerhetsföretag har rapporterat försök att utnyttja sårbarheterna. Det är viktigt att skilja sådana försök från bekräftade intrång.
11
14
19
Vad gör PHP2Shell-sårbarheterna?
Felen finns i PHP självt – alltså i den programvara som kör PHP-kod på en server – och inte i en viss webbplats eller ett specifikt publiceringssystem. Red Hat beskriver hur det ena felet rör minneshantering när en minnesallokering misslyckas vid tolkning av en förfrågan. Det andra kan lämna kvar ett föråldrat tillstånd när ett allvarligt fel avbryter upprensningen.
7
Tillsammans kan sårbarheterna skapa en väg till fjärrkörning av kod. I praktiken innebär det att en angripare kan få en sårbar server att köra kod utan att först logga in.
11
13
Båda felen har fått 9,2 av 10 i CVSS v4.0, en bedömning i den kritiska allvarlighetsklassen.
4 Möjliga följder är att en server tas över, att data exponeras eller att tjänster störs. Men en sårbarhet innebär inte i sig att varje webbplats som använder PHP har utsatts för en attack.
13
Varför väckte felen så stor oro?
Rapporter beskriver sårbarheterna som problem som funnits i PHP under flera år.
42 Att ett fel har funnits länge är däremot inte ett bevis för att angripare kände till eller utnyttjade det under hela den perioden.
Fallet har också riktat uppmärksamheten mot AI-stödd säkerhetsforskning. Enligt rapporteringen använde Calif och Wiz AI-verktyg i sina undersökningar, och OpenAI deltog i forsknings- och rapporteringsarbetet.
34
44 AI kan hjälpa forskare att granska programvara, men upptäckten i sig visar inte hur snabbt angripare kan använda liknande verktyg – eller vilken sida som har ett övertag.
PHP:s breda användning har också lyfts fram i rubriker, ibland med uppskattningar om att språket används på omkring 70 procent av webbplatser.
20 Den siffran säger något om PHP:s räckvidd, inte hur många servrar som bekräftats sårbara eller har utsatts för intrång. Den faktiska risken beror bland annat på PHP-version, konfiguration och om en rättning har installerats.
Uppdateringar och rapporterade attackförsök
PHP-projektet publicerade rättningar den 21 oktober i versionerna 8.2.35, 8.3.36, 8.4.27 och 8.5.12.
19 Den listan gäller versionerna 8.2 till 8.5. Om ni använder en äldre version bör ni kontrollera säkerhetsinformationen från er operativsystemleverantör eller webbhotell och ta reda på om en verifierad rättning eller bakåtporterad uppdatering finns.
Det finns rapporter om försök att utnyttja sårbarheterna. SecurityWeek rapporterade att Amazon observerade ett försök den 17 oktober, fyra dagar före att rättningarna släpptes.
14 Cloudflare rapporterade också en kraftig ökning av trafik som försökte utnyttja felen, med rapporterade mängder på flera miljoner.
27
38 Det är siffror på observerade försök – inte på lyckade intrång.
Uppgifterna om omfattningen går isär. Vissa källor beskriver aktiva försök, medan en annan bedömer att en storskalig exploatering verkade mindre sannolik än man först trodde.
3
4 Det tillgängliga underlaget bekräftar inte att ett stort antal servrar har tagits över. Ta trovärdiga varningar på allvar, men skilj mellan skanning, attackförsök och bevis för att en viss server har drabbats.
2
3
Tjänster stängdes tillfälligt – men det bevisar inte intrång
Vissa organisationer tog tillfälligt ner tjänster som en del av sitt säkerhetsarbete. Rapporter beskriver tillfälliga avbrott eller underhåll i Japan, Frankrike, Finland och Nederländerna. Amerikanska och europeiska myndigheter uppmanade också organisationer att agera.
18
20
35 Att stänga en webbplats kan minska exponeringen medan arbetet pågår, men betyder inte i sig att webbplatsen har blivit hackad.
Det tillgängliga underlaget bekräftar inte heller på egen hand de uttalanden som tillskrivits Microsofts vd Satya Nadella vid ett evenemang i Köln, vare sig den exakta formuleringen eller sammanhanget. Därför bör sådana uppgifter inte användas som förklaring till hur organisationer agerade.
Vad bör driftansvariga göra?
- Kontrollera PHP-miljön, inte bara webbplatsen. PHP2Shell påverkar PHP-körmiljön. En uppdatering av ett publiceringssystem eller ett tillägg visar inte i sig att PHP-installationen är lagad.
13
- Installera en verifierad rättning. Uppgradera till en lämplig PHP-version med rättningen, eller följ leverantörens instruktioner om en bakåtporterad uppdatering. Kontrollera vilken version som faktiskt körs i produktion.
19
- Undersök tecken på intrång. En uppdatering lagar sårbarheten, men bevisar inte att servern aldrig har varit åtkommen. Granska relevanta loggar och utred misstänkt aktivitet.
- Var försiktig med tillfälliga skydd. Följ aktuell vägledning från PHP-underhållarna eller leverantören. Räkna inte med att en enskild konfigurationsändring eller en webbapplikationsbrandvägg ersätter en verifierad rättning av PHP.
15
27
- Se kontoskydd som ett extra lager. Unika lösenord och multifaktorautentisering skyddar användarkonton, men åtgärdar inte ett serverfel som kan utnyttjas utan inloggning.
För IT-team är skillnaden mellan en sårbarhet, ett attackförsök och ett bekräftat intrång avgörande. Den gör det möjligt att agera snabbt med uppdateringar utan att dra slutsatser om intrång som underlaget inte styrker.