Akut säkerhetslarm – uppdatera webbservern nu

Två ovanligt allvarliga säkerhetshål har upptäckts i PHP, tekniken som ligger under en stor del av dagens webbplatser.

Sårbarheterna CVE-2026-109618 och CVE-2026-109619 kan under rätt förhållanden låta en utomstående angripare köra egen kod på en webbserver utan att först ha ett användarkonto. PHP-projektet har klassat båda som kritiska med 9,2 av 10 på CVSS-skalan och säger att uppdatering är det enda fullständiga skyddet.

Problemet kallas gemensamt PHP2Shell. Säkerhetsuppdateringarna släpptes den 21 oktober efter att information om de hemliga sårbarheterna börjat läcka före det planerade offentliggörandet.

WordPress kan påverkas utan att WordPress är felet

Säkerhetshålen ligger i själva PHP-motorn. Det betyder att problemet inte är en specifik WordPress-plugin, Joomla-komponent eller Drupal-modul.

En helt uppdaterad WordPressinstallation kan fortfarande ligga på en sårbar server om PHP-versionen under webbplatsen inte har uppdaterats. Samma sak gäller bland annat Magento, MediaWiki och andra system byggda med PHP.

PHP uppger att installationer som hanterar webbförfrågningar kan vara utsatta, däribland PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Risken bedöms som särskilt hög för Apache med mod_php, där forskare har demonstrerat en attack innan webbplatsens egen programkod ens börjar köras.

De här PHP-versionerna innehåller fixen

PHP har släppt fyra säkerhetsversioner: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 och PHP 8.2.35

Den som använder någon av dessa huvudversioner bör minst ligga på respektive versionsnummer ovan. PHP säger uttryckligen att tillfälliga skydd inte är fullständiga och att själva PHP-installationen måste uppdateras.

För äldre PHP 7.4, 8.0 och 8.1 har minimala källkodspatchar också publicerats, men versionerna är sedan tidigare utanför normal support. Den som fortfarande driver en webbplats på så gammal PHP bör därför se det här som ytterligare anledning att flytta till en stödd version. PHP 8.2 når dessutom slutet av sin säkerhetssupport den 31 december 2026.

Hackare behöver inte något lösenord

Det som gör PHP2Shell extra allvarligt är att attacken kan ske utan autentisering.

CVE-2026-109618 berör hur PHP hanterar situationer där processen får slut på minne. Under vissa förhållanden kan intern data lämnas i ett felaktigt tillstånd och senare behandlas som om den vore giltig.

CVE-2026-109619 handlar i stället om internt tillstånd som kan bli kvar efter att minnet bakom informationen redan har frigjorts. När samma PHP-process hanterar en senare förfrågan kan den komma åt det gamla minnet igen.

Forskarna har visat att problemen kan användas både för fjärrkörning av kod och för att läsa delar av PHP-processens minne. Där kan det i värsta fall ligga lösenord, API-nycklar, autentiseringstokens och annan känslig information.

Attackförsök började direkt

PHP-teamet hade egentligen planerat att offentliggöra sårbarheterna den 22 oktober.

Men tekniska detaljer började läcka redan den 20 oktober. Bland annat publicerades en video som demonstrerade en fungerande attack innan den snabbt togs bort. PHP flyttade därför fram säkerhetsutgåvan med ett dygn.

Samtidigt började automatiserade attacker synas.

Cloudflare uppger att företaget sett trafik som aktivt försöker utnyttja PHP2Shell och att angriparna redan har förändrat sina attackförfrågningar för att försöka ta sig förbi nya skyddsregler.

SecurityWeek rapporterade initialt att flera säkerhetsföretag såg försök men ännu inga bekräftat framgångsrika intrång. Situationen har därefter förändrats.

Minst ett lyckat utnyttjande har nu setts

Den 22 oktober meddelade Sophos att deras säkerhetsanalytiker observerat flera försök som stämmer överens med PHP2Shell och ett fall där sårbarheten utnyttjades framgångsrikt.

