Gammal PHP-version? Risker, php2shell och så uppgraderar ni

Den 21 oktober 2026 släppte PHP-projektet akuta säkerhetsuppdateringar för två kritiska sårbarheter som går under namnet php2shell. De gör det möjligt för en angripare att köra egen kod på en webbserver – utan att logga in. För den som redan kör en PHP-version som inte längre får uppdateringar finns ingen officiell rättning alls.

Det här berör väldigt många svenska företag. WordPress, WooCommerce, Joomla, Drupal och Magento är alla byggda på PHP, och enligt W3Techs körs PHP på 69,3 procent av alla webbplatser där serverspråket går att identifiera. Av dem kör 7,7 procent fortfarande PHP 5 och 26,9 procent PHP 7 – versioner som inte har fått en enda säkerhetsuppdatering på flera år.

I den här artikeln går vi igenom vad som hänt, vilka PHP-versioner som stöds just nu, hur ni tar reda på vad ni själva kör och hur ni uppgraderar utan att sajten går sönder.

Vad är php2shell?

php2shell är samlingsnamnet på två sårbarheter i själva PHP-motorn:

• CVE-2026-109618 – minneskorruption när PHP får slut på minne mitt i hanteringen av en förfrågan, till exempel en filuppladdning. Uppstädningen kan då behandla halvfärdig data som giltig.
• CVE-2026-109619 – en så kallad use-after-free där information från en tidigare förfrågan ligger kvar i en arbetsprocess och kan återanvändas av nästa förfrågan.

Båda har allvarlighetsgraden 9,2 av 10 enligt CVSS 4.0 och kan enligt PHP-projektets egen säkerhetsavisering utnyttjas av en angripare som inte är inloggad. Det som står på spel är fjärrkörning av kod med webbserverns behörigheter – alltså samma åtkomst som er webbplats har till databasen, kundregistret och konfigurationsfilerna med lösenord.

Enligt PHP-projektet är alla installationer som tar emot webbtrafik i riskzonen: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Risken bedöms som högst för mod_php, där en enda förfrågan kan räcka och attacken sker innan någon av webbplatsens egen kod ens har körts. Det betyder att det inte hjälper att ert CMS eller era tillägg är uppdaterade – felet sitter ett lager under.

Hur allvarligt är läget just nu?

Bedömningarna skiljer sig något åt mellan källorna, vilket är normalt de första dagarna efter en publicering:

• Amazon har enligt Tenables sammanställning sett försök att utnyttja sårbarheterna redan den 17 oktober, fyra dagar innan rättningen publicerades, och fler försök efter publiceringen. Cloudflare rapporterar tidiga attacker.
• Rapid7 har granskat de publika exploateringskoder som cirkulerar och bedömer att var och en bara fungerar för en viss kombination av operativsystem, PHP-version och webbserver – men räknar med att utnyttjandet ökar.
• Amerikanska CISA och EU:s CERT-EU uppmanar till omedelbar uppdatering. CERT-EU rekommenderar att internetexponerade system som inte kan uppdateras isoleras tills rättningen är på plats.

Historiken talar sitt tydliga språk. När sårbarheten CVE-2024-4577 i PHP-CGI på Windows publicerades i juni 2024 dröjde det bara några dagar innan den användes för att sprida ransomware, och den hamnade snabbt i CISA:s katalog över aktivt utnyttjade sårbarheter. Räkna med att samma sak händer igen.

Vilka versioner rättar felen?

Uppdatera till någon av följande versioner eller senare:

För PHP 7.4, 8.0 och 8.1 har PHP:s säkerhetsteam publicerat minimala rättningar i källkod, avsedda för den som kompilerar PHP själv. Äldre grenar än så får ingenting från PHP-projektet. Linuxdistributioner och leverantörer av långtidssupport fick rättningarna i förväg – kör ni till exempel Debian, Ubuntu eller Red Hat ska ni följa deras säkerhetsmeddelanden.

Vilka PHP-versioner stöds just nu?

PHP-projektet stöder varje version i fyra år: två år med aktivt stöd (buggfixar och säkerhetsfixar) och därefter två år med enbart säkerhetsfixar. Läget i oktober 2026 enligt php.net:

Två saker att notera. PHP 8.2 slutar få säkerhetsuppdateringar den 31 december 2026, alltså om drygt två månader. Den som kör 8.2 i dag har klarat sig från php2shell genom att uppdatera, men behöver planera nästa uppgradering redan nu. Och PHP 8.6 är på väg – den är i skrivande stund i release candidate-fas och ska inte användas i produktion förrän den släppts skarpt.

Varför är en gammal PHP-version en säkerhetsrisk?

Det är lätt att tänka att en sajt som fungerar inte behöver röras. Problemet är att det som skyddar den hela tiden blir sämre:

1. Kända sårbarheter rättas aldrig. När en version har passerat sitt slutdatum publiceras nya sårbarheter som påverkar den, men ingen rättning. php2shell är ett exempel: enligt Tenables sammanställning går den sårbara koden tillbaka ända till PHP 5.4.
2. Angripare letar automatiskt. Ingen sitter och väljer ut just er sajt. Botar skannar hela internet efter servrar som avslöjar en sårbar version, ofta i en HTTP-header som X-Powered-By: PHP/7.4.33.
3. Tillägg och teman hänger inte med. WordPress rekommenderar PHP 8.3 eller senare och varnar för att äldre versioner kan exponera sajten för sårbarheter. Nya versioner av tillägg slutar stödja gamla PHP-versioner, och då fastnar sajten även på gamla tillägg.
4. Det blir svårare att uppfylla lagkrav. GDPR kräver lämpliga tekniska åtgärder för att skydda personuppgifter, och för verksamheter som omfattas av cybersäkerhetslagen är säkerhet vid underhåll av system ett uttryckligt krav. En programvara utan säkerhetsstöd är svår att försvara efter en incident.

