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 →

PHP2Shell-akuthjälp: hjälp med PHP-sårbarheten

Vi stänger PHP2Shell på era webbservrar på distans: inventering, patch eller övergångsåtgärd, omstart av alla workers och skriftligt intyg.

Aktualitet 4 min läsningTjänster

Kort sagt: PHP2Shell är två kritiska sårbarheter i själva PHP som angripare kan använda för att köra skadlig kod utan inloggning. Behöver ni snabb hjälp med den här PHP-sårbarheten tar vi på distans hand om inventeringen, patchningen eller en övergångsåtgärd, omstarten av alla PHP-processer och en första spårsökning. Till slut får ni ett skriftligt intyg om läget.

Hjälp med PHP-sårbarheten: varför ni måste agera nu

Den 21 oktober 2026 klockan 16 tysk tid publicerade PHP-projektet patchar för CVE-2026-109618 och CVE-2026-109619. Båda sårbarheterna är bedömda med CVSS v4.0 9,2 och tillåter körning av skadlig kod på distans utan att någon behöver logga in. Berörda är de vanliga driftlägena: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed.

BSI (Tysklands federala myndighet för informationssäkerhet) har utlyst varningsnivå 3 (orange). Det rekommenderar omedelbar uppdatering och, om det inte går genast, att tillfälligt ta webbservrarna från nätet. Palo Alto Networks (Unit 42) räknade mer än 22,6 miljoner exponerade, potentiellt sårbara instanser. Bekräftade lyckade angrepp i bredd var enligt BSI till en början inte kända, men Cloudflare rapporterade redan angreppsförsök.

För ledning och ägare betyder det: Varje offentligt nåbar PHP-server är en kandidat tills motsatsen är belagd. En begriplig förklaring av sårbarheten finns under Vad är PHP2Shell?.

Vem är PHP2Shell-akuthjälpen till för?

För företag, byråer och offentliga organ som driver PHP-applikationer och som inte själva kan eller vill arbeta igenom läget på det djup som behövs. Det gäller egna root-servrar och vServers lika väl som servrar med Plesk eller cPanel, containermiljöer och managed servers där ansvaret är oklart.

Även den som har ett webbhotell behöver ofta stöd. Många leverantörer levererar backports; då visar till exempel Plesk fortfarande 8.2.34 fast paketstatusen är patchad. Omvänt kan ett nytt versionsnummer visas medan gamla PHP-processer fortfarande körs i minnet. Vilka versioner som räknas som åtgärdade står på Vilka PHP-versioner berörs?.

Hur hjälper PHP SOS konkret?

  1. Inventering: Vi kartlägger alla PHP-installationer, driftlägen och versioner på era servrar, inklusive paketstatus och körande processer. Resultatet är en lista över vilka system som är berörda, åtgärdade eller oklara.
  2. Patch eller övergångsåtgärd: Där det går installerar vi de åtgärdade versionerna (8.5.12, 8.4.27, 8.3.36, 8.2.35) eller paketen i er distribution. Går det inte genast sätter vi in övergångsåtgärderna enligt php.net och säger öppet att de inte ger fullständigt skydd.
  3. Omstart och kontroll: Vi startar om alla PHP-workers och processer och kontrollerar därefter att ingen gammal process längre körs. Nya filer ensamma stänger inte sårbarheten.
  4. Första spårsökning: Vi säkrar serverloggarna från och med den 20 oktober och söker efter avvikelser som nya PHP-filer, okända cronjobb eller ovanliga processer. Eftersom det inte finns några publicerade, bekräftade Indicators of Compromise bygger den här kontrollen på beteendeanalys.
  5. Intyg och nästa steg: Ni får en skriftlig rapport. Vid misstanke om komprometterande rekommenderar vi lämpliga fortsatta steg, till exempel borttagning av skadlig kod eller en forensisk undersökning.
Viktigt

En patch tar inte bort skadlig programvara som redan förts in och bevisar inte att inget har hänt tidigare. Därför hör alltid en blick på perioden sedan den 17 oktober 2026 till akuthjälpen.

Vad ni får från oss

  • en översikt över alla kontrollerade servrar med PHP-version, paketstatus, driftläge och patchstatus
  • dokumentationen av de installerade uppdateringarna eller de införda övergångsåtgärderna
  • intyget att alla PHP-processer har startats om
  • en bedömning av spårsökningen, uppdelad i belagt, sannolikt och okänt
  • en lista över öppna punkter, till exempel system med PHP 8.1 eller äldre

Den här rapporten kan ni lämna vidare till ledning, dataskyddsombud eller försäkringsgivare. Den gör ingen rättslig bedömning.

Vad vi behöver från er

  • Åtkomst: SSH- eller panelåtkomst med tillräckliga rättigheter, alternativt ett godkännande för ert webbhotell att lämna oss besked
  • Kontaktperson: en person som får fatta beslut, till exempel om en kort tid offline eller en omstart
  • Överblick: vilka webbplatser, butiker och applikationer som körs på vilka servrar
  • Underhållsfönster: era önskemål om när omstarter får ske
  • Säkerhetskopior: besked om var aktuella säkerhetskopior finns

För administratörer som vill kontrollera själva i förväg räcker ofta redan den här ofarliga blicken på läget:

php -v
# Debian/Ubuntu: installerade PHP-paket med version
dpkg -l | grep -i php
# körande PHP-processer och deras starttid
ps -eo pid,lstart,cmd | grep -i php

Vad vi inte lovar

Vi lovar ingen absolut säkerhet och inget påstående om att er server aldrig har angripits om beläggen inte räcker till. Vi arbetar med incidenten tills den är avslutad och dokumenterad. Om en anmälningsskyldighet enligt GDPR föreligger eller om er försäkring ska informeras klarar ni ut med dataskyddsombud, jurist eller försäkringsgivare. Vi levererar de tekniska fakta för det.

Om ni bara behöver uppdateringen med intyg passar vår PHP-patchtjänst. Finns det redan tecken på ett angrepp är akuthjälp vid hackad webbplats rätt ingång.

Vanliga frågor

Räcker det om mitt webbhotell har uppdaterat PHP?

Det kan räcka om webbhotellet skriftligen bekräftar paketstatusen och alla PHP-processer har startats om. Det visade versionsnumret ensamt är inget belägg, eftersom distributioner levererar backports. Om servern redan hade angripits före patchen besvarar en patch ändå inte.

Måste min webbplats gå offline för akuthjälpen?

Inte nödvändigtvis. BSI rekommenderar att tillfälligt ta webbservrar från nätet om uppdateringen inte är möjlig genast. Om det är nödvändigt hos er avgör vi tillsammans efter inventeringen.

Skyddar en uppdatering av WordPress eller Shopware mot PHP2Shell?

Nej. PHP2Shell finns i PHP självt, inte i CMS:et. En CMS-uppdatering är fortfarande meningsfull men stänger inte den här sårbarheten.

Vad gäller för PHP 8.1 eller äldre?

För dessa versioner finns inga officiella uppdateringar längre från PHP-projektet, bara minimala backports i källkoden för 7.4, 8.0 och 8.1. Vi skyddar servern under övergången och planerar tillsammans med er omstigningen till en version med support.

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