Sophos har däremot inte sett belägg för att händelsen följts av ransomware, datastöld eller en attack mot mjukvaruleveranskedjan. Möjligheten att gå från själva sårbarheten till full fjärrkörning påverkas också av serverns PHP-version, arkitektur och konfiguration.

Det betyder att formuleringen ”aktiva attacker” nu är motiverad, men inte att alla exponerade PHP-servrar har hackats.

Nära 70 procent av webben använder PHP

Omfattningen blir tydlig när man tittar på hur vanligt PHP är.

W3Techs uppskattar att PHP används av drygt 69 procent av alla webbplatser där det går att identifiera vilket serverspråk som används. Det betyder inte att 69 procent av alla webbplatser automatiskt är sårbara för PHP2Shell, eftersom PHP-version, serverkonfiguration och exponering spelar roll.

Palo Alto Networks säger samtidigt att deras system identifierat över 22,6 miljoner internetexponerade PHP-instanser som potentiellt kan vara sårbara. Även det är en exponeringsoch riskuppskattning, inte ett antal bekräftat hackade webbplatser.

Ett webbhotell kan sköta uppdateringen åt dig

För många vanliga webbplatsägare är PHP inget program de själva har installerat.

Om webbplatsen ligger hos ett webbhotell är det ofta leverantören som ansvarar för PHP-versionen. I kontrollpanelen brukar det gå att se vilken version webbplatsen kör och i vissa fall välja en nyare.

Har du exempelvis WordPress men ingen egen server bör du därför kontrollera PHP-versionen i webbhotellets kontrollpanel eller kontakta leverantören.

Det räcker inte att bara trycka på ”Uppdatera WordPress”. Cloudflare poängterar uttryckligen att problemet ligger i PHP-runtime och att uppdateringar av webbplatsens plugins eller egen kod inte i sig löser sårbarheten.

Cloudflare har lagt in extra skydd

Den som använder Cloudflares webbapplikationsbrandvägg har fått ytterligare ett skyddslager.

Cloudflare säger att PHP2Shell-regler aktiverades automatiskt även för kunder på gratisnivån före det fullständiga offentliggörandet. Företaget fortsätter att justera skyddet när nya attackvarianter dyker upp.

Men inte ens Cloudflare beskriver WAF-skyddet som en ersättning för uppdateringen. Företaget rekommenderar fortfarande att PHP patchas.

PHP-projektets besked är ännu tydligare: det finns ingen komplett workaround.

Har du en äldre webbserver bör du agera nu

För en privat blogg bakom ett modernt webbhotell kan säkerhetsuppdateringen redan vara installerad utan att ägaren gjort någonting.

Problemet blir större för egenadministrerade servrar, gamla företagswebbar och system som fortfarande kör PHP-versioner som varit ur support i flera år.

Där kan både uppdateringen och eventuella kompatibilitetsproblem behöva hanteras manuellt.

Storbritanniens nationella cybersäkerhetscenter uppmanar organisationer att först identifiera samtliga PHP-installationer och prioritera sådant som går att nå från internet. Myndigheten varnar också för att man inte bör leta enbart efter gamla PHP-versioner eftersom samtliga versioner före de nya säkerhetsutgåvorna måste bedömas.

Läs mer:1400 säkerhetshål upptäckta – Microsoft vill att du uppdaterar nu

Det här bör du kontrollera

Har du ansvar för en webbplats är den viktigaste frågan vilken PHP-version servern faktiskt använder.

Kör du PHP 8.5 bör den vara 8.5.12 eller senare. För PHP 8.4 gäller 8.4.27, för PHP 8.3 8.3.36 och för PHP 8.2 8.2.35.

Äldre versioner bör inte betraktas som en långsiktig lösning även om en patch går att backporta.

Och eftersom attackförsök började nästan samtidigt som säkerhetsfixarna blev offentliga finns det betydligt mindre utrymme än vanligt för principen ”jag uppdaterar nästa vecka”.

För en sårbar internetansluten PHP-server är nästa vecka potentiellt väldigt långt bort.