# Vad är PHP2Shell? Sårbarheten enkelt förklarad

> PHP2Shell enkelt förklarat: vad som ligger bakom de två kritiska PHP-sårbarheterna, vilka servrar som berörs och vilka steg ni bör ta nu.

Källa: https://phpsos.de/sv/php2shell/was-ist-php2shell/  
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 är namnet på två kritiska säkerhetsluckor i själva PHP, CVE-2026-109618 och CVE-2026-109619. Via dem kan angripare köra skadlig kod på sårbara webbservrar utan inloggning. Hjälp ger bara uppdateringen till en åtgärdad PHP-version med efterföljande omstart av alla PHP-processer.

## Vad är PHP2Shell?

PHP är det programmeringsspråk som en stor del av alla webbplatser körs på: företagssidor med WordPress eller TYPO3, nätbutiker med Shopware eller WooCommerce, interna portaler och egenutvecklingar. Den 21 oktober 2026 publicerade PHP-projektet säkerhetsuppdateringar för två sårbarheter som har blivit kända under namnet PHP2Shell.

Båda sårbarheterna är bedömda med CVSS v4.0 9,2, alltså som kritiska. Följden är i båda fallen densamma: körning av skadlig kod på distans, utan att angriparen behöver logga in. Experter talar om ”unauthenticated Remote Code Execution”. Den som kan köra kod på servern kan i värsta fall läsa data, bygga in bakdörrar eller använda servern för ytterligare angrepp.

Viktigt för förståelsen: Sårbarheten finns inte i ett visst CMS eller plugin utan i PHP. En uppdatering av WordPress, Shopware eller TYPO3 stänger den därför inte.

## Varför är sårbarheten så allvarlig?

Tre punkter gör PHP2Shell särskilt känsligt ur säkerhetsmyndigheternas synvinkel:

- **Bredd:** Berörda är de gängse driftlägena för PHP, nämligen PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Palo Alto Networks (Unit 42) räknade mer än 22,6 miljoner exponerade, potentiellt sårbara instanser.
- **Ingen inloggning behövs:** Angriparen behöver varken lösenord eller användarkonto.
- **Tidig tidpunkt:** Vid Apache med mod_php visades enligt PHP-teamet en exploit innan någon applikationskod ens körs. Skyddsfunktioner inne i webbplatsen verkar då inte.

BSI (Tysklands federala myndighet för informationssäkerhet) har utlyst varningsnivå 3 (orange). Det rekommenderar omedelbar uppdatering och, om det inte är möjligt genast, att tillfälligt ta de berörda webbservrarna från nätet.

## Vilka servrar berörs av PHP2Shell?

Sårbarheterna är åtgärdade i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Äldre versioner av dessa grenar är berörda. För PHP 8.1 och äldre finns inga officiella uppdateringar längre; enligt facktidningarna berörs nästan alla versioner ända tillbaka till PHP 5.4. Den fullständiga översikten finns på sidan [Vilka PHP-versioner berörs?](https://phpsos.de/sv/php2shell/betroffene-php-versionen/).

En särskild omständighet: Linux-distributioner och webbhotell levererar rättningarna ibland som backport. Då visar till exempel Plesk fortfarande 8.2.34 fast felet är åtgärdat. Avgörande är paketstatusen och leverantörens bekräftelse. Hur ni kontrollerar det förklarar vi under [Kontrollera PHP-version och patchstatus rätt](https://phpsos.de/sv/php2shell/php-version-pruefen/).

## Vad är belagt och vad är öppet?

**Belagda** är de två CVE-numren, de åtgärdade versionerna och de övergångsåtgärder som php.net har publicerat. Den 23 oktober tillkom en anvisning om ytterligare en sårbarhet, CVE-2026-115560, som bara slår till vid en ovanlig konfiguration.

**Sannolikt** är att angripare fortsätter att aktivt söka efter opatchade servrar. Enligt mediarapporter observerades ett första angreppsförsök redan den 17 oktober, alltså före publiceringen av patcharna. Cloudflare rapporterade angreppsförsök och har rullat ut skyddsregler, men påpekar att regler baserade enbart på förfrågningsdata inte räcker.

**Öppet** är hur många servrar som redan har angripits framgångsrikt. Bekräftade lyckade angrepp i bredd var enligt BSI till en början inte kända. Det finns inga publicerade, bekräftade Indicators of Compromise. Om en server var berörd går därför bara att bedöma genom beteendeanalys. Det tidsmässiga förloppet sammanfattar [kronologin 17–25 oktober](https://phpsos.de/sv/ratgeber/php2shell-chronologie/).

## Vad företag bör göra nu

1. **Klarlägga vem som ansvarar:** egen server, managed server eller webbhotell.
2. **Uppdatera PHP** till en åtgärdad version eller en bekräftad backport.
3. **Starta om alla PHP-processer.** Nya filer ensamma räcker inte så länge gamla processer körs i minnet.
4. **Säkra loggar,** och det från och med den 20 oktober. Facktidningarna rekommenderar att spara dessa data.
5. **Kontrollera efter spår.** En patch tar inte bort skadlig programvara som redan förts in och bevisar inte att inget har hänt tidigare. Anvisningar ger sidan [Är jag redan komprometterad?](https://phpsos.de/sv/php2shell/bin-ich-gehackt-anzeichen/).

> **Viktigt:**
> En uppdatering stänger dörren men städar inte upp. Om er server var nåbar mellan den 17 oktober och patchen är en kontroll av spår ett måste, inte ett extra.

## Hur hjälper PHP SOS konkret?

Med [PHP2Shell-akuthjälpen](https://phpsos.de/sv/leistungen/php2shell-soforthilfe/) tar vi över de steg som många företag internt inte kan täcka med kort varsel:

- **Inventering:** Vi fastställer PHP-version, driftläge och paketstatus för varje berörd server.
- **Patch eller övergång:** Vi installerar uppdateringen eller, där det ännu inte går, sätter in övergångsåtgärderna från php.net och klarlägger frågan om servern tillfälligt måste tas från nätet.
- **Omstart och intyg:** Vi startar om alla PHP-processer och dokumenterar läget före och efter.
- **Spårkontroll:** Vi säkrar loggar från och med den 20 oktober och kontrollerar efter avvikelser tills incidenten är avslutad och dokumenterad.


## Vanliga frågor

**Är PHP2Shell en sårbarhet i WordPress?**  
Nej. Sårbarheterna finns i PHP, alltså i det programmeringsspråk som WordPress, Shopware, TYPO3 och många andra system körs på. En uppdatering av CMS:et stänger dem därför inte. Avgörande är PHP-versionen på servern.

**Måste jag som kund hos ett webbhotell göra något själv?**  
Vid delat webbhotell installerar i regel webbhotellet PHP-uppdateringen. Ni bör ändå låta er skriftligen bekräfta att den PHP-version ni använder har patchats och startats om. Om något hände före patchen besvarar uppdateringen inte.

**Varifrån kommer namnet PHP2Shell?**  
Namnet beskriver följden: Via PHP kan en angripare i värsta fall få en kommandorad, alltså ett skal, på servern. Officiella beteckningar är CVE-numren CVE-2026-109618 och CVE-2026-109619.

**Har min webbplats redan angripits om den togs offline?**  
Inte nödvändigtvis. Några leverantörer har försiktighetsvis tagit webbplatser från nätet, som BSI rekommenderar när en uppdatering inte är möjlig genast. Det är en skyddsåtgärd och inget belägg för ett angrepp.

## Källor

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