Kort sagt: Vid en PHP-sårbarhet som PHP2Shell är det webbhotellet, inte ni, som ansvarar för PHP-uppdateringen. Er uppgift är att inhämta en skriftlig bekräftelse, välja en PHP-version som stöds i kundmenyn och kontrollera att er webbplats inte visar spår av ett angrepp. En patch från webbhotellet tar inte bort skadlig programvara som redan hamnat på er webbplats.
Läget med enkla ord
PHP är det programmeringsspråk som de flesta webbplatser, butiker och CMS som WordPress körs på. PHP2Shell är namnet på två kritiska fel i själva PHP (CVE-2026-109618 och CVE-2026-109619). Via dem kan angripare köra egen kod på servern utan lösenord. BSI (den tyska förbundsmyndigheten för informationssäkerhet) har utlyst varningsnivå 3 (orange) och rekommenderar en omedelbar uppdatering.
Vid shared hosting delar många kunder på en server. Tekniken under, alltså operativsystem, webbserver och PHP, drivs av webbhotellet. Ni förvaltar själva bara er webbplats, databas och åtkomster. Därför kan ni inte installera PHP-uppdateringen själva, och ni behöver inte heller göra det.
Webbhotell och PHP-sårbarhet: vem ansvarar?
Fördelningen följer av ert avtal. I de flesta abonnemang gäller ungefär följande fördelning:
| Uppgift | Webbhotellet | Ni som kund |
|---|---|---|
| Uppdatera PHP-paketen | ja | nej |
| Starta om PHP-processerna | ja | nej |
| Sätta serveromfattande tillfälliga värden | ja | nej |
| Välja PHP-version för er webbplats | tillhandahåller | väljer |
| Uppdatera CMS, plugin och teman | nej | ja |
| Inloggningsuppgifter och administratörskonton | nej | ja |
| Kontrollera webbplatsen med avseende på skadlig kod | delvis | ja |
| Dataskyddsrättslig bedömning | nej | ja |
Den sista raden är viktig: inträffar en incident med personuppgifter på er webbplats är det i regel ni som driftansvarig som bär ansvaret, inte webbhotellet. Mer om det under Anmälningsplikt enligt GDPR.
Det här bör ni göra själva nu
1. Inhämta bekräftelse. Fråga ert webbhotell skriftligt om PHP-versionerna i ert paket är skyddade mot båda CVE-numren, sedan när, och om alla PHP-processer har startats om. En färdig mall finns under Fråga webbhotellet om patchstatus. Bli inte förvånade om det i kundmenyn fortfarande står ett äldre versionsnummer som 8.2.34: vissa leverantörer levererar rättningar som backport utan att numret ändras.
2. Kontrollera PHP-versionen. Titta i kundmenyn efter vilken PHP-version er webbplats använder. PHP 8.1 och äldre får inga officiella uppdateringar längre från PHP-projektet. PHP 8.2 når slutet på supporten den 31 december 2026. Om ert CMS klarar en nyare version kontrollerar ni enligt tillverkarens systemkrav, till exempel på wordpress.org.
3. Kontrollera webbplatsen. Håll utkik efter okända administratörskonton, oväntade omdirigeringar, främmande filer i FTP-åtkomsten och varningar i Google Search Console. En lista över typiska tecken finns under Är jag redan komprometterad?.
4. Ta en säkerhetskopia. Ladda ned en aktuell säkerhetskopia av filer och databas och förvara den separat. Be dessutom webbhotellet spara åtkomstloggarna för ert paket från och med den 20 oktober 2026.
Byt efter webbhotellets bekräftelse i förebyggande syfte lösenorden för kundmenyn, FTP/SFTP, databasen och CMS-administratörerna och aktivera tvåfaktorsinloggning där det går.
Det ni inte kan lösa själva vid shared hosting
De tillfälliga åtgärder som php.net rekommenderar, till exempel session.upload_progress.enabled=0, fungerar bara om de sätts i serverkonfigurationen. En post i .user.ini eller via ini_set() i koden räcker enligt php.net inte. Även minnesgränser på cgroup-nivå och omstarten av PHP-processerna ligger hos webbhotellet.
Svarar ert webbhotell inte alls eller bara undvikande har ni tre alternativ: följa upp och sätta en frist, tillfälligt lägga webbplatsen i underhållsläge eller byta till en leverantör med ett tydligt besked. BSI rekommenderar att webbservrar tillfälligt kopplas bort från nätet om en uppdatering inte kan göras direkt.
Kontrollera också om ert abonnemang fortfarande är tidsenligt. Paket som har körts oförändrade i många år ligger ibland på äldre servergenerationer med äldre PHP-versioner som webbhotellet bara underhåller i begränsad omfattning. Ett byte till ett aktuellt abonnemang hos samma leverantör kräver ofta lite arbete och ger nyare PHP-versioner. Fråga efter det om svaret om patchstatus är otillfredsställande.
Om webbplatsen redan är avvikande
En patch hos webbhotellet stänger sårbarheten för framtiden. Den tar dock inte bort någon bakdörr som angripare byggde in tidigare och bevisar inte att ingenting har hänt dessförinnan. Hittar ni avvikelser ska ni inte radera filer urskillningslöst. Säkra först tillståndet så att orsaken går att följa upp senare.
Hur hjälper PHP SOS konkret?
- Vi formulerar förfrågan till webbhotellet tillsammans med er och bedömer svaret tekniskt.
- Vi kontrollerar er webbplats med avseende på webshells, främmande konton och manipulerade filer och rensar vid fynd via vår borttagning av skadlig kod.
- Vid akut misstanke tar vi över akuthjälpen för hackade webbplatser med bevissäkring.
- Vi hjälper till att välja en lämplig PHP-version och testar webbplatsen efteråt.
Vanliga frågor
Måste jag som webbhotellskund uppdatera PHP själv?
I regel inte, eftersom PHP vid shared hosting hör till webbhotellets plattform. Ofta kan ni dock välja PHP-version i kundmenyn. Står det där en version utan officiella uppdateringar bör ni byta eller fråga webbhotellet hur det skyddar den.
Min webbplats är nere. Har jag blivit hackad?
Inte nödvändigtvis. Vissa leverantörer har tagit webbplatser offline i förebyggande syfte för att täppa till sårbarheten. Fråga webbhotellet om orsaken och be om bekräftelse på om det finns tecken på ett angrepp mot ert paket.
Kan jag själv sätta de tillfälliga åtgärderna i .user.ini?
För session.upload_progress.enabled anger php.net uttryckligen att .user.ini och ini_set() inte räcker. Den inställningen måste webbhotellet sätta i serverkonfigurationen.
Vad bör jag ha skriftligt från webbhotellet?
En bekräftelse på att PHP-versionerna i ert paket är skyddade mot CVE-2026-109618 och CVE-2026-109619, från och med när det gäller och att PHP-processerna har startats om. Spara svaret tillsammans med era handlingar.