Kort sagt: PHP-sårbarheden PHP2Shell består af to kritiske fejl i PHP, grundlaget for de fleste websites og webshops. Angribere kan herigennem uden adgangskode udføre skadelig kode på webservere. BSI (det tyske forbundsagentur for informationssikkerhed) advarer med niveau orange og anbefaler: opdatér straks, ellers tag berørte servere midlertidigt af nettet. For ledelsen betyder det i dag: afklar ansvaret, kræv opdatering og dokumentation, beslut om en nedlukning, og dokumentér alt.
Situationen i tre sætninger
Den 21. oktober 2026 udgav PHP-projektet opdateringer til to kritiske sikkerhedssårbarheder, kendt under navnet PHP2Shell. Berørt er PHP selv, ikke et bestemt produkt, altså potentielt ethvert website, enhver shop og ethvert portal, der kører med PHP. BSI har udråbt advarselsniveau 3 / orange, sikkerhedsfirmaer rapporterer om angrebsforsøg, og bekræftede vellykkede angreb i bredden var ifølge BSI indledningsvis ikke kendt.
Myndigheder som BKA (det tyske kriminalpoliti på forbundsplan) og flere byer har ifølge mediedækning lukket deres websites ned som forholdsregel. Det var forsigtighed, ikke tegn på et angreb.
Hvad PHP-sårbarheden betyder for ledelsen og virksomheden
Spørgsmålet er ikke, om I bruger PHP. Næsten alle virksomheder gør det et sted: website, shop, ansøgerportal, kundeområde, intranet, ticketsystem, bureauets microsite. Spørgsmålet er, om disse systemer er opdaterede, og hvem der er ansvarlig for dem.
Lykkes et angreb, kan angriberen i værste fald overtage serveren. Mulige følger er datalækage, manipuleret indhold, omdirigeringer til svindelsider, nedbrud af shoppen eller misbrug af serveren til yderligere angreb. Hvis personoplysninger kan være berørt, kommer der anmeldelsespligter til; fristen efter art. 33 GDPR er som regel 72 timer. Enkeltheder herom står under GDPR-anmeldelsespligt. Dette er ikke juridisk rådgivning.
Hvilke omkostninger der typisk opstår i en alvorlig situation, vurderer indlægget Omkostningsposter ved et hackerangreb.
Hvor PHP ofte overses i virksomheder
Hovedwebsitet har de fleste styr på. Systemer i udkanten overses snarere: ansøgerportalen hos en ekstern udbyder, landingssiden fra en tidligere kampagne, et partnerområde for forhandlere, supportens ticketsystem, en fil-cloud på egen server eller weboverfladen på et netværksdrev. Også bureauers testsystemer er ofte offentligt tilgængelige og kører på den samme server som det rigtige website.
For ledelsen er lærdommen enkel: Spørgsmålet til it lyder ikke „Er vores website patchet?“, men „Er alle vores systemer med PHP patchet, også dem hos serviceudbydere?“. Forskellen mellem de to spørgsmål er ofte netop det sted, hvor et angreb lykkes.
Hvad situationen ikke er
Lige så vigtig er vurderingen nedad. PHP2Shell er ingen grund til aktionisme, der forstyrrer driften mere end nødvendigt. Den, der dokumenteret har patchet, har genstartet alle PHP-processer og ikke finder noget påfaldende ved kontrollen, kan vende tilbage til normaldrift. En midlertidig nedlukning er en mulighed i uafklarede tilfælde, ikke en pligt for alle.
Fem spørgsmål til jeres it eller serviceudbyder
Disse spørgsmål kan I stille i dag. Svarene bør komme skriftligt.
- Hvilke af vores systemer kører med PHP? En liste med adresse, formål og driftsansvarlig.
- Er hvert system patchet? Rettet version 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller en backport bekræftet af udbyderen.
- Er alle PHP-processer genstartet? Uden genstart virker opdateringen ikke.
- Hvad med systemer på PHP 8.1 eller ældre? Dertil findes der ingen officielle opdateringer. Hvad er planen?
- Er det undersøgt, om der skete noget før opdateringen? Logs fra og med den 20. oktober sikret, spor eftersøgt?
Ligger jeres website hos en hostingudbyder, hjælper en formel forespørgsel. En skabelon giver vejledningen Anmod hostingudbyderen om bekræftelse af PHP-opdatering.
Beslutningerne, der bør træffes i dag
| Beslutning | Muligheder | Grundlag |
|---|---|---|
| Hvem leder? | en ansvarlig person internt, en ekstern partner | ansvaret skal være entydigt |
| Ikke patchede systemer | patche straks, midlertidige foranstaltninger, midlertidigt lukke ned | BSI-anbefaling, datasituation, omsætningsrelevans |
| Undersøgelse for spor | internt, eksternt, kun ved påfaldende forhold | beskyttelsesbehovet for dataene på serveren |
| Kommunikation | informere internt, forberede kunder, vente | situationen efter undersøgelsen |
| Ældre systemer | planlægge migrering, isolere, lukke ned | PHP 8.1 og ældre uden officielle opdateringer |
Fasthold, hvem der besluttede hvad hvornår og på hvilket informationsgrundlag. En kort, dateret notits er nok. Over for forsikringsselskaber, kunder eller tilsynsmyndigheder er den bagefter ofte mere værd end enhver efterfølgende forklaring.
Hvorfor denne dokumentation er vigtig for ledelsen, forklarer siden Ledelsens ansvar ved it-sikkerhedssårbarheder. Dette er almen information og ikke juridisk rådgivning.
Hvad I ikke bør tro på
Tre udsagn hører direktører for tiden ofte, og alle tre er forkerte:
- „Vi har opdateret WordPress, så vi er sikre.“ Sårbarheden sidder i PHP, ikke i CMS'et. En CMS-opdatering lukker den ikke.
- „Vi er for små, ingen angriber os.“ Angreb kører automatiseret. Der søges efter sårbare servere, ikke efter kendte navne.
- „Opdateringen er på, så er sagen afsluttet.“ En patch fjerner ikke skadelig software, der blev smuglet ind før, og beviser ikke, at der intet er sket.
Hvordan hjælper PHP SOS konkret?
- Situationsbillede til ledelsen: Vi udarbejder en kort oversigt over jeres PHP-systemer med status og anbefaling for hvert system.
- Gennemførelse: Vi patcher, genstarter eller indsætter midlertidige foranstaltninger, hvor en opdatering endnu ikke er mulig.
- Undersøgelse: Vi sikrer logs og undersøger for spor af et angreb.
- Dokumentation: I modtager en dokumentation, som I kan bruge internt og over for tredjeparter.
Forløbet beskrives under PHP2Shell-akuthjælp.
Konklusion
PHP2Shell er en teknisk sårbarhed med en ledelsesopgave. Teknikken klarer fagfolk. Ledelsen sørger for, at nogen har ansvaret, at de fem spørgsmål bliver besvaret, og at beslutninger træffes bevidst og dokumenteres. Det kan nås på en formiddag, hvis det begynder i dag.
Ofte stillede spørgsmål
Skal ledelsen selv tage sig af PHP2Shell?
Ikke den tekniske gennemførelse, men styringen. Ledelsen bør sikre, at ansvarsområderne er klare, at BSI's anbefaling gennemføres, og at beslutninger som en midlertidig nedlukning træffes bevidst og dokumenteres.
Hvordan forklarer jeg sårbarheden i én sætning?
I PHP, den software, som de fleste websites og shops kører på, findes der to kritiske fejl, hvorigennem fremmede uden adgangskode kan starte programmer på serveren; en opdatering er tilgængelig og skal indspilles.
Hvad koster det ikke at gøre noget?
Det kan ikke opgøres generelt. Mulige følger af et vellykket angreb er nedetid, datalækage, anmeldelsespligter, udgifter til oprydning og forensik samt tab af kundernes tillid. En opdatering med kontrol er som regel markant mindre omkostningskrævende.
Er det nok, at hostingudbyderen tager sig af det?
Ved shared hosting indspiller som regel hostingudbyderen opdateringen. Lad jer det bekræfte skriftligt, herunder genstart af PHP-processerne. Om der skete noget før opdateringen, besvarer bekræftelsen ikke; til det kræves en undersøgelse af websitet.