# PHP2Shell och Log4Shell: vad sårbarheterna har gemensamt

> PHP2Shell och Log4Shell i jämförelse: vad sårbarheterna har gemensamt, var de skiljer sig och vilka lärdomar från 2021 företag kan använda i dag.

Källa: https://phpsos.de/sv/blog/php2shell-und-log4shell/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** PHP2Shell och Log4Shell har gemensamt att de är kritiska sårbarheter i en mycket utbredd grundbyggsten, där angripare kan köra kod utan inloggning. De skiljer sig i synlighet, klassning och läget vid kända angrepp. Den viktigaste lärdomen från Log4Shell gäller oförändrat i dag: den som vet var den berörda byggstenen körs agerar på timmar i stället för veckor.

## Varför jämförelsen just nu dyker upp överallt

I december 2021 höll Log4Shell IT-världen i spänning i veckor. BSI utlyste då högsta varningsnivån röd. Nästan fem år senare nämns samma namn i många inlägg om PHP2Shell, ofta förenat med frågan: ”Blir det lika illa igen?”

Jämförelsen ligger nära till hands, och den är användbar om man för den rätt. Den visar vilka mönster som upprepas och vilka erfarenheter företag kan använda direkt i dag. Hur BSI klassar det aktuella läget förklarar inlägget [BSI:s varningsnivå orange](https://phpsos.de/sv/blog/bsi-warnstufe-orange-erklaert/).

## PHP2Shell och Log4Shell i direkt jämförelse

| Kännetecken | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Berörd programvara | Java-biblioteket Log4j | själva PHP-körmiljön |
| Beteckning | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Bedömning | CVSS 10,0 (v3) | CVSS v4.0 9,2 |
| Verkan | kodkörning utan inloggning | kodkörning utan inloggning |
| BSI:s varningsnivå | 4 / röd | 3 / orange |
| Läge vid varning | enligt rapporter från den tiden komprometteringar kända | angreppsförsök rapporterade, enligt BSI inledningsvis inga bekräftade lyckade angrepp i bred skala |
| Synlighet | ofta djupt gömd i applikationer | synlig på servern, men patchnivån svår att utläsa på grund av backports |
| Uppföljande rapporter | flera ytterligare CVE:er på några veckor | meddelande om CVE-2026-115560 den 23.10. |

## Vad de båda sårbarheterna har gemensamt

**En grundbyggsten, otaliga applikationer.** Log4j fanns i Java-programvara av alla slag, PHP bär WordPress, Shopware, TYPO3 och otaliga egenutvecklingar. I båda fallen är det inte en produkt som är berörd utan ett fundament.

**Ingen inloggning behövs.** Båda sårbarheterna tillåter kodkörning på distans utan inloggning. Det gör dem attraktiva för automatiserade angrepp.

**Patchen är inte slutet.** Vid Log4Shell visade det sig att många system redan hade angripits före uppdateringen. Även vid PHP2Shell gäller: en patch tar inte bort skadlig programvara som smugits in. Enligt mediarapporter observerades ett första angreppsförsök redan den 17 oktober.

**Uppföljande rapporter.** Efter Log4Shell kom inom några veckor ytterligare CVE:er för Log4j. För PHP kom två dagar efter patcharna meddelandet om CVE-2026-115560. Varför fler rapporter är sannolika förklarar [Efter PHP2Shell: varför fler rapporter är sannolika](https://phpsos.de/sv/blog/weitere-php-meldungen/).

## Där jämförelsen haltar

Den största skillnaden ligger i synligheten. Log4j var ofta inbyggt som del av en applikation, ibland flera gånger i flera nivåer. Många driftansvariga visste helt enkelt inte att de använde det. PHP däremot är ingen hemlighet på en webbserver. Men vid PHP2Shell uppstår en annan oklarhet: distributioner och webbhotell installerar rättningar som backport, och det visade versionsnumret förblir detsamma. Man ser PHP, men inte genast om det är patchat.

En andra skillnad är utgångsläget för uppdateringen. Vid Log4Shell måste ofta tillverkare av fackapplikationer först leverera nya versioner. Vid PHP2Shell finns uppdateringar för alla grenar med support. Det blir svårt vid PHP 8.1 och äldre, för vilka PHP-projektet inte längre ger ut några officiella uppdateringar.

En tredje skillnad gäller angreppets plats. Vid Log4Shell kunde varje ställe vara farligt där en applikation loggade indata, alltså även interna system som bara indirekt fick data från internet. Vid PHP2Shell står webbservern i centrum, den som tar emot förfrågningar direkt. Det gör sökandet efter berörda system något mer överskådligt: först kommer alla publikt nåbara PHP-tjänster, därefter interna applikationer.

Slutligen skiljer sig läget vid utnyttjandet. För Log4Shell cirkulerade tidigt enkla angreppsverktyg, och komprometteringar var enligt rapporter från den tiden redan kända vid tidpunkten för varningen. Vid PHP2Shell rapporterar Cloudflare och Patchstack angreppsförsök, watchTowr har enligt egna uppgifter återskapat en av sårbarheterna, bekräftade lyckade angrepp i bred skala meddelade BSI inledningsvis inte. Det kan ändras. Men det är ett skäl till att jämförelsen inte duger som prognos.

> **Tips:**
> Använd erfarenheterna från Log4Shell i det egna huset: Vilka listor, förlopp och kontakter hjälpte då? Mycket av det går att återanvända direkt för PHP2Shell.

## Fem lärdomar från Log4Shell som hjälper i dag

1. **Inventering före patch:** Den som 2021 hade en aktuell lista över sina system var snabbare. Det gäller lika i dag. En anvisning erbjuder inlägget [Inventering av alla webbplatser och servrar](https://phpsos.de/sv/blog/inventar-websites-server/).
2. **Känn beroendena:** En stycklista över programvarubyggstenarna, kort SBOM, besvarar frågan ”Var använder vi det?” på minuter. För PHP-applikationer hjälper blicken i Composer, som [Kontrollera Composer-beroenden](https://phpsos.de/sv/ratgeber/composer-abhaengigkeiten-pruefen/) beskriver.
3. **Spara loggar:** Efter Log4Shell kunde många företag inte längre klargöra om de var berörda eftersom loggar saknades. Facktidningarna rekommenderar vid PHP2Shell att säkra loggar från och med den 20 oktober.
4. **Kontrollera i efterhand:** En patch besvarar inte vad som hände tidigare. En kontroll av spår hör till.
5. **Var förberedd på uppföljande rapporter:** Den första uppdateringen är sällan den sista. Den som en gång har ordnat uppdateringsvägen på ett rent sätt upprepar den snabbt.

## Hur hjälper PHP SOS konkret?

- **Inventering:** Vi tar reda på var PHP körs i ert företag, i vilken version och vilket driftläge.
- **Patch och omstart:** Vi installerar uppdateringar och styrker läget per system.
- **Spårkontroll:** Vi säkrar loggar och söker efter avvikelser sedan den 17 oktober.
- **Varaktig bevakning:** Vi håller era system under uppsikt så att uppföljande rapporter inte åter börjar från noll.

Hur den löpande övervakningen ser ut beskriver [Säkerhetsövervakning för webbservrar](https://phpsos.de/sv/leistungen/security-monitoring/).

## Slutsats

PHP2Shell är inte Log4Shell, men det rimmar. Båda träffar ett fundament, båda kräver mer än en patch. Företag som har tagit med sig inventering, logglagring och uppdateringsvägar från 2021 har en fördel i dag. För alla andra är det nu dags att ta igen det.


## Vanliga frågor

**Är PHP2Shell lika illa som Log4Shell?**  
Båda är kritiska sårbarheter i mycket utbredd programvara där angripare kan köra kod utan inloggning. BSI (den tyska federala myndigheten för informationssäkerhet) klassade Log4Shell 2021 som röd, PHP2Shell som orange. En viktig skillnad: vid Log4Shell var enligt rapporter från den tiden komprometteringar redan kända vid varningen, vid PHP2Shell enligt BSI inledningsvis inga bekräftade lyckade angrepp i bred skala.

**Vad var Log4Shell?**  
Log4Shell var en kritisk sårbarhet i Java-biblioteket Log4j som blev känd i december 2021 och förs under CVE-2021-44228. Log4j fanns som byggsten i mycket många applikationer, ofta utan att de driftansvariga visste det.

**Kommer fler sårbarheter efter PHP2Shell?**  
Det är möjligt. Efter Log4Shell följde inom några veckor ytterligare CVE:er för Log4j. För PHP fanns den 23 oktober redan ett meddelande om CVE-2026-115560, som bara slår till vid ovanlig konfiguration. Räkna med uppföljande rapporter.

**Vad är en SBOM?**  
En Software Bill of Materials är en stycklista över alla programvarubyggstenar som en applikation består av. Med den går det att snabbt fastställa var den berörda byggstenen används när en ny sårbarhet dyker upp.

## Källor

- [BSI: den tyska federala myndigheten för informationssäkerhet](https://www.bsi.bund.de/)
- [php.net: säkerhetsmeddelanden](https://www.php.net/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)