PHP2Shell (CVE-2026-109618 och CVE-2026-109619): vad företag som kör PHP bör göra nu

En tekniker med en bärbar dator som arbetar vid ett serverrack

Den 21 oktober 2026 släppte PHP-projektet PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35 för att rätta två sårbarheter som ”kan möjliggöra fjärrkörning av kod utan autentisering”. Enkelt uttryckt: den som kan skicka en HTTP-förfrågan till din webbplats kan ha möjlighet att köra sin egen kod på din server. Det krävs inget lösenord, och i vissa konfigurationer fungerar attacken innan din applikation har kört en enda rad. Paret har fått namnet PHP2Shell, och PHP ger båda betyget 9,2 (CVSS 4.0, på en skala upp till 10).

Den här guiden är till för dem som måste agera: ägare av PHP-webbplatser och nätbutiker, IT-chefer och alla som har en leverantör som kör PHP åt dem. Den skrevs den 22 oktober 2026, dagen efter att versionerna släpptes, utifrån PHP-projektets egna säkerhetsmeddelanden, nationella cybersäkerhetsmyndigheters vägledning och de siffror som leverantörer har publicerat. Där källorna inte är överens säger vi det.

I korthet

Uppdatera själva PHP och starta sedan om det. Att uppdatera WordPress, Drupal, Laravel eller ett plugin löser inte det här. Felet sitter i PHP, under din applikation.
Varje PHP-installation som hanterar webbförfrågningar omfattas, enligt PHP: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. PHP bedömer att risken är högst för Apache med mod_php.
Nästan hälften av alla PHP-webbplatser kör en gren som PHP-projektet inte längre ger ut versioner för (vår tolkning av data från W3Techs, se nedan). För dem finns det inget officiellt paket att installera.
Inställningar och brandväggar köper tid, inte säkerhet. PHP listar tillfälliga åtgärder och säger att de ”inte gör en installation säker”.
Om du inte kan patcha i dag ger myndigheterna i USA, Storbritannien och EU samma råd: koppla bort systemet från internet tills du kan.

Vad som hände, i tur och ordning

19 augusti 2026. Forskare på Wiz hittar det första av felen, enligt deras offentliggörande, och rapporterar dem till PHP:s säkerhetsteam den 24 augusti. Även forskare från flera andra företag får erkännande i PHP:s säkerhetsmeddelanden.
20 oktober. CVE-numren läcker ut på nätet två dagar före det planerade offentliggörandet. PHP tidigarelägger sin release med en dag, till den 21 oktober kl. 14:00 UTC, och uppmanar alla att förbereda sig.
21 oktober, 03:02 UTC. Cloudflare slår på brandväggsregler för alla kunder som använder företagets WAF, gratisplanen inräknad. Senare rapporterar Cloudflare att företaget ”observerade attacktrafik riktad mot våra kunder” och såg angripare ”ändra attackens payload för att försöka ta sig förbi våra skydd”.
21 oktober, omkring 14:00 UTC. PHP publicerar rättelserna och sitt säkerhetsmeddelande. Samma dag uppmanar CISA i USA, brittiska NCSC, CERT-EU och ett gemensamt uttalande från Europeiska kommissionen, ENISA, CERT-EU, Europol och EU:s nationella CSIRT-enheter samstämmigt organisationer att patcha omedelbart.

Hur allvarligt är det?

Tre saker skiljer det här från de vanliga månadspatcharna.

Angriparen behöver inget annat än en förfrågan. Ingen inloggning, och ingen behöver klicka på en länk. PHP:s säkerhetsmeddelande beskriver en demonstrerad exploit mot Apache med mod_php ”där en oautentiserad förfrågan kan utlösa attacken innan någon applikationskod körs”. Wiz demonstrerade attacker mot aktuella versioner av WordPress, Drupal och Joomla, och påpekar att ”även en enkel ’Hello World’-applikation som körs på en berörd PHP-version kan vara sårbar”. Kod som körs på det här sättet har webbserverkontots rättigheter, och på de flesta webbplatser kan det kontot läsa applikationens konfiguration: databaslösenordet, API-nycklar, inloggningsuppgifter för e-post och betalningar. För det andra felet, CVE-2026-109619, bekräftar PHP också att minnesinnehåll kan röjas: data från serverns minne som läcker ut, även utan fullständig kodkörning.

