Två kritiska säkerhetshål i PHP har utlöst ett akut säkerhetslarm. Sårbarheterna kan göra det möjligt för angripare att köra skadlig kod på webbservrar utan lösenord eller inloggning. Eftersom bristerna finns i själva PHP-motorn kan även välskötta webbplatser drabbas. PHP-utvecklarna har nu släppt säkerhetsuppdateringar och uppmanar alla serveradministratörer att uppdatera omedelbart.
Den 21 oktober 2026 gick PHP:s utvecklingsteam ut med en ovanligt skarp säkerhetsvarning. Två allvarliga sårbarheter har upptäckts i PHP, det programmeringsspråk som används bakom en stor del av världens webbplatser.
Bristerna har fått beteckningarna CVE-2026-109618 och CVE-2026-109619. Båda har tilldelats allvarlighetsgraden 9,2 av 10 enligt säkerhetsskalan CVSS 4.0, vilket placerar dem i den högsta riskkategorin.
Det allvarliga är att en angripare i vissa serverkonfigurationer kan utnyttja säkerhetshålen genom att skicka särskilt utformade förfrågningar till webbservern. Angriparen behöver varken känna till något lösenord eller ha ett användarkonto.
I värsta fall kan angriparen få servern att köra egen programkod. Säkerhetsbristerna har även fått smeknamnet php2shell, en anspelning på möjligheten att ta sig från en vanlig webbförfrågan till att köra kommandon på servern.
Vad är PHP och varför är säkerhetshålen så allvarliga?
PHP har funnits sedan 1990-talet och är fortfarande ett av internets mest använda programmeringsspråk för dynamiska webbplatser.
När någon exempelvis besöker en webbshop, loggar in på en webbplats eller skickar ett formulär används ofta PHP för att behandla informationen på servern.
Publiceringssystem som WordPress, Drupal och många andra webbapplikationer bygger helt eller delvis på PHP.
Normalt arbetar PHP i bakgrunden. Webbservern tar emot en förfrågan, PHP behandlar den och resultatet skickas tillbaka till besökarens webbläsare.
Problemet med de nyupptäckta säkerhetsbristerna är att felen ligger inne i själva PHP-motorn, inte i programkoden som webbplatsens utvecklare har skrivit.
Det innebär att även en välskött webbplats med uppdaterade tillägg och säkra lösenord kan vara sårbar om servern använder en osäker PHP-version.
Det behövs alltså inte någon sårbar WordPress-installation eller ett dåligt programmerat formulär för att ett angrepp ska vara möjligt.
När datorns minne blir en säkerhetsrisk
Den första sårbarheten, CVE-2026-109618, handlar om hur PHP hanterar situationer när programmets tillgängliga arbetsminne tar slut.
För att förstå problemet kan man föreställa sig en bibliotekarie som håller på att registrera nya böcker. Mitt under arbetet kommer en order om att omedelbart avbryta och städa undan allt material.
Men eftersom registreringen inte hann slutföras vet bibliotekarien inte längre vilka böcker som faktiskt är färdigbehandlade.
Något liknande kan inträffa i PHP.
När PHP får slut på tillåtet minne kan programmet avbryta en pågående operation. Problemet är att vissa interna datastrukturer då bara är delvis färdigställda.
När PHP därefter försöker städa upp efter den avbrutna operationen kan programmet använda felaktig information om minnet.
Detta kan i sin tur öppna möjligheten för en angripare att påverka programmets beteende och i vissa fall få egen kod att köras på servern.
Säkerhetsforskarna har visat att särskilt utformade HTTP-förfrågningar kan utlösa problemet.
Det anmärkningsvärda är att angreppet i vissa fall kan lyckas innan webbplatsens egen programkod över huvud taget har börjat köras.
Den andra sårbarheten – information som inte försvinner
Den andra bristen, CVE-2026-109619, är besläktad med den första men fungerar på ett annat sätt.
För att spara resurser återanvänder webbservrar ofta samma PHP-process för att behandla flera förfrågningar efter varandra.
Normalt ska information från en tidigare förfrågan rensas bort innan nästa behandlas.
Men forskarna har upptäckt situationer där PHP lämnar kvar interna referenser till minnesområden som redan har frigjorts.
Det är ungefär som att en anställd försöker hämta ett dokument ur ett arkivskåp som redan har tömts och sedan fyllts med helt andra handlingar.
I programmering kallas detta för use-after-free, alltså att ett program försöker använda minne efter att det har frigjorts.
Om en angripare lyckas påverka innehållet i dessa minnesområden kan resultatet bli att servern börjar utföra instruktioner som aldrig var avsedda att köras.
Det är en allvarlig säkerhetsbrist eftersom den kan ge möjlighet till fjärrkörning av kod, på engelska Remote Code Execution (RCE).
Problemet kan dessutom uppstå mellan två olika webbförfrågningar som behandlas av samma PHP-process. Det gör säkerhetsbristen särskilt besvärlig eftersom felaktigt minnestillstånd kan leva kvar efter att en tidigare förfrågan har avslutats.
Apache med mod_php särskilt utsatt
Enligt PHP:s eget säkerhetsmeddelande är risken särskilt stor på webbservrar som kör Apache tillsammans med modulen mod_php.
I denna konfiguration har säkerhetsforskare demonstrerat att en angripare kan utnyttja säkerhetsbristerna innan webbplatsens egen programkod ens börjar köras.
Det betyder att skydd som är inbyggda i exempelvis WordPress eller andra PHP-applikationer inte nödvändigtvis hjälper.
Även andra PHP-miljöer omfattas av säkerhetsvarningen. Det gäller bland annat PHP-FPM, som ofta används tillsammans med Apache eller Nginx, liksom php-cgi, FrankenPHP och LiteSpeed.
PHP-FPM är en vanlig lösning på moderna Linuxservrar. Där körs PHP som en separat tjänst som tar emot förfrågningar från webbservern.
Att en server använder någon av dessa tekniker betyder inte att den automatiskt har blivit angripen. Däremot kan den vara sårbar om den kör en PHP-version utan säkerhetsrättningarna.
Om ett angrepp lyckas kan angriparens kod köras med samma rättigheter som PHP-processen. Det innebär inte automatiskt fullständig administratörsbehörighet, men kan ändå ge tillgång till webbplatsens filer, konfigurationsuppgifter, databasinloggningar och annan känslig information.
Akuta säkerhetsuppdateringar har släppts
PHP-utvecklarna har publicerat fyra uppdaterade versioner där båda säkerhetshålen har åtgärdats.
- PHP 8.5 uppdateras till version 8.5.12.
- PHP 8.4 uppdateras till version 8.4.27.
- PHP 8.3 uppdateras till version 8.3.36.
- PHP 8.2 uppdateras till version 8.2.35.
PHP 8.1 och tidigare får inte längre ordinarie säkerhetsuppdateringar från PHP-projektet.
Vissa Linuxdistributioner och leverantörer med långtidsstöd tillhandahåller dock egna säkerhetsrättningar för äldre versioner.
PHP 8.2 närmar sig dessutom slutet på sin officiella livscykel. Den 31 december 2026 upphör projektets säkerhetsstöd för denna versionsserie.
Debian och Arch Linux agerar snabbt
Flera stora Linuxdistributioner har redan reagerat på säkerhetsvarningen.
Debian har publicerat säkerhetsmeddelandet DSA-6574-1 och släppt rättade paket för Debian 13, med kodnamnet Trixie.
Den säkerhetsrättade paketversionen är 8.4.27-1~deb13u1.
Även Debian 12, Bookworm, har fått en uppdatering genom sitt säkerhetsförråd. Där används PHP 8.2 och den rättade paketversionen är 8.2.35-1~deb12u1.
Arch Linux har samtidigt gått ut med en uttrycklig uppmaning till alla som driver publika PHP-webbplatser att omedelbart uppdatera sina installationer.
För Arch Linux gäller PHP 8.5.12 eller senare. Användare av paketet php-legacy behöver version 8.3.36 eller senare.
Även AlmaLinux arbetar med säkerhetsrättningarna. Projektet har beslutat att förbereda uppdaterade paket utan att invänta motsvarande uppdateringar från Red Hat och CentOS Stream.
Enligt AlmaLinux planeras de rättade paketen först till testförråden och därefter till de ordinarie paketförråden när kontrollerna är färdiga.
För andra Linuxdistributioner gäller det att kontrollera respektive leverantörs säkerhetsmeddelanden och paketförråd.
Vad behöver den som driver en webbserver göra?
Det viktigaste är att kontrollera vilken PHP-version som används och installera tillgängliga säkerhetsuppdateringar.
På Debian- och Ubuntubaserade system kan man börja med kommandot php -v för att kontrollera PHP-versionen i terminalen.
Administratören bör därefter uppdatera PHP-paketen genom distributionens ordinarie pakethanterare.
På Debian och Ubuntu används normalt apt. Kommandot sudo apt update uppdaterar informationen om tillgängliga paket, medan sudo apt upgrade installerar tillgängliga uppdateringar.
Det är viktigt att komma ihåg att versionen som visas med php -v inte nödvändigtvis är densamma som används av webbservern. PHP-FPM och andra servermiljöer kan använda en annan installerad version.
Linuxdistributioner kan dessutom ha säkerhetsrättningar som har lagts tillbaka i äldre paketversioner. Därför bör man kontrollera distributionens säkerhetsmeddelanden och paketinformation, inte enbart PHP:s versionsnummer.
Efter uppdateringen behöver berörda PHP-processer och webbtjänster startas om så att den rättade programkoden verkligen börjar användas.
Den som driver en WordPress-webbplats bör också känna till att det inte räcker att uppdatera WordPress, teman och tillägg. Själva PHP-miljön på servern måste vara säkerhetsuppdaterad.
Den som använder ett webbhotell och saknar möjlighet att själv uppdatera PHP bör kontakta leverantören och fråga om säkerhetsbristerna har åtgärdats.
Finns det något tillfälligt skydd?
PHP-utvecklarna har publicerat flera rekommendationer som kan minska risken om en server inte kan uppdateras omedelbart.
Exempelvis kan vissa angreppsvägar begränsas genom att justera PHP:s minnesinställningar, begränsa storleken på inkommande förfrågningar och stänga av funktionen session.upload_progress.enabled.
Men utvecklarna understryker att dessa åtgärder inte erbjuder ett fullständigt skydd. Vissa av ändringarna kan dessutom påverka hur applikationer fungerar eller hur servern hanterar resursbrist.
Den enda kompletta lösningen är att installera en säkerhetsrättad PHP-version.
Ett säkerhetsproblem som berör stora delar av internet
Det som gör dessa två PHP-sårbarheter särskilt oroande är att de inte förutsätter att någon har gjort ett misstag när en webbplats programmerades.
Säkerhetsbristerna finns i den programvara som behandlar webbplatsens förfrågningar, på en nivå där vanliga applikationer inte alltid har möjlighet att ingripa.
Detta visar hur viktigt det är att hålla även den underliggande servermiljön uppdaterad.
En webbplats kan ha säkra lösenord, välskriven programkod och alla sina tillägg uppdaterade, men ändå vara sårbar på grund av ett fel i själva PHP-motorn.
För den som ansvarar för en Linuxserver med PHP är rekommendationen därför tydlig: kontrollera säkerhetsuppdateringarna och installera rättningarna så snart som möjligt.
Källor
- PHP – officiellt säkerhetsmeddelande, 21 oktober 2026
- CVE-2026-109618 – National Vulnerability Database
- CVE-2026-109619 – National Vulnerability Database
- Debian Security Advisory DSA-6574-1
- Arch Linux – säkerhetsvarning
- AlmaLinux – php2shell och säkerhetsuppdateringar
CVE-2026-109618
CVE-2026-109619
9,2 / 10 (CVSS 4.0)
Klassificering: KRITISK
Remote Code Execution (RCE)
Minneskorruption
Use-after-free
> Apache / mod_php
> PHP-FPM
> php-cgi
> FrankenPHP
> LiteSpeed
PHP 8.4 → 8.4.27
PHP 8.3 → 8.3.36
PHP 8.2 → 8.2.35
Webbservrar som behandlar PHP-förfrågningar och saknar säkerhetsrättningarna. Högst risk har Apache med mod_php. Angrepp kan i vissa fall ske utan autentisering.
[2] Installera säkerhetsuppdateringar
[3] Starta om berörda PHP-tjänster
[4] Verifiera att rättningen är aktiv
Publicerad: 2026-10-21
Källa: php.net
