Kort sagt: Om I bør tage et website offline på grund af PHP-sårbarheden, afhænger af ét spørgsmål: Kører PHP på denne server dokumenteret på en rettet version, og er alle processer genstartet? Hvis ja, er nedlukning ikke nødvendig. Hvis opdateringen ikke er mulig med det samme, anbefaler BSI midlertidigt at tage webserveren af nettet. At vente er kun forsvarligt, hvis systemet ikke bruger PHP, ikke er offentligt tilgængeligt, eller udbyderen skriftligt har bekræftet patchen.
Situationen, hvor I skal beslutte
PHP2Shell omfatter to sårbarheder i selve PHP, CVE-2026-109618 og CVE-2026-109619, begge vurderet til CVSS v4.0 9,2. De tillader udførelse af skadelig kode på afstand uden login. Rettede versioner er tilgængelige siden 21.10.2026: 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Til PHP 8.1 og ældre findes der ikke længere officielle opdateringer.
BSI har udråbt advarselsniveau orange og råder til øjeblikkelig opdatering, subsidiært til midlertidig nedlukning. Ifølge medierapporter har byen Mainz, dele af den hessiske delstatsregering og yderligere offentlige institutioner forebyggende taget websites af nettet; den hessiske statskancelli meldte intet angreb. Hvad virksomheder kan udlede heraf, står under Myndigheder tager websites af nettet.
For ansvarlige i virksomheder er spørgsmålet mere praktisk: Hvad gør vi i dag med vores shop, vores portal, vores virksomhedswebsite?
Tage website offline, patche eller vente: de tre muligheder sammenlignet
Den følgende tabel stiller mulighederne ved siden af hinanden. Den erstatter ikke vurderingen af jeres enkelttilfælde, men gør afvejningen synlig.
| Kriterium | Patche straks | Lukke midlertidigt ned | Vente |
|---|---|---|---|
| Beskyttelse mod PHP2Shell | Høj, hvis patch og genstart er dokumenteret | Høj så længe nedlukningen varer | Ingen, så længe upatchet |
| Driftsafbrydelse | Kort, til opdatering og genstart | Timer til dage | Ingen |
| Forudsætning | Understøttet PHP-version, adgang, vedligeholdelsesvindue | Direktionens beslutning, statisk erstatningsside | Dokumenteret grund til, at der ikke er risiko |
| Indsats | Lav til middel | Lav teknisk, høj organisatorisk | Lav, men kontrolindsats for dokumentationen |
| Typisk tilfælde | Server med PHP 8.2 til 8.5 | Ældre system med PHP 8.1 eller ældre, uklar status | System uden PHP eller kun internt tilgængeligt |
| Restrisiko | Tidligere indbrud forbliver muligt | Tidligere indbrud forbliver muligt | Fuldt bestående |
Én række fortjener opmærksomhed: Hverken patch eller nedlukning afklarer, om der allerede er sket noget før. Ifølge medierapporter fandtes det første observerede angrebsforsøg den 17.10.2026, altså før patchen. Et blik på mulige spor hører derfor med til enhver mulighed.
Til beslutningen i fem spørgsmål
Gennemgå spørgsmålene efter tur. Det første klare svar fører som regel til beslutningen.
- Kører der overhovedet PHP på systemet, og kan det nås fra internettet? Hvis nej, er systemet ikke direkte berørt af PHP2Shell. Dokumentér, hvordan I har konstateret det.
- Er patch-status dokumenteret? Dokumenteret betyder: rettet version eller backport med CVE-numre i pakkens changelog og genstart af alle PHP-processer. En versionsvisning i panelet er ikke nok. Hvordan I kontrollerer det, står under Kontrollér PHP-version og patchstatus korrekt.
- Kan opdateringen indspilles inden for de næste timer? Hvis ja: patche, genstarte, kontrollere. Indtil da kan midlertidige foranstaltninger hjælpe.
- Er det ikke muligt, f.eks. på grund af PHP 8.1 eller manglende adgang? Så er midlertidig nedlukning ifølge BSI vejen. Midlertidige foranstaltninger efter php.net sænker risikoen, men beskytter ikke fuldstændigt; enkeltheder står under Hasteforanstaltninger, hvis I endnu ikke kan patche.
- Er der tegn på kompromittering? Så er spørgsmålet ikke længere "patche eller lukke ned", men "behandle hændelsen". Lukke ned, sikre beviser, ikke slette forhastet.
Hvis I lukker ned: Luk ned på rigtig måde
En nedlukning skal fjerne angrebsfladen, ikke blot skjule forsiden. En vedligeholdelsesside, der fortsat genereres af PHP, opfylder ikke dette formål. Bedre er en statisk HTML-side, som webserveren leverer uden PHP, eller en omdirigering til en anden server.
Tænk på alt, hvad der hænger på det samme PHP: undersider, grænseflader til apps eller varedispositionssystemer, admin-områder, betalings-callbacks. Tal på forhånd med betalingsudbyder og logistik, hvis en shop er berørt. Og informér medarbejdere og kunder i klare vendinger: Siden er forebyggende offline, kontakt foregår via telefon og e-mail. Det er bedre end tavshed, som nærer spekulationer.
Vigtig er også nedlukningens afslutning. Fastlæg, på hvilken betingelse siden kommer online igen, f.eks. "PHP på rettet version, genstart kontrolleret, første sporkontrol uden fund". Så bliver en nødbremse til et ordnet forløb.
At lukke ned er ikke et nederlag. Flere offentlige instanser har ifølge medierapporter gjort netop det, uden at der forelå et angreb. En forebyggende nedlukning betyder ikke automatisk, at et website er blevet hacket.
Hvornår I ikke har brug for en leverandør
Ikke enhver beslutning kræver ekstern hjælp. Hvis jeres website ligger hos en hostingudbyder, der skriftligt bekræfter patch-status og genstart, og der ikke er nogen påfaldende forhold, er I godt stillet med en kort dokumentation. Det samme gælder, hvis jeres egen it selv kan patche en server med understøttet PHP-version og behersker kontrollen.
Hjælp kan betale sig, hvis der kører systemer med gammel PHP-version, status er uklar, flere servere er berørt, eller der foreligger tegn på et indbrud.
Hvordan hjælper PHP SOS konkret?
- Vi afklarer sammen med jer på kort tid, hvilke systemer der er berørt, og hvilken patch-status der er dokumenteret.
- Vi leverer direktionen et beslutningsgrundlag på én side: muligheder, risici, anbefalet vej.
- Vi gennemfører den valgte vej, altså patch med genstart, midlertidige foranstaltninger eller en ren nedlukning med statisk erstatningsside, som en del af vores PHP2Shell-akuthjælp.
- Vi kontrollerer for spor siden 17.10.2026 og dokumenterer resultatet.
Konklusion
At patche er normaltilfældet, at lukke ned den rette nødbremse, at vente kun forsvarligt med bevis. Den, der besvarer de fem spørgsmål ærligt og fastholder beslutningen skriftligt, handler i overensstemmelse med BSI's anbefaling og kan senere vise hvorfor.
Ofte stillede spørgsmål
Skal jeg tage mit website offline på grund af PHP2Shell?
Ikke hvis PHP allerede kører på en rettet version, og alle processer er genstartet. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler midlertidig nedlukning, hvis en øjeblikkelig opdatering ikke er mulig.
Hvad koster en nedlukning mest: omsætning eller risiko?
Det kan kun besvares i det enkelte tilfælde. Et nedbrud på timer kan som regel planlægges bedre end et indbrud, hvis følger og varighed ingen kender. Fasthold afvejningen skriftligt, uanset hvordan den falder ud.
Må en vedligeholdelsesside køre via den samme server?
Ja, hvis den leveres som en statisk fil uden PHP. Genereres vedligeholdelsessiden fortsat af PHP, forbliver angrebsfladen.
Er det nogensinde det rigtige valg at vente?
Ja, i klart afgrænsede tilfælde: hvis der ikke kører PHP på systemet, hvis det ikke kan nås fra internettet, eller hvis udbyderen skriftligt har bekræftet patch og genstart. At vente uden sådanne beviser er ikke en mulighed, men en risiko.
Hvem bør træffe beslutningen?
Den person, der er ansvarlig for forretningsrisikoen, som regel direktionen eller ejeren. It leverer fakta. Hvem der beslutter, bør stå i nødplanen på forhånd.