PHP2Shell blev en akut säkerhetsfråga för organisationer som driver webbplatser med PHP. Den 21 oktober 2026 släppte PHP uppdateringar för två kritiska brister som kunde göra det möjligt för en angripare att köra kod på en server utan att logga in. Ett läckage dagen före gjorde att uppdateringarna kom tidigare än planerat.
4
6
13
Men en viktig skillnad försvann lätt i larmrapporterna: många potentiellt utsatta system betyder inte att alla hade blivit hackade. Underlaget visar ett brådskande behov av att inventera och uppdatera PHP-miljöer, men belägger inte någon omfattande våg av lyckade intrång.
Vad var PHP2Shell?
Namnet PHP2Shell syftar på två sårbarheter i själva PHP-kärnan: CVE-2026-109618 och CVE-2026-109619. Den ena rör minneskorruption när PHP får slut på minne; den andra handlar om inaktuellt globalt tillstånd. Båda kan leda till fjärrkörning av kod, och båda fick betyget 9,2 av 10 enligt CVSS v4.0.
7
9
10
Bristerna berörde webbservrar med PHP 5.4 till 8.5, enligt flera sammanställningar. Det pekar på att problemet sträckte sig långt bakåt i PHP:s versionshistorik, men källmaterialet fastställer inte exakt att det funnits i 14 år.
1
14
AI-stöd i upptäcktsarbetet
Calif hittade bristerna i augusti inom ramen för OpenAI-initiativet Patch the Planet. OpenAI uppgav att GPT-5.6 Sol användes i arbetet. Wiz identifierade också sårbarheterna genom en självständig undersökning; en redogörelse anger att Wiz använde Wiz Atlas, Gemini 4 Argon och GPT-5.6 Sol. Det tillgängliga materialet ger däremot inte en säker karta över vilket verktyg som bidrog till varje enskilt fynd.
6
18
21
Det här är ett exempel på AI-stöd i säkerhetsforskning – inte i sig ett bevis för att AI gynnar försvarare mer än angripare, eller tvärtom.
5
6
Läckage, akuta uppdateringar och äldre versioner
Uppgifter om sårbarheterna blev offentliga den 20 oktober. PHP hade planerat att släppa rättningarna den 22 oktober, men publicerade dem i stället den 21 oktober.
2
7
24
Uppdateringarna gäller PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. PHP uppmanade användare att uppdatera installationer som hanterar webbtrafik.
5
15 PHP 8.1 och äldre grenar får inte längre regelbundna säkerhetsuppdateringar från PHP-projektet. Det betyder inte nödvändigtvis att alla användare saknar en möjlig rättning: vissa Linuxdistributioner och leverantörer av långtidsstöd kan erbjuda egna bakåtporterade fixar.
Den amerikanska säkerhetsmyndigheten NSA rekommenderade att organisationer inventerar tjänster som använder PHP och prioriterar leverantörernas uppdateringar. Även CISA och stora teknikleverantörer publicerade råd till kunder.
17
18
3
Många potentiellt utsatta system – men vad vet vi om intrång?
PHP uppskattas ligga bakom omkring 70 procent av webben, och Palo Alto Networks uppgav att fler än 22,6 miljoner internetexponerade instanser kunde vara sårbara. Det är uppskattningar av möjlig exponering, inte en räkning av bekräftade komprometterade servrar.
23
Amazon rapporterade ett försök att utnyttja sårbarheten den 17 oktober, fyra dagar innan den offentliga informationen kom. Försöket visar att aktivitet före publiceringen rapporterats, men bekräftar inte i sig att angriparen lyckades ta sig in i ett produktionssystem.
4
6
Det fanns också motstridiga bedömningar av hur sannolikt ett storskaligt utnyttjande var. Sansec skrev den 22 oktober att massutnyttjande verkade mindre sannolikt än bolaget först hade trott. Försök, fungerande demonstrationer och bekräftade intrång är olika saker och bör inte blandas ihop.
10
En senare varning – och andra säkerhetsnyheter
Den 23 oktober varnade PHP för en separat, ovanlig väg till fjärrkörning av kod, CVE-2026-115560, kopplad till särskilda sessionsinställningar. Som tillfällig åtgärd rekommenderades session.upload_progress.enabled=0 fram till nästa ordinarie felrättningsversion. PHP beskrev risken som osannolik och beroende av en ovanlig kombination av konfiguration och programkod.
9
19
Samma period uppmärksammades även andra säkerhetsfrågor, bland annat en Node.js-demonstration som kallades Node2Shell. Sammanställningar nämnde också eMudhra och LiteLLM, men det tillgängliga materialet ger inte tillräckligt underlag för att här reda ut omfattningen av de incidenterna. De ska inte heller blandas ihop med PHP2Shell.
2
10
Den praktiska slutsatsen är tydlig: ta reda på var PHP körs, kontrollera vilken version som används och installera rätt uppdatering eller leverantörens motsvarande fix. En potentiellt sårbar instans är en anledning att agera – inte ett bevis på att den redan har blivit komprometterad.
1
6