Antalet installationer är enormt. Enligt W3Techs används PHP av 69,3 % av de webbplatser vars språk på serversidan är känt (siffror från 22 oktober 2026). Unit 42 hos Palo Alto Networks räknar över 22,6 miljoner exponerade instanser som är potentiellt sårbara, utifrån sin egen skanning av internet, och rapporterar att minst en europeisk regering tog ner sin webbplats av försiktighetsskäl.

Arbetet med exploits går snabbt. CERT-EU rapporterar att de första proof of concept-koderna ”har börjat cirkulera”. Säkerhetsföretaget watchTowr säger att dess honeypots har registrerat utnyttjande av sårbarheterna sedan den 21 oktober. Cloudflare rapporterar attacktrafik. Och Wiz säger att dess forskare använde AI-modeller genom hela arbetet, så att en enda forskare på en vecka gjorde det som ”skulle ha tagit ett team i världsklass månader”. Angripare som anpassar en exploit till din PHP-version har samma verktyg.

För att ge hela bilden: när CISA publicerade sin varning den 21 oktober hade myndigheten inte observerat något utnyttjande, och inget av felen fanns ännu i dess katalog Known Exploited Vulnerabilities (kända utnyttjade sårbarheter). Red Hat klassar problemet som ”Important” snarare än kritiskt, eftersom en standardserver med Red Hat Enterprise Linux kör PHP-FPM, där det är svårare att utnyttja felen. Svårare är inte omöjligt: PHP bekräftar att en väg för det andra felet fungerar även på PHP-FPM. Inget av detta ändrar vad du bör göra. Det ändrar bara hur mycket förvarning du kommer att få.

Vilken version kör du? Siffrorna

W3Techs publicerar också vilka PHP-versioner webbplatser kör, räknat på de webbplatser som visar sin version. Om man lägger ihop företagets två tabeller från 22 oktober 2026:

PHP-gren	Andel av PHP-webbplatserna	Rättelse från PHP-projektet
8.3, 8.4, 8.5	cirka 34 %	Ja: 8.3.36, 8.4.27, 8.5.12
8.2	cirka 18 %	Ja: 8.2.35. Men 8.2 når själv end of life den 31 december 2026
8.0, 8.1	cirka 14 %	Ingen release. 8.0 och 8.1: bara backport i källkod
7.x	26,9 %	Ingen release. 7.4: bara backport i källkod; 7.3 och äldre: ingenting
5.x och äldre	7,8 %	Ingenting

Alltså kör cirka 48 % av PHP-webbplatserna en gren som PHP-projektet inte publicerar någon rättad version för, och ytterligare 18 % får sin rättelse nu och förlorar stödet om tio veckor.

Två förbehåll. W3Techs ser bara de webbplatser som visar sin version. Och en Linuxdistribution kan själv ha patchat en gammal gren: Ubuntu har gjort det, som du ser nedan. Versionsnumret ensamt säger inte om du är skyddad. Versionen på leverantörens paket gör det.

Steg 1: Hitta all PHP du kör

Du kan inte patcha det du inte har listat, och PHP är bra på att gömma sig. Brittiska NCSC ber organisationer att hitta varje PHP-system, med de som nås från internet först, och tillägger: ”begränsa inte kartläggningen till föråldrade PHP-versioner”. EU:s gemensamma uttalande varnar för att vissa produkter ”kan påverkas av dessa sårbarheter även om de inte verkar använda PHP direkt”.

Var du ska leta:

Webbplatser och butiker: WordPress och WooCommerce, Drupal, Joomla, Magento och Adobe Commerce, Shopware, PrestaShop, TYPO3 och allt som är byggt på Laravel eller Symfony.
De bortglömda: kampanjsajter, en gammal språkversion, staging- och testservrar som går att nå från internet, webbmejlen eller helpdesksystemet som någon installerade för flera år sedan.
Containrar: varje image som är byggd från basimagen php har sin egen PHP. Att uppdatera värdsystemet gör ingenting för den.
Kontrollpaneler för hosting: cPanel, Plesk och liknande paneler levererar egna PHP-byggen bredvid systemets. Varje version som är aktiverad i panelen är en separat sak att uppdatera.
Produkter med PHP inuti: färdiga enheter (appliances), övervakningsverktyg, CRM-system, helpdesksystem och leverantörers administrationsgränssnitt. Nederländska NCSC för en offentlig lista över sådana produkter med deras status, leverantör för leverantör.
Leverantörer: ditt hostingföretag, din byrå, varje tjänst där du vet att det finns PHP under ytan. Fråga dem skriftligt vilka PHP-versioner som kör dina system och när de kommer att patchas.

