Kort sagt: Om ni bör ta en webbplats offline på grund av PHP-luckan hänger på en fråga: Körs PHP på den servern belagt på en rättad version, och är alla processer omstartade? Om ja behövs ingen avstängning. Om uppdateringen inte går att göra direkt rekommenderar BSI (tyska förbundskontoret för informationssäkerhet) att tillfälligt ta webbservern från nätet. Att avvakta är bara försvarbart om systemet inte använder PHP, inte är offentligt nåbart eller om leverantören skriftligt har bekräftat patchen.
Läget där ni måste besluta
PHP2Shell omfattar två luckor i själva PHP, CVE-2026-109618 och CVE-2026-109619, båda graderade med CVSS v4.0 9.2. De tillåter körning av skadlig kod på distans utan inloggning. Rättade versioner finns sedan 21.10.2026: 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre.
BSI har utfärdat varningsnivå orange och råder till omedelbar uppdatering, i andra hand till tillfällig avstängning. Enligt medierapporter har staden Mainz, enheter inom Hessens delstatsregering och ytterligare offentliga inrättningar tagit webbplatser från nätet i förebyggande syfte; den hessiska delstatskansliet rapporterade inget angrepp. Vad företag kan dra för slutsatser av det står under Myndigheter tar webbplatser från nätet.
För ansvariga i företag är frågan mer praktisk: Vad gör vi med vår webbshop, vår portal, vår företagswebbplats i dag?
Ta webbplatsen offline, patcha eller avvakta: de tre alternativen jämförda
Följande tabell ställer alternativen bredvid varandra. Den ersätter inte bedömningen av ert enskilda fall men gör avvägningen synlig.
| Kriterium | Patcha direkt | Stänga av tillfälligt | Avvakta |
|---|---|---|---|
| Skydd mot PHP2Shell | Högt, om patch och omstart är belagda | Högt under avstängningens varaktighet | Inget, så länge det är opatchat |
| Driftavbrott | Kort, för uppdatering och omstart | Timmar till dagar | Inget |
| Förutsättning | PHP-version som stöds, åtkomst, underhållsfönster | Beslut av ledningen, statisk ersättningssida | Belagd grund till varför ingen risk finns |
| Arbetsinsats | Låg till medelhög | Låg tekniskt, hög organisatoriskt | Låg, men granskningsinsats för beläggen |
| Typiskt fall | Server med PHP 8.2 till 8.5 | Äldre system med PHP 8.1 eller äldre, oklart läge | System utan PHP eller bara internt nåbart |
| Kvarstående risk | Ett tidigare intrång kan finnas kvar | Ett tidigare intrång kan finnas kvar | Fullt kvarstående |
En rad förtjänar uppmärksamhet: Varken patch eller avstängning klargör om något redan hänt tidigare. Enligt medierapporter inträffade det första observerade angreppsförsöket den 17.10.2026, alltså före patchen. En blick på möjliga spår hör därför till varje alternativ.
Till beslutet med fem frågor
Arbeta igenom frågorna i ordning. Det första tydliga svaret leder oftast till beslutet.
- Körs det över huvud taget PHP på systemet, och kan det nås från internet? Om nej berörs systemet inte direkt av PHP2Shell. Dokumentera hur ni har konstaterat det.
- Är patchstatusen belagd? Belagd innebär: rättad version eller backport med CVE-nummer i paketets changelog och omstart av alla PHP-processer. En versionsvisning i panelen räcker inte. Hur ni kontrollerar det står under Kontrollera PHP-version och patchstatus på rätt sätt.
- Går uppdateringen att installera de närmaste timmarna? Om ja: patcha, starta om, kontrollera. Fram till dess kan övergångsåtgärder hjälpa.
- Är det inte möjligt, till exempel på grund av PHP 8.1 eller saknad åtkomst? Då är tillfällig avstängning enligt BSI vägen. Övergångsåtgärder enligt php.net sänker risken men skyddar inte fullständigt; detaljerna står under Akutåtgärder när ni ännu inte kan patcha.
- Finns det tecken på komprometterande? Då är frågan inte längre ”patcha eller stänga av” utan ”hantera incidenten”. Stäng av, säkra bevis, radera inte förhastat.
Om ni stänger av: stäng av rätt
En avstängning ska ta bort angreppsytan, inte bara dölja startsidan. En underhållssida som fortfarande genereras av PHP fyller inte det syftet. Bättre är en statisk HTML-sida som webbservern levererar utan PHP, eller en omdirigering till en annan server.
Tänk på allt som hänger på samma PHP: undersidor, gränssnitt för appar eller affärssystem, administrationsområden, betalningsåteranrop. Tala i förväg med betalningsleverantör och logistik om en webbshop berörs. Och informera medarbetare och kunder i klartext: Sidan är offline i förebyggande syfte, kontakten sker via telefon och e-post. Det är bättre än tystnad som göder spekulationer.
Viktigt är också avstängningens slut. Fastställ under vilket villkor sidan kommer tillbaka online, till exempel ”PHP på rättad version, omstart kontrollerad, första spårprövning utan fynd”. Så blir en nödbroms ett ordnat förlopp.
Att stänga av är inget nederlag. Flera offentliga instanser har enligt medierapporter gjort just det utan att något angrepp förelåg. En avstängning i förebyggande syfte innebär inte automatiskt att en webbplats har hackats.
När ni inte behöver någon leverantör
Inte varje beslut kräver extern hjälp. Ligger er webbplats hos en hostingleverantör som skriftligt bekräftar patchstatus och omstart, och det inte finns några avvikelser, är ni väl rustade med en kort dokumentation. Detsamma gäller om er egen IT själv kan patcha en server med PHP-version som stöds och behärskar kontrollen.
Hjälp lönar sig när system med gammal PHP-version körs, läget är oklart, flera servrar berörs eller det finns tecken på ett intrång.
Hur hjälper PHP SOS konkret?
- Vi klargör med er på kort tid vilka system som berörs och vilken patchstatus som är belagd.
- Vi levererar ett beslutsunderlag på en sida till ledningen: alternativ, risker, rekommenderad väg.
- Vi genomför den valda vägen, alltså patch med omstart, övergångsåtgärder eller en ren avstängning med statisk ersättningssida, som en del av vår PHP2Shell-akuthjälp.
- Vi prövar om det finns spår sedan 17.10.2026 och dokumenterar resultatet.
Slutsats
Att patcha är normalfallet, att stänga av är rätt nödbroms, att avvakta är bara försvarbart med belägg. Den som ärligt besvarar de fem frågorna och dokumenterar beslutet skriftligt handlar i linje med BSI:s rekommendation och kan senare visa varför.
Vanliga frågor
Måste jag ta min webbplats offline på grund av PHP2Shell?
Inte om PHP redan körs på en rättad version och alla processer är omstartade. BSI rekommenderar tillfällig avstängning för det fall att en omedelbar uppdatering inte är möjlig.
Vad kostar en avstängning mer: omsättning eller risk?
Det kan bara besvaras i det enskilda fallet. Ett avbrott på några timmar går oftast att planera bättre än ett intrång vars följder och varaktighet ingen känner till. Dokumentera avvägningen skriftligt, oavsett hur den slutar.
Får en underhållssida köras via samma server?
Ja, om den levereras som en statisk fil utan PHP. Genereras underhållssidan fortfarande av PHP kvarstår angreppsytan.
Är det någonsin rätt val att avvakta?
Ja, i tydligt avgränsade fall: om det inte körs någon PHP på systemet, om det inte kan nås från internet eller om leverantören skriftligt har bekräftat patch och omstart. Att avvakta utan sådana belägg är inget alternativ utan en risk.
Vem bör fatta beslutet?
Den som ansvarar för affärsrisken, som regel ledningen eller ägaren. IT levererar fakta. Vem som beslutar bör stå i krisplanen i förväg.