En viktig nyans: kör ni en Linuxdistribution med långtidssupport kan versionsnumret se gammalt ut trots att säkerhetsrättningar har förts in i efterhand, så kallad bakportering. Ubuntu och Red Hat gör det för de PHP-paket som ingår i distributionen under dess supporttid. Kontrollera då distributionens säkerhetsmeddelanden snarare än bara versionsnumret.

Så kollar ni vilken PHP-version ni kör

Börja med att lista alla webbplatser och system ni har – även den gamla kampanjsajten, testmiljön på en underdomän och intranätet som byråns praktikant byggde 2019. Det är oftast de bortglömda sajterna som blir vägen in. Kontrollera sedan varje sajt på något av följande sätt:

• Webbhotellets kontrollpanel. De flesta svenska webbhotell visar vilken PHP-version varje sajt kör och låter er byta version själva.
• WordPress. Gå till Verktyg → Webbplatsens hälsa → Info → Server. Där står PHP-versionen, och WordPress varnar om den är för gammal.
• Kommandoraden. php -v visar versionen för kommandoradsverktyget, men det kan vara en annan version än den som faktiskt kör webbplatsen. Kontrollera även PHP-FPM, till exempel med php-fpm8.3 -v, eller Apaches modul.
• HTTP-headern. curl -sI https://er-sajt.se | grep -i x-powered-by visar versionen om servern avslöjar den. Gör den det bör ni stänga av det med expose_php = Off i php.ini – läs mer i vår guide till säkerhetsheaders.
• Vår gratis skanning. Secvras säkerhetsskanning flaggar bland annat PHP-versioner som inte stöds eller saknar den senaste säkerhetsrättningen, om servern exponerar versionen.

Undvik att lägga upp en fil med phpinfo() på en publik sajt. Måste ni göra det, ta bort den direkt efteråt – den avslöjar mycket mer än versionsnumret.

Så uppgraderar ni utan att sajten går sönder

En uppgradering från PHP 7.4 till 8.4 är sällan svår, men den kräver lite förberedelse. Så här gör vi det i våra uppdrag:

1. Ta en fullständig säkerhetskopia av filer och databas, och kontrollera att den går att återställa.
2. Uppdatera CMS, tillägg och teman först, medan ni fortfarande kör den gamla PHP-versionen. Nyare versioner av tilläggen har oftast redan stöd för nyare PHP.
3. Testa i en kopia av sajten. Många webbhotell erbjuder en staging-miljö med ett klick. Byt PHP-version där och klicka igenom det viktigaste: startsida, formulär, inloggning, kassa och betalning.
4. Leta efter inkompatibel kod. För egenutvecklad kod kan verktyget PHPCompatibility för PHP_CodeSniffer hitta funktioner som tagits bort eller ändrats.
5. Byt version i produktion vid en tidpunkt med lite trafik och håll koll på felloggen de närmaste dagarna.
6. Städa efteråt. Ta bort gamla PHP-versioner från servern om ni driftar själva, och se till att versionen inte syns i HTTP-headers.

Om ni inte kan uppdatera i dag

PHP-projektet listar tillfälliga åtgärder som minskar risken för php2shell, men de gör uttryckligen inte en installation säker. Bland annat:

; Sätts i php.ini, FPM-poolen eller serverkonfigurationen – inte via ini_set() eller .user.ini.
; Starta därefter om samtliga PHP-processer.
session.upload_progress.enabled = 0
memory_limit = -1          ; måste sättas så att applikationen inte kan skriva över värdet
post_max_size = 8M         ; 32M om ni behöver filuppladdning
fatal_error_backtraces = 0 ; endast PHP 8.5

Läs hela listan i PHP:s säkerhetsavisering innan ni ändrar något, eftersom vissa åtgärder kan påverka hur sajten fungerar. Nederländska NCSC har också samlat listor över programvara som bäddar in PHP, vilket är bra att gå igenom – PHP kan finnas i produkter där ni inte väntar er det, som administrationsgränssnitt och nätverksutrustning.

Checklista för VD och IT-ansvarig

• Vi har en lista över alla webbplatser och system som kör PHP, inklusive gamla och interna.
• Varje system kör PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 eller senare – eller en distributionsversion med bakporterad rättning.
• System på PHP 8.1 eller äldre har en plan för uppgradering med datum och ansvarig, och är isolerade tills dess.
• Vi har frågat webbhotellet eller IT-leverantören skriftligt vilken version och patchnivå vi kör.
• Sajter på PHP 8.2 är inplanerade för uppgradering före 31 december 2026.
• Någon bevakar säkerhetsuppdateringar framöver, så att vi inte är beroende av att läsa om nästa sårbarhet i nyheterna.

Den sista punkten är den viktigaste. php2shell kommer inte att vara den sista kritiska sårbarheten i PHP. Med löpande övervakning skannas era sajter varje vecka och ni får larm när en version blir sårbar eller når sitt slutdatum. Vill ni ha hjälp att inventera och uppgradera kan ni boka ett kort samtal eller börja med en gratis skanning.

Källor

• PHP-projektet: säkerhetsavisering 21 oktober 2026, versioner som stöds och versioner som inte längre stöds
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• CERT-EU: Security Advisory 2026-018
• Tenable: php2shell – frequently asked questions
• Rapid7: CVE-2026-109618 and CVE-2026-109619
• W3Techs: Usage statistics of PHP, hämtat 22 oktober 2026