Skriv för var och en ner PHP-versionen, hur PHP körs (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, en container), om systemet går att nå från internet och vem som kan patcha det.

Steg 2: Patcha i rätt ordning

Börja med allt som går att nå från internet, och inom det med installationer med Apache och mod_php.

På en gren med stöd (8.2 till 8.5). Uppdatera till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller till det paket från din distribution som innehåller rättelsen. PHP säger att Linuxdistributionerna fick patcharna i förväg. Bekräftat hittills:

Ubuntu: rättade paket för varje release från 14.04 till 26.10. På 22.04 och senare kommer de med de vanliga uppdateringarna; på 20.04 och äldre kräver de en Ubuntu Pro-prenumeration, som är gratis för upp till fem maskiner (Canonicals meddelande).
Debian: php8.4 8.4.27 för Debian 13 (DSA-6574-1) och php8.2 8.2.35 för Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hats säkerhetsbulletin RHSB-2026-013 listar paketen per release.
Remis paketförråd, som används mycket för nyare PHP på system i Red Hat-familjen: den 21 oktober noterade CERT-EU att det inte fanns några paket där på releasedagen och rådde till att byta till distributionens paket eller bygga från källkod. Kontrollera om det har kommit ikapp innan du förlitar dig på det.

På PHP 7.4, 8.0 eller 8.1. PHP-projektet publicerar ingen release för dessa. Projektets säkerhetsteam har gjort minimala backportar i källkod för de tre grenarna, som hjälper om du kompilerar PHP själv. Annars måste rättelsen komma från din leverantör (Ubuntu Pro täcker till exempel PHP 7.4 på Ubuntu 20.04) eller från en uppgradering av PHP. CISA:s råd till alla på 8.1 eller äldre som inte kan uppdatera är rakt på sak: ta systemet offline tills det har patchats eller uppgraderats.

På PHP 7.3 eller äldre. Ingenting kommer från PHP-projektet. Om inte en leverantör fortfarande patchar ditt bygge står valet mellan en uppgradering och att ta systemet offline.

Starta om efter uppdateringen. Att installera ett paket ersätter inte den PHP som redan körs. Ubuntus meddelande säger det rakt ut: applikationen ”skulle sannolikt behöva startas om”. Starta om PHP-FPM, Apache, LiteSpeed eller containern på varje server. Kontrollera sedan vilken version webbservern faktiskt kör, inte bara php -v på kommandoraden, som kan vara ett annat bygge.

Containrar: bygg om dina images från en patchad basimage och driftsätt dem igen. En patchad värd som kör en gammal image är fortfarande exponerad.

Hanterad hosting: fråga din leverantör om datum och version, och kontrollera sedan själv.

Steg 3: Om du inte kan patcha i dag

PHP:s säkerhetsmeddelande listar tillfälliga åtgärder och inleder dem med en varning: de ”minskar exponeringen för specifika attackvägar men gör inte en installation säker”. I korthet, för den som sköter dina servrar:

För CVE-2026-109618: sätt memory_limit=-1 så att applikationen inte kan åsidosätta värdet (till exempel med php_admin_value i PHP-FPM-poolen eller i Apache-konfigurationen); sätt en låg post_max_size (PHP föreslår 8M utan filuppladdningar, 32M med); begränsa förfrågningarnas storlek, antalet fält och antalet multipart-delar i webbservern eller proxyn; och använd en minnesgräns på container- eller cgroup-nivå, aldrig RLIMIT_AS eller RLIMIT_DATA.
För CVE-2026-109619: sätt session.upload_progress.enabled=0 i php.ini eller i serverkonfigurationen (inte med ini_set() eller en .user.ini-fil) och starta om alla worker-processer. På PHP 8.5 ska du också sätta fatal_error_backtraces=0.

