Kort sagt: Till de belagda fakta om PHP2Shell hör de två CVE-numren, bedömningen CVSS v4.0 9,2, de åtgärdade PHP-versionerna och php.nets tillfälliga åtgärder. Belagd är också BSI:s (den tyska federala myndigheten för informationssäkerhet) varningsnivå orange. Inte belagda är en bedömning med CVSS 10, bekräftade lyckade angrepp i bred skala och en lista med kännetecken. Den som håller isär de här tre nivåerna fattar bättre beslut.
Varför en faktakoll om PHP2Shell behövs
Knappt någon säkerhetslucka under de senaste åren har skapat så många rubriker så snabbt. Redan innan PHP-teamet publicerade uppdateringarna den 21 oktober 2026 cirkulerade enligt rapporter foruminlägg, skärmdumpar och påstådda detaljer. Därefter följde myndighetsvarningar, tillverkarbloggar, räkningar av exponerade servrar och en flod av tips.
För driftansvariga betyder det: inte varje siffra och inte varje råd håller samma kvalitet. En del kommer från primärkällor, en del från seriös rapportering, en del från spekulation. Den här artikeln sorterar vad ni kan använda som säkert underlag för era beslut. Själva sårbarhetens grunder förklaras på sidan Vad är PHP2Shell?.
Vilka källor som väger hur tungt
En enkel rangordning hjälper vid läsningen av varje rapport:
- php.net: PHP-projektet är primärkälla för CVE-nummer, bedömningar, berörda driftlägen, åtgärdade versioner och tillfälliga åtgärder. Hur projektet i grunden hanterar säkerhetsmeddelanden beskriver vårt inlägg om PHP:s säkerhetsprocess.
- Myndigheter: BSI ger lägesbedömningen för Tyskland och handlingsrekommendationer, CERT-EU (EU-institutionernas CERT) och CERT-Bund (den tyska federala förvaltningens CERT) kompletterar.
- Distributioner och leverantörer: Debian, Ubuntu, Red Hat, webbhotell och plattformstjänster uttalar sig bindande bara om sina egna paket och tjänster.
- Säkerhetsföretag: Cloudflare, Unit 42, CybelAngel och andra rapporterar utifrån egna mätningar. Värdefullt, men alltid med egen metod.
- Medier och sociala nätverk: Bra för tempot, svaga på detaljer. Uppgifter därifrån behöver bekräftas längre upp i listan.
Belagt, rapporterat, obelagt: översikten
Tabellen nedan placerar de vanligaste påståendena. ”Belagt” betyder: primärkälla eller myndighet. ”Rapporterat” betyder: från medier eller tillverkaruppgifter, inte oberoende bekräftat.
| Påstående | Bedömning | Underlag |
|---|---|---|
| Två sårbarheter, CVE-2026-109618 och CVE-2026-109619 | belagt | php.net |
| Bedömning CVSS v4.0 9,2, kritisk | belagt | php.net |
| Bedömning CVSS 10 | håller inte | enligt rapporter från ett foruminlägg före anmälan |
| Åtgärdat i 8.5.12, 8.4.27, 8.3.36, 8.2.35 | belagt | php.net |
| mod_php med högst risk, exploit visad före applikationskod | belagt | php.net |
| Nästan alla versioner ända tillbaka till PHP 5.4 berörda | rapporterat | facktidningar |
| Första angreppsförsök den 17.10. | rapporterat | mediarapporter som hänvisar till Amazon |
| Mer än 22,6 miljoner exponerade instanser | rapporterat | Unit 42, enligt TechTarget |
| Lyckade angrepp i bred skala | obelagt | enligt BSI inledningsvis inte kända |
| Bekräftade Indicators of Compromise | finns inte | ingen publicering |
| Tillfälliga åtgärder skyddar fullständigt | felaktigt | php.net kallar dem uttryckligen ofullständiga |
Det är anmärkningsvärt hur tidigt siffror får eget liv. Bedömningen 10,0 från foruminlägget dök upp i inlägg ännu flera dagar senare, fast PHP-teamet för länge sedan hade publicerat 9,2.
Var osäkerheten egentligen ligger
Den största öppna frågan är inte teknisk utan tidsmässig: vad hände mellan det första rapporterade angreppsförsöket och patchen på enskilda servrar? Det finns inget generellt svar på det. Cloudflare och Patchstack rapporterade angreppsförsök, watchTowr har enligt egna uppgifter återskapat CVE-2026-109618. Huntress såg däremot vid tidpunkten för sin rapport inga angrepp i partnermiljöer.
De här uppgifterna motsäger inte varandra. De beskriver olika utsnitt: en stor proxytjänst, ett säkerhetsföretag för tillägg, ett forskarteam och ett företag med egen kundbas. Någon helhetsbild ger de inte.
På samma sätt med frågan vilka versioner som berörs. För 8.2 till 8.5 är läget klart. För äldre grenar finns minimala backports i källkoden för 7.4, 8.0 och 8.1, men inga officiella releaser. Det som ligger före det är enligt facktidningarna nästan genomgående berört. För er planering gör det knappast någon skillnad: en server med PHP 8.1 eller äldre utan bekräftad backport ska behandlas som utsatt.
Avsaknad av belägg för angrepp är inget belägg för säkerhet. Eftersom det inte finns bekräftade kännetecken kan ett angrepp mot en enskild server bara bedömas genom en kontroll av beteendet, inte med hjälp av en lista.
Vad ni kan dra för slutsatser för era servrar
Av de belagda fakta följer några få, tydliga steg. Av de obelagda följer framför allt försiktighet.
- Kontrollera patchnivån: åtgärdad version eller en backport som leverantören bekräftat. Det angivna versionsnumret räcker inte i sig.
- Starta om alla PHP-processer: Nya filer får effekt först när inga gamla processer längre körs.
- Säkra loggar från och med den 20.10.: Facktidningarna rekommenderar det så att en senare kontroll förblir möjlig.
- Leta efter spår: nya PHP-filer i uppladdningsmappar, okända cronjobb, webbserverprocesser med skal. Sidan Har vi redan komprometterats? går igenom kontrollen.
- Kontrollera råd mot källan: Genomför tips från forum och sociala nätverk bara om de går att spåra till php.net eller en myndighet. Vilka rekommendationer som just nu gör skada samlar inlägget Farliga felaktiga tips om PHP2Shell.
För den interna kommunikationen hjälper samma uppdelning. Den som lägger fram ”belagt”, ”rapporterat” och ”öppet” var för sig för ledningen undviker både alarmism och falsk avblåsning.
Hur hjälper PHP SOS konkret?
- Läget för era system: Vi överför de belagda fakta till era servrar och skiljer i dokumentationen på vad som har mätts, vad som har rapporterats och vad som är öppet.
- Patch och bevis: Vi kontrollerar paketstatus och omstart av varje PHP-tjänst och dokumenterar det skriftligt.
- Spårkontroll: Vi säkrar loggar från och med den 20 oktober och söker efter beteendeavvikelser tills incidenten är avslutad och dokumenterad.
- Löpande bedömning: Nya rapporter bedömer vi åt er innan de blir åtgärder.
Förloppet beskrivs i PHP2Shell-akuthjälpen.
Slutsats
PHP2Shell är allvarligt, och det är väl belagt. Just därför lönar sig den nyktra blicken: primärkällorna räcker för alla viktiga beslut. Det som cirkulerar utöver dem är ofta snabbare än korrekt. Patcha, starta om, säkra loggar och leta efter spår är fortfarande svaret, oavsett vilken siffra som just går runt.
Vanliga frågor
Är PHP2Shell bedömd med CVSS 10?
Nej. Siffran 10 kommer enligt rapporter från ett foruminlägg som cirkulerade före den officiella anmälan. PHP-teamet bedömer båda sårbarheterna med CVSS v4.0 9,2. Det är ändå kategorin kritisk.
Finns det en lista med kännetecken för PHP2Shell-angrepp?
Hittills inte. Det finns inga publicerade, bekräftade Indicators of Compromise. Den som vill kontrollera om en server har berörts måste leta efter beteendeavvikelser, till exempel webbserverprocesser som startar ett skal eller nya PHP-filer i uppladdningsmappar.
Vilken källa är mest tillförlitlig för PHP2Shell?
För de tekniska fakta är det meddelandena på php.net, för lägesbedömningen i Tyskland BSI. Mediarapporter och tillverkarbloggar kompletterar bilden, men bör ses som rapporter och läsas mot primärkällan.
Berörs verkligen alla PHP-versioner från PHP 5?
Läget är belagt för grenarna 8.2 till 8.5, för vilka det finns uppdateringar. Enligt facktidningarna berörs nästan alla versioner ända tillbaka till PHP 5.4; CERT-EU ansåg enligt rapporter att versioner från PHP 5 var möjliga. För äldre versioner finns inga officiella uppdateringar, så ni bör under alla omständigheter behandla dem som utsatta.