Kort sagt: Den som vill ha PHP-sårbarheten PHP2Shell stängd redan i dag behöver fyra saker: rätt uppdatering, omstart av alla PHP-processer, granskning efter redan införd skadlig kod och ett bevis. Berörs ni? Ring oss. Vi hjälper er. Vi tar hand om det på distans, från första meddelandet.
Radera ingenting och installera inte om något nu. Även vid patchning gäller: Först säkra, sedan ändra. Om något redan har tagit sig in behöver vi läget för filer och loggar. Anmäl nödläge, så klarlägger vi ordningsföljden med er.
Varför sårbarheten inte kan vänta
De båda sårbarheterna CVE-2026-109618 och CVE-2026-109619 finns i själva PHP och tillåter skadlig kod på distans utan inloggning. BSI (den tyska federala myndigheten för informationssäkerhet) har utlyst varningsnivå 3 (orange) och rekommenderar omedelbar uppdatering. Om det inte går direkt ska webbservrar tillfälligt tas offline. Enligt medierapporter observerades de första angreppsförsöken redan innan patcharna publicerades den 21 oktober 2026. Cloudflare har observerat försök och infört skyddsregler, men varnar för att regler baserade enbart på förfrågningsdata inte räcker.
Viktigt för driftansvariga: En CMS-uppdatering stänger inte PHP-sårbarheten. Enligt rapporter planerar inte heller WordPress.org någon uppdatering mot den, eftersom sårbarheten finns i tolken. Den stängs bara på PHP-nivå, alltså hos det som er server faktiskt kör.
Det här gör ni direkt
- Känn till målversionen. Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. PHP 8.2 når slutet på supporten den 31 december 2026, räkna med det i planeringen.
- Kartlägg alla system. Även testservrar, containerimages och äldre system som är nåbara från internet.
- Klarlägg ansvaret. Vid webbhotellspaket och managed servrar installerar leverantören. Fråga skriftligen efter version och omstart.
- Spara loggarna. Från och med den 20 oktober 2026, enligt fackpressen.
- Stäm av tidsfönstret. En omstart avbryter pågående förfrågningar en kort stund. Bestäm en tidpunkt då någon kan fatta beslut.
- Vänta inte om det är öppet. Kan det inte patchas direkt, undersök tillsammans med oss avskärmning eller de tillfälliga åtgärderna.
Hur hjälper PHP SOS konkret?
- Kartlägga läget: Vi inventerar system, PHP-versioner, driftlägen, webbhotell och nåbarhet och fastställer ordningen: först de mest exponerade systemen.
- Säkra och stänga: Vi säkrar det aktuella läget, installerar uppdateringen eller för hostingen till den bevisligen patchade nivån och startar om alla processer. Vid containrar bygger vi om imagen och rullar ut den.
- Granska och rensa: Eftersom en patch inte tar bort skadlig kod granskar vi om det finns tecken på ett tidigare intrång och rensar vid behov.
- Härda och rapportera: Ni får ett skriftligt bevis per system och rekommendationer så att nästa uppdatering går snabbare. Tjänsten beskrivs i PHP-patchtjänsten.
Uppdatering, omstart, bevis: det här är det viktiga
Det vanligaste felet är en uppdatering utan omstart. Så länge gamla processer ligger kvar i minnet förblir den sårbara koden aktiv, även om filerna är nya. Anvisningen finns på sidan Starta om PHP-FPM och alla workers. Det andra felet är att tro på det som visas: Distributioner och webbhotell levererar ofta backports, och då förblir versionsnumret detsamma. Pålitligt är paketets changelog med CVE-numren, i Debian-familjen med apt-get changelog <paket>.
Dessutom gäller enligt PHP-manualen sedan säkerhetsutgåvorna det nya direktivet memory_hard_limit_percent. Känner en PHP-version inte till det är den berörd. Testet är kort:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Det måste köras per version och driftläge, eftersom kommandoraden kan använda en annan PHP-version än webbservern. Till sist dokumenterar vi resultatet så att ni kan visa det för ert webbhotell, försäkringsbolag eller uppdragsgivare.
Om uppdateringen inte går direkt
Det finns skäl till att en uppdatering inte är möjlig i dag: ett gammalt program som inte körs på nyare PHP-versioner, ett webbhotell utan godkännande, en containerimage i en fast pipeline. För dessa fall anger php.net tillfälliga åtgärder som uttryckligen inte är ett fullständigt skydd: sätta memory_limit=-1 så att program inte kan skriva över det, begränsa post_max_size, session.upload_progress.enabled=0 och på PHP 8.5 fatal_error_backtraces=0, i varje fall med omstart. Dessutom finns skyddsregler i kanten, som inte ersätter en uppdatering. Ett tips som cirkulerar om att blockera alla förfrågningar med PHPSESSID avvisas uttryckligen av fackskribenter.
Vilka åtgärder som passar ert system och vad de kan förstöra går vi igenom i förväg. Mer finns på sidan Akutåtgärder när ni ännu inte kan patcha och under ämnet WAF och virtuell patchning. För PHP 8.1 och äldre gäller ett eget läge, som beskrivs under PHP 8.1 och äldre: vad som gäller nu.
Det här bör ni skicka till oss
- Lista över servrarna och webbhotellen, i den mån den finns
- Utdata från
php -vper system och uppgift om driftläget - Uppgift om huruvida containrar, Plesk, cPanel eller ett managed-erbjudande används
- önskat tidsfönster och kontaktperson för omstarter
- Uppgifter om avvikelser sedan den 17 oktober 2026
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 har en kontaktperson som följer uppdateringen, kontrollerar omstarten och levererar beviset. Vi arbetar på distans, utan resor, och dokumenterar varje steg. Vi lovar inga underverk: En patch stänger sårbarheten, den bevisar inte att inget hände tidigare, och det säger vi också rakt ut.
Berörs ni? Ring oss. Vi hjälper er.
Låt inte sårbarheten stå öppen längre. Ring eller skriv via WhatsApp. Vi tar över från första meddelandet och finns kvar tills incidenten är avslutad och dokumenterad. Anmäl nödläge nu.
Vanliga frågor
Kan jag stänga PHP-sårbarheten själv eller behöver jag hjälp?
En uppdatering är görbar för administratörer men felbenägen: Den måste gälla den version som faktiskt levererar, och alla processer måste startas om. Den som har flera servrar, containerimages eller ett webbhotell med egenheter sparar tid och fel med stöd.
Måste PHP startas om efter uppdateringen?
Ja. Nya filer räcker inte så länge gamla PHP-processer ligger kvar i minnet. Alla workers respektive processer måste startas om, vid mod_php webbservern.
Vad gör jag om det ännu inte finns någon uppdatering för min PHP-version?
För PHP 8.1 och äldre levererar PHP-projektet inga officiella uppdateringar längre. Då krävs en bevisligen patchad backport från leverantören, en migrering till en underhållen version eller tillfälliga åtgärder, som dock inte ger ett fullständigt skydd.
Räcker det att sätta session.upload_progress.enabled till 0?
Nej. Enligt fackrapporter stänger inställningen ensam inte båda sårbarheterna; PHP-uppdateringen är fortfarande ett måste. Sätt den bara i php.ini, FPM-poolen eller serverkonfigurationen, inte via ini_set() eller .user.ini.
Hur vet jag att sårbarheten verkligen är stängd efteråt?
Genom ett bevis på det körande systemet: version eller paketets changelog, ett test av det nya direktivet memory_hard_limit_percent och bekräftelsen att alla processer startades om efter uppdateringen.