Två varningar. Sessionsinställningen som spreds brett den 20 oktober stänger bara vägar för det andra felet, vilket en medlem av PHP:s säkerhetsteam påpekade; mot det första gör den ingenting. Och memory_limit=-1 tar bort PHP:s egen minnesgräns, så att en enda tung förfrågan nu kan uttömma serverns minne. Kombinera det med gränsen på container- eller cgroup-nivå.

En brandvägg för webbapplikationer (WAF) hjälper, lite grann. Cloudflares regler är påslagna som standard för alla planer med företagets WAF, gratisplanen inräknad, och Palo Alto Networks och andra leverantörer har publicerat egna skydd. Cloudflare uppmanar ändå kunderna att patcha PHP ”även med WAF-skydd”, och företaget såg angripare ändra sina payloads för att ta sig förbi reglerna. En WAF skyddar dessutom bara den trafik som passerar genom den. Om din server svarar på sin egen IP-adress kan en angripare gå runt den.

Om inget av detta kan göras snabbt pekar CISA, CERT-EU, NCSC och EU:s gemensamma uttalande alla åt samma håll: koppla bort systemet från det öppna internet tills det är åtgärdat. En underhållssida under en dag kostar mindre än en ombyggd server.

Steg 4: Kontrollera om du redan har drabbats

Fönstret öppnades den 20 oktober, när läckan började, och attacktrafik rapporterades redan nästa morgon. Om ett system var nåbart och opatchat under det fönstret stänger patchningen dörren, men den säger inte om någon tog sig in först. NCSC ber alla som inte kunde patcha omedelbart att leta efter tecken på intrång och bakdörrar.

Vad du ska leta efter, utifrån den publicerade vägledningen och vanlig praxis vid incidenthantering:

PHP-processer som gör saker som PHP aldrig gör, som att starta ett skal eller ladda ner verktyg (CISA).
Ovanliga multipart-förfrågningar följda av fel om minnesgränsen eller upprepade HTTP 500-svar, worker-processer för PHP som startar om utan tydlig anledning, och ovanligt stora eller felformade PHPSESSID-cookies i svaren (Wiz).
Nya eller ändrade PHP-filer i uppladdningsmappar, cachemappar eller webbroten, nya administratörskonton i ditt CMS och schemalagda uppgifter som ingen har skapat.

Rena loggar är inget bevis. PHP:s säkerhetsmeddelande för det andra felet varnar för just det, och Wiz påpekar att applikationsloggarna kan innehålla lite kontext.

Om du hittar något, behandla det som en incident och inte som ett patchjobb. Isolera servern, bevara bevisen, ta in en specialist på incidenthantering och byt ut varje hemlighet som webbservern kunde läsa: databaslösenord, API-nycklar, inloggningsuppgifter för betalningar och e-post, signeringsnycklar. Eftersom det andra felet kan röja minnesinnehåll bör du överväga att byta ut de känsligaste av dessa hemligheter på varje server som var exponerad och opatchad i flera dagar, även utan tecken på intrång.

Steg 5: Vad du kan behöva rapportera

En sårbarhet i sig är ingen rapporteringspliktig incident. En sårbarhet som har utnyttjats kan vara det.

NIS2: om din organisation omfattas och ett intrång utgör en betydande incident ska den tidiga varningen till din nationella CSIRT lämnas inom 24 timmar. Se vår guide till NIS2.
GDPR: om någon har kommit åt personuppgifter måste tillsynsmyndigheten underrättas inom 72 timmar från att du fick kännedom om personuppgiftsincidenten, om det inte är osannolikt att den medför en risk för människor. Se vår guide till GDPR.
Cyberresiliensförordningen (CRA): om du säljer programvara eller en enhet med PHP inuti är du dess tillverkare enligt CRA. Sedan 11 september 2026 har tillverkare varit skyldiga att rapportera aktivt utnyttjade sårbarheter i sina produkter via den gemensamma rapporteringsplattformen för CRA, vilket EU:s gemensamma uttalande påminner om. Se vår guide till CRA.
Dina kunder: om du hostar eller driver PHP åt kunder kommer de att fråga. En kort skriftlig redogörelse (vad du kör, när det patchades, vad du kontrollerade) räcker för de flesta av dem, och det är samma redogörelse som en revisor eller ett cyberförsäkringsbolag kommer att vilja se.

