Aktuellt läge: PHP2Shell. Två kritiska PHP-sårbarheter (CVSS 9,2) tillåter skadlig kod utan inloggning. Patchar sedan den 21 oktober 2026.Vad som bör göras nu →

Berörs ni av PHP2Shell? Få det klarlagt nu

Vet ni inte om era servrar, webbplatser eller webbhotellspaket berörs av PHP2Shell? Vi klarlägger det på distans, belägger det på servern och talar om vad som bör göras.

Aktualitet 5 min läsningOmedelbar hjälp

Kort sagt: Om ni berörs av PHP2Shell beror på tre saker: PHP-versionen, driftläget och om och hur det har patchats. Är ni osäkra, hör av er nu. Berörs ni? Ring oss. Vi hjälper er. Vi klarlägger det på distans på själva servern, inte efter magkänsla, och stänger sårbarheten om den är öppen.

Agera direkt

Radera ingenting och installera inte om något nu. Även om ni bara vill klarlägga om ni berörs: Kan servern redan ha angripits behöver vi filer och loggar oförändrade. Anmäl nödläge, så går vi igenom kontrollen tillsammans.

Berörs ni? De här fallen hör hemma på kontrollistan

PHP2Shell är två kritiska sårbarheter i själva PHP (CVE-2026-109618 och CVE-2026-109619, båda med högsta betyg 9,2 enligt CVSS v4.0). De tillåter skadlig kod på distans utan inloggning. Alla driftlägen kan beröras: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Kontrollera vart och ett av dessa system:

  • egna servrar, vServer och root-servrar med PHP
  • webbhotellspaket och managed servrar, även om ni inte har åtkomst till konfigurationen
  • containrar och plattformstjänster som levererar en PHP-image
  • testsystem, staging-miljöer och bortglömda äldre system som är nåbara från internet
  • NAS, appliances eller leverantörers programvara som använder PHP internt

Det är just bortglömda system som utgör risken. Enligt Unit 42 finns det över 22,6 miljoner exponerade, potentiellt sårbara instanser, och BSI räknade med snabb utnyttjande i stor skala.

Det här gör ni direkt

  1. Upprätta en inventering. Skriv ned alla servrar, domäner och hostingavtal där PHP körs och vem som ansvarar för dem.
  2. Ta reda på PHP-versionen för varje system. På servrar med php -v. Tänk på att kommandoraden kan använda en annan version än webbservern.
  3. Klarlägg driftläget. Körs PHP som PHP-FPM, som mod_php eller via LiteSpeed? Vid mod_php bedömer PHP-teamet risken som högst.
  4. Fråga webbhotell och leverantörer. Skriftligen: Vilken version körs, har rättningen installerats, har alla processer startats om?
  5. Spara loggarna. Fackpressen rekommenderar att loggar sparas från och med den 20 oktober 2026.
  6. Dröj inte länge. Är ett system öppet och patchen inte möjlig direkt, rekommenderar BSI att webbservern tillfälligt tas offline.

Hur hjälper PHP SOS konkret?

Vi klarlägger om ni berörs på distans och med belägg.

  1. Kartlägga läget: Vi låter er beskriva er inventering och ordnar systemen efter nåbarhet och risk.
  2. Säkra och stänga: Där det är öppet säkrar vi först läget och stänger sedan sårbarheten med uppdatering och omstart. Där det inte går direkt sätter vi in tillfälliga åtgärder, som inte är ett fullständigt skydd.
  3. Granska och rensa: Vi kontrollerar om sårbarheten utnyttjades före patchen och rensar vid behov. Om en server berörs och kanske redan har angripits skiljer vi tydligt åt.
  4. Härda och rapportera: Ni får en lista per system: version, driftläge, patchbevis, öppna punkter.

Så belägger ni att ni berörs

Ett versionsnummer ensamt räcker inte, eftersom leverantörer backportar rättningar. Ubuntu 24.04 visar till exempel enligt rapporter fortfarande 8.3.6 även efter uppdateringen. Tre vägar är pålitliga:

