Kort sagt: PHP2Shell og Log4Shell har tilfælles, at de er kritiske sårbarheder i en meget udbredt grundbyggesten, hvorigennem angribere kan udføre kode uden login. De adskiller sig i synlighed, vurdering og situationen ved kendte angreb. Den vigtigste lærdom fra Log4Shell gælder i dag uændret: Den, der ved, hvor den berørte byggesten kører, handler på timer i stedet for uger.
Hvorfor sammenligningen netop dukker op overalt
I december 2021 holdt Log4Shell it-verdenen i ånde i ugevis. BSI udråbte dengang det højeste advarselsniveau, rød. Næsten fem år senere falder det samme navn i mange indlæg om PHP2Shell, ofte forbundet med spørgsmålet: „Bliver det igen så slemt?“
Sammenligningen er nærliggende, og den er nyttig, hvis man fører den rigtigt. Den viser, hvilke mønstre der gentager sig, og hvilke erfaringer virksomheder i dag kan bruge direkte. Hvordan BSI vurderer den aktuelle situation, forklarer indlægget BSI-advarselsniveau orange.
PHP2Shell og Log4Shell direkte sammenlignet
| Kendetegn | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Berørt software | Java-biblioteket Log4j | selve PHP-kørselsmiljøet |
| Identifikator | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Vurdering | CVSS 10,0 (v3) | CVSS v4.0 9,2 |
| Virkning | kodeudførelse uden login | kodeudførelse uden login |
| BSI-advarselsniveau | 4 / rød | 3 / orange |
| Situation ved advarslen | ifølge datidens rapporter kompromitteringer kendt | angrebsforsøg rapporteret, ifølge BSI indledningsvis ingen bekræftede vellykkede angreb i bredden |
| Synlighed | ofte skjult dybt i applikationer | synlig på serveren, men patchstatus svær at aflæse pga. backports |
| Opfølgende meddelelser | flere yderligere CVE'er på få uger | henvisning til CVE-2026-115560 den 23.10. |
Hvad de to sårbarheder har tilfælles
Én grundbyggesten, utallige applikationer. Log4j sad i Java-software af alle slags, PHP bærer WordPress, Shopware, TYPO3 og utallige egenudviklinger. I begge tilfælde er det ikke ét produkt, der er berørt, men et fundament.
Intet login nødvendigt. Begge sårbarheder tillader udførelse af kode på afstand uden login. Det gør dem attraktive for automatiserede angreb.
Patchen er ikke slutningen. Ved Log4Shell viste det sig, at mange systemer allerede var angrebet før opdateringen. Også ved PHP2Shell gælder: En patch fjerner ikke skadelig software, der er smuglet ind. Ifølge mediedækning blev et første angrebsforsøg allerede observeret den 17. oktober.
Opfølgende meddelelser. Efter Log4Shell udkom der inden for få uger flere CVE'er om Log4j. Ved PHP kom henvisningen til CVE-2026-115560 to dage efter patchene. Hvorfor flere meddelelser er sandsynlige, forklarer Efter PHP2Shell: Hvorfor flere meddelelser er sandsynlige.
Hvor sammenligningen halter
Den største forskel ligger i synligheden. Log4j var ofte bygget ind som del af en applikation, nogle gange flere gange indlejret. Mange driftsansvarlige vidste simpelthen ikke, at de brugte det. PHP derimod er på en webserver ingen hemmelighed. Til gengæld opstår der ved PHP2Shell en anden uklarhed: Distributioner og hostingudbydere indspiller rettelser som backport, det viste versionsnummer forbliver det samme. Man ser PHP, men ikke straks, om det er patchet.
En anden forskel er udgangspunktet ved opdateringen. Ved Log4Shell skulle producenter af fagapplikationer ofte først levere nye versioner. Ved PHP2Shell står opdateringer klar til alle understøttede grene. Vanskeligt bliver det ved PHP 8.1 og ældre, hvortil PHP-projektet ikke længere udgiver officielle opdateringer.
En tredje forskel angår angrebets sted. Ved Log4Shell kunne ethvert sted være farligt, hvor en applikation loggede input, altså også interne systemer, der kun indirekte modtog data fra internettet. Ved PHP2Shell står webserveren i centrum, som modtager forespørgsler direkte. Det gør søgningen efter berørte systemer lidt mere overskuelig: Først kommer alle offentligt tilgængelige PHP-tjenester, derefter interne applikationer.
Endelig adskiller situationen sig ved udnyttelsen. Til Log4Shell cirkulerede der tidligt simple angrebsværktøjer, og kompromitteringer var ifølge datidens rapporter allerede kendt på tidspunktet for advarslen. Ved PHP2Shell rapporterer Cloudflare og Patchstack om angrebsforsøg, watchTowr har efter egne oplysninger genskabt en af sårbarhederne, men bekræftede vellykkede angreb i bredden meldte BSI indledningsvis ikke. Det kan ændre sig. Det er dog en grund til, at sammenligningen ikke duer som prognose.
Brug erfaringerne fra Log4Shell i eget hus: Hvilke lister, forløb og kontakter hjalp dengang? Meget af det kan genbruges direkte til PHP2Shell.
Fem lærdomme fra Log4Shell, der hjælper i dag
- Inventar før patch: Den, der i 2021 havde en aktuel liste over sine systemer, var hurtigere. Det gælder lige så meget i dag. En vejledning giver indlægget Inventar over alle websites og servere.
- Kend afhængighederne: En stykliste over softwarebyggesten, kort SBOM, besvarer spørgsmålet „Hvor bruger vi det?“ på minutter. For PHP-applikationer hjælper et blik i Composer, som Kontrollér Composer-afhængigheder beskriver.
- Opbevar logs: Efter Log4Shell kunne mange virksomheder ikke længere afklare, om de var berørt, fordi logs manglede. Fagpressen anbefaler ved PHP2Shell at sikre logs fra og med den 20. oktober.
- Undersøg bagefter: En patch besvarer ikke, hvad der skete før. En undersøgelse for spor hører med.
- Vær forberedt på opfølgende meddelelser: Den første opdatering er sjældent den sidste. Den, der én gang har indrettet opdateringsvejen ordentligt, gentager den hurtigt.
Hvordan hjælper PHP SOS konkret?
- Opgørelse: Vi fastslår, hvor PHP kører i jeres virksomhed, i hvilken version og driftsform.
- Patch og genstart: Vi indspiller opdateringer og dokumenterer status for hvert system.
- Sporundersøgelse: Vi sikrer logs og undersøger for påfaldende forhold siden den 17. oktober.
- Varig observation: Vi holder øje med jeres systemer, så opfølgende meddelelser ikke igen begynder fra nul.
Hvordan den løbende overvågning ser ud, beskriver Security-monitoring for webservere.
Konklusion
PHP2Shell er ikke Log4Shell, men det rimer. Begge rammer et fundament, begge kræver mere end en patch. Virksomheder, der fra 2021 har taget inventar, logopbevaring og opdateringsveje med, har en fordel i dag. For alle andre er nu tidspunktet til at indhente det.
Ofte stillede spørgsmål
Er PHP2Shell lige så slem som Log4Shell?
Begge er kritiske sårbarheder i meget udbredt software, hvorigennem angribere kan udføre kode uden login. BSI (det tyske forbundsagentur for informationssikkerhed) vurderede Log4Shell til rød i 2021, PHP2Shell til orange. En vigtig forskel: Ved Log4Shell var kompromitteringer ifølge datidens rapporter allerede kendt ved advarslen, ved PHP2Shell var der ifølge BSI indledningsvis ingen bekræftede vellykkede angreb i bredden.
Hvad var Log4Shell?
Log4Shell var en kritisk sårbarhed i Java-biblioteket Log4j, som blev kendt i december 2021 og føres under CVE-2021-44228. Log4j sad som byggesten i meget mange applikationer, ofte uden at driftsansvarlige vidste det.
Kommer der flere sårbarheder efter PHP2Shell?
Det er muligt. Efter Log4Shell fulgte inden for få uger flere CVE'er om Log4j. Ved PHP var der den 23. oktober allerede en henvisning til CVE-2026-115560, der kun virker ved usædvanlig konfiguration. Regn med opfølgende meddelelser.
Hvad er en SBOM?
En Software Bill of Materials er en stykliste over alle softwarebyggesten, som en applikation består af. Med den kan man ved en ny sårbarhed hurtigt fastslå, hvor den berørte byggesten er i brug.