När det akuta är över: vad du bör ändra

På de flesta välskötta servrar kommer PHP2Shell att vara patchat inom några dagar. Det som sårbarheten avslöjade om din miljö gäller fortfarande efteråt.

Vet hur lång tid en patch tar för dig. Från säkerhetsmeddelandet till att varje server är omstartad: timmar, dagar eller veckor? Om det ärliga svaret är ”vi skulle behöva fråga byrån”, åtgärda det före nästa gång. När forskare säger att AI kortade deras arbete med exploiten från månader till en vecka, utgå från att angripare kan hålla samma takt.
Behåll inventeringen som du just har byggt. Den var den svåraste delen av insatsen, och den blir inaktuell i samma stund som ingen äger den.
Lämna PHP-versioner som har nått end of life. En webbplats på 7.4 eller 8.1 behövde en leverantör eller en backport i källkod den här gången; nästa gång kanske ingetdera finns. PHP 8.2 når end of life den 31 december 2026, så en webbplats som lämnar 8.1 bör gå direkt till 8.3 eller senare. Att byta PHP-version innebär ofta att applikationen också måste uppdateras: vår artikel om end of life för Drupal, Umbraco och Kentico visar vad det innebär för ett CMS.
Välj PHP-FPM framför mod_php där du kan. Det var den konfigurationen som hade lägre risk den här gången.
Låt funktionen för uppladdningsförlopp vara avstängd om du inte använder den. PHP:s säkerhetsmeddelande föreslår att session.upload_progress.enabled hålls avstängd även efter patchningen när applikationen inte behöver den.
Skriv in patchtider i dina avtal. Fråga din hostingleverantör och din byrå hur snabbt de installerar kritiska PHP-rättelser, och få svaret skriftligt.

En checklista för den här veckan

Lista varje PHP-installation, inklusive containrar, kontrollpaneler, leverantörsprodukter och stagingservrar.
Patcha system som nås från internet först, och börja med Apache med mod_php.
Starta om varje PHP-process och kontrollera vilken version webbservern rapporterar.
Bygg om containerimages och driftsätt dem på nytt.
Där du inte kan patcha i dag: använd PHP:s tillfälliga inställningar, led trafiken genom en WAF eller ta systemet offline.
Be leverantörer och hostingleverantörer skriftligt om deras PHP-version och patchdatum.
Gå igenom loggar och filändringar på allt som har varit exponerat och opatchat sedan den 20 oktober.
Avgör om en rapporteringsskyldighet (NIS2, GDPR, CRA) gäller.
Planera flytten från PHP 8.1 och äldre, och från 8.2 före den 31 december.

Där vi kan hjälpa till

De flesta företag saknar inte viljan att patcha. Det de saknar är en tydlig bild av vad de kör, eller folk som kan göra jobbet den här veckan. Det är den delen vi tar hand om:

Inventering och patchning, på några dagar. Vi hittar dina PHP-installationer på servrar, i containrar, i hostingpaneler och hos leverantörer, patchar dem, startar om och verifierar, och lämnar en skriftlig redogörelse för vad som gjordes och när. Den redogörelsen är också ditt svar till kunder och revisorer.
Bort från gammal PHP. Applikationer som har fastnat på PHP 7.x, 8.0 eller 8.1 för att koden inte går att köra på något nyare: vi portar dem till en version med stöd inom ramen för vår tjänst för underhåll av äldre system.
Härdning och en patchrutin, så att nästa säkerhetsmeddelande blir ett schemalagt jobb i stället för en akut kris.

Om du hittar tecken på intrång, ring en specialist på incidenthantering först. Vi kan ta hand om ombyggnaden och uppgraderingen parallellt med dem.

Skriv till office@c9group.dev och berätta vad du kör, så svarar vi med vad vi skulle göra först.

Källor

Kontrollerade den 22 oktober 2026. Läget förändras fortfarande: särskilt status för utnyttjande och leverantörernas paket kan ha ändrats sedan dess.

PHP-projektet

Myndigheter

Forskare, leverantörer och data