Väg Vad den visar Begränsning
Jämföra versionen med rättningsversionerna 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller högre är åtgärdad gäller bara originalversioner, inte backports
Test av memory_hard_limit_percent bool(false) betyder: direktivet okänt, alltså berörd körs för varje version och driftläge för sig
Söka igenom paketets changelog efter CVE-nummer belägger backports hos distributioner källan är leverantörens säkerhetsarkiv

Testet ser ut så här:

php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

Hur ni kontrollerar version och patchnivå på rätt sätt står på sidan Kontrollera PHP-version och patchnivå rätt. En översikt över grenarna ger Vilka PHP-versioner berörs?. Varför visningen kan se gammal ut trots patch förklarar inlägget php -v visar ett gammalt nummer.

Berörda och inte längre patchbara: PHP 8.1 och äldre

För PHP 8.1 och äldre finns inga officiella uppdateringar från PHP-projektet längre, bara minimala backports av källkoden för 7.4, 8.0 och 8.1. Den som använder en sådan version har oftast två vägar: en leverantör med belagd backport eller migrering till en underhållen version. Kommersiella erbjudanden om långtidssupport finns, men om och när de täcker PHP2Shell måste leverantören bekräfta skriftligen. Vi hjälper till med bedömningen under PHP 8.1 och äldre: vad som gäller nu och med genomförandet i PHP-patchtjänsten.

Det här bör ni skicka till oss

  • Lista över era servrar, domäner och webbhotell
  • PHP-version per system, i den mån den är känd
  • Driftläge och webbserver, i den mån de är kända
  • Uppgift om huruvida Cloudflare eller annat skydd är förkopplat och om ursprungsservern är direkt nåbar
  • Svar från ert webbhotell, om ni redan har frågat
  • Kontaktperson för godkännanden och omstarter

Varför PHP SOS

Vi arbetar Made in Germany och är sedan över 25 år, tillsammans med vårt partnernätverk av cyberproffs, specialiserade på IT-säkerhet. Ni får en kontaktperson som går igenom er inventering och belägger varje uttalande i stället för att bara läsa av versionsnummer. Vi arbetar på distans, utan resor, och dokumenterar vad vi har kontrollerat. Ett uttalande som ”säker” ger vi bara så långt det går att belägga. För större miljöer kan PHP2Shell-direkthjälpen komma i fråga.

Berörs ni? Ring oss. Vi hjälper er.

Om ni inte vet om ni berörs är det skäl nog att höra av er nu. Ring eller skriv via WhatsApp. Vi tar över från första meddelandet och klarlägger det tillsammans med er på servern. Anmäl nödläge nu.

Vanliga frågor

Berörs jag av PHP2Shell om jag bara använder WordPress eller en webbutik?

Möjligen ja. Sårbarheterna finns i PHP, inte i CMS:et. Det avgörande är vilken PHP-version och vilket driftläge som faktiskt levererar hos er; en WordPress-uppdatering ändrar inget av det.

Räcker versionsnumret för att veta om jag är patchad?

Inte alltid. Distributioner och webbhotell levererar ibland rättningar som backport, och då förblir numret detsamma. Det som säger något är paketets changelog med CVE-numren eller leverantörens skriftliga bekräftelse.

Finns det ett snabbtest för att se om min PHP-version innehåller rättningen?

Enligt PHP-manualen berörs en version som inte känner till direktivet memory_hard_limit_percent. Testet måste köras för varje PHP-version och driftläge för sig, eftersom kommandoraden kan använda en annan version än webbservern.

Berörs även äldre PHP-versioner som 7.4 eller 8.0?

Enligt fackpressen berörs nästan alla versioner ända tillbaka till PHP 5.4. För 8.1 och äldre finns inga officiella uppdateringar från PHP-projektet längre, bara minimala backports av källkoden. Om en leverantör har installerat dem måste leverantören bekräfta.

Skyddar Cloudflare mig om jag berörs?

Delvis. Cloudflare har infört skyddsregler men varnar själva för att de inte ersätter uppdateringen. Om er ursprungsserver är direkt nåbar kringgås skyddet.

Källor

Direktkontakt

Varje timme räknas. Skriv till oss nu.

Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.

Direkthjälp