Två allvarliga säkerhetshål i PHP har utlöst miljontals angreppsförsök mot webbservrar världen över. Sårbarheterna, som fått samlingsnamnet PHP2Shell, kan i värsta fall göra det möjligt för en angripare att köra skadlig kod eller komma åt känslig information på en server. Även webbplatser som använder WordPress kan vara berörda.

Det avgörande är vilken PHP-version servern använder och om säkerhetsuppdateringarna har installerats. Här går vi igenom vilka versioner som är sårbara, hur du kontrollerar din webbplats och vad du behöver göra för att minska risken för intrång.

Vilka PHP-versioner är drabbade?

Den 21 oktober 2026 släppte PHP-projektet säkerhetsuppdateringar för två kritiska sårbarheter. De har beteckningarna CVE-2026-109618 och CVE-2026-109619 och har båda fått allvarlighetsgraden 9,2 av 10 enligt säkerhetsskalan CVSS 4.0.

Följande versioner innehåller de aktuella säkerhetsrättningarna:

PHP-version	Säkerhetsläge
PHP 8.5.12 eller senare	Rättad inom 8.5-serien
PHP 8.4.27 eller senare	Rättad inom 8.4-serien
PHP 8.3.36 eller senare	Rättad inom 8.3-serien
PHP 8.2.35 eller senare	Rättad inom 8.2-serien
Tidigare utgåvor i dessa serier	Sårbara utan särskild säkerhetsrättning
PHP 8.1 och äldre	Kräver särskild kontroll av leverantörens säkerhetsstöd

Tabellen gäller de officiella PHP-utgåvorna. Vissa webbhotell och Linuxdistributioner använder egna säkerhetsuppdateringar, vilket betyder att en äldre version kan ha fått en rättning utan att versionsnumret ändrats till någon av utgåvorna ovan.

Om du använder en äldre PHP-version ska du därför inte automatiskt dra slutsatsen att webbplatsen är oskyddad. Men du behöver kunna bekräfta att rättningen finns installerad.

Den som vill kontrollera vilka versioner som har släppts kan använda PHP-projektets officiella information om säkerhetsuppdateringarna.

PHP 8.2 behöver snart bytas ut

Även PHP 8.2 har fått säkerhetsuppdateringar för de aktuella bristerna. Däremot upphör det officiella säkerhetsstödet för versionsserien den 31 december 2026.

En webbplats som fortfarande kör PHP 8.2 kan alltså få den omedelbara sårbarheten åtgärdad, men behöver ändå planera för en nyare version.

För äldre versioner som PHP 7.4, 8.0 och 8.1 är situationen mer komplicerad. De omfattas inte längre av PHP-projektets ordinarie säkerhetsunderhåll. Vissa leverantörer erbjuder ändå särskilda rättningar, och därför måste säkerhetsläget bedömas utifrån den faktiska servermiljön.

Så kontrollerar du PHP-versionen i WordPress

För många webbplatsägare är WordPress den enklaste vägen till information om vilken PHP-version som används.

Du behöver inte kunna programmera eller ha tillgång till serverns kommandorad.

1. Logga in i WordPress administrationspanel.
2. Gå till Verktyg → Webbplatshälsa.
3. Klicka på fliken Information.
4. Öppna avsnittet Server.
5. Leta efter raden PHP-version.

Jämför versionsnumret med tabellen ovan.

Om webbplatsen exempelvis använder PHP 8.4.26 är den officiella versionen äldre än den rättade utgåvan 8.4.27. Då behöver du undersöka om webbhotellet har installerat en separat säkerhetsrättning eller om PHP behöver uppdateras.

Varför räcker det inte att uppdatera WordPress?

WordPress och PHP är två olika saker.

WordPress är systemet du använder för att skapa och hantera webbplatsens innehåll. PHP är programmeringsspråket som ligger bakom stora delar av funktionaliteten.

När någon besöker en WordPress-webbplats kör servern PHP-kod för att bland annat hämta innehåll, hantera inloggningar och bygga upp sidan.

Det innebär att en webbplats kan ha:

• Senaste versionen av WordPress.
• Uppdaterade teman och tillägg.
• Starka lösenord och tvåfaktorsautentisering.
• En gammal och sårbar PHP-version.

De tre första punkterna är viktiga för säkerheten, men de åtgärdar inte ett säkerhetshål i själva PHP-motorn.

Sårbarheterna i PHP2Shell ligger dessutom på en sådan nivå att de under vissa förutsättningar kan utnyttjas innan webbplatsens egen kod hinner kontrollera en inkommande förfrågan.

Därför kan det vara otillräckligt att enbart förlita sig på WordPress vanliga säkerhetsfunktioner.

Så uppdaterar du PHP utan att förstöra webbplatsen

På vanliga webbhotell ändras PHP-versionen normalt i webbhotellets kontrollpanel, inte direkt i WordPress.

Hur det fungerar varierar mellan olika leverantörer. Det kan finnas en särskild inställning för PHP-version, en administrationssida för webbplatsens servermiljö eller möjlighet att kontakta supporten.

Innan ett större versionsbyte är det klokt att:

1. Säkerhetskopiera webbplatsens filer och databas.
2. Kontrollera att WordPress, teman och tillägg är uppdaterade.
3. Undersöka om något äldre tillägg saknar stöd för den nya PHP-versionen.
4. Genomföra versionsbytet.
5. Testa webbplatsens viktigaste funktioner efteråt.

En säkerhetskopia är särskilt viktig om webbplatsen innehåller kundkonton, betalningsfunktioner eller andra tjänster som inte får sluta fungera.

Men det finns en viktig avvägning: En allvarlig säkerhetssårbarhet ska inte lämnas öppen under lång tid bara för att en fullständig uppgradering känns besvärlig.

Om ett äldre tillägg förhindrar uppgraderingen bör du kontakta webbhotellet eller den tekniskt ansvariga. I vissa fall går det att installera en riktad säkerhetsuppdatering utan att omedelbart byta till en helt ny PHP-serie.

WordPress har också en officiell guide för att uppdatera PHP som förklarar hur versionsbyte och kompatibilitetskontroll fungerar.

Fyra frågor att ställa till webbhotellet

Om du är osäker på serverns säkerhetsläge kan du kontakta supporten och fråga:

1. Vilken PHP-version använder min webbplats?
2. Är CVE-2026-109618 och CVE-2026-109619 åtgärdade på servern?
3. Har ni installerat en särskild säkerhetsrättning om versionsnumret fortfarande är äldre?
4. Har ni undersökt misstänkt trafik och sett till att uppdateringen används av de körande PHP-processerna?

Det räcker alltså inte alltid med svaret att servern är uppdaterad. Det viktiga är att de två aktuella säkerhetshålen verkligen har åtgärdats.

Vad är PHP2Shell och hur fungerar säkerhetshålen?

PHP är ett av världens mest använda programmeringsspråk för webbtjänster. Det används inte bara av WordPress utan också av många andra publiceringssystem, webbapplikationer och specialbyggda företagstjänster.

PHP2Shell är samlingsnamnet på två säkerhetsbrister som berör hur PHP hanterar information i serverns minne.

De tekniska felen skiljer sig åt, men båda kan under vissa förutsättningar leda till allvarliga säkerhetsproblem.

Säkerhetshål	Vad går fel?
CVE-2026-109618	PHP kan hantera interna minnesuppgifter felaktigt när vissa operationer misslyckas.
CVE-2026-109619	Information från tidigare webbförfrågningar kan hanteras på ett osäkert sätt och påverka senare förfrågningar.

För att förstå varför detta är farligt behöver man veta lite om hur en webbserver fungerar.

När du besöker en webbplats skickar webbläsaren en förfrågan till servern. Servern behandlar den och skickar tillbaka ett svar, exempelvis en färdig webbsida.

Under processen använder programvaran arbetsminne för att hantera information.

Minnet måste användas på ett kontrollerat sätt. Programmet ska exempelvis inte läsa information som inte längre är giltig eller återanvända uppgifter på ett sätt som påverkar andra förfrågningar.

PHP2Shell innebär att vissa av dessa säkerhetsgränser kan kringgås.

Kan en angripare ta över hela servern?

I värsta fall kan säkerhetshålen utnyttjas för att köra skadlig kod på den angripna servern. Ett annat möjligt resultat är att angriparen får tillgång till information som finns i serverprocessens minne.

Men konsekvenserna beror på hur servern är uppbyggd.

Om PHP-processen har begränsade rättigheter kan det minska vad en angripare kommer åt. Om samma process däremot har omfattande åtkomst till filer, databaser och andra system kan intrånget bli betydligt allvarligare.

En framgångsrik attack betyder därför inte automatiskt att angriparen fått administratörsrättigheter över hela servern.

Det betyder inte heller att samtliga kunduppgifter har stulits.

Det avgörs av vad angriparen faktiskt har kunnat göra och vilka resurser den sårbara processen har tillgång till.

Måste angriparen känna till lösenordet?

Nej. En viktig anledning till den höga riskklassningen är att säkerhetshålen under vissa förutsättningar kan angripas utan att någon först behöver logga in.

Angriparen kan försöka utnyttja dem genom särskilt utformade webbförfrågningar till en sårbar server.

Det är en annan typ av angrepp än när någon försöker gissa ett WordPress-lösenord eller lura en användare att avslöja sina inloggningsuppgifter.

Starka lösenord och tvåfaktorsautentisering är fortfarande viktiga. De reparerar däremot inte dessa PHP-sårbarheter.

Vilka webbplatser och företag löper störst risk?

Det går inte att avgöra om en webbplats är sårbar enbart genom att se att den använder PHP.

Flera faktorer påverkar risken, bland annat PHP-versionen, serverns konfiguration och om tjänsten kan nås direkt från internet.

PHP-projektet har särskilt pekat ut servermiljöer som använder Apache tillsammans med mod_php som riskfyllda. Även andra sätt att köra PHP kan beröras.

För vanliga företag finns dessutom ett problem som lätt missas: PHP kan användas på betydligt fler ställen än den publika hemsidan.

Det kan exempelvis handla om:

• En äldre kundportal som fortfarande används.
• Ett internt bokningssystem.
• En webbapplikation som sköter beställningar.
• Ett API som kommunicerar med andra system.
• En testmiljö eller separat server som inte har uppdaterats på länge.

En organisation kan därför ha uppdaterat sin huvudsakliga webbplats men fortfarande ha en sårbar PHP-installation någon annanstans.

Egen server kräver en bredare kontroll

Företag som driver egna servrar behöver inventera var PHP faktiskt körs.

Det räcker inte alltid att kontrollera vilken version som är installerad som standard i operativsystemet. Olika webbplatser, containrar och applikationer kan använda separata PHP-installationer.

Efter att rättningarna installerats behöver serveransvariga även verifiera att de berörda tjänsterna verkligen kör den uppdaterade programvaran. I vissa miljöer kan tjänster eller processer behöva startas om.

För verksamheter med flera servrar är det därför viktigt att arbeta systematiskt, så att ingen äldre installation lämnas kvar av misstag.

Vad gör man om PHP inte kan uppdateras direkt?

I äldre system kan en omedelbar uppgradering vara svår.

Kanske bygger en affärskritisk applikation på PHP-kod som inte fungerar tillsammans med nyare versioner. Det kan också saknas tillräcklig dokumentation eller möjlighet att snabbt testa en förändring.

Det förändrar inte riskbilden.

PHP-projektet har beskrivit vissa tillfälliga åtgärder som kan begränsa möjligheterna att utnyttja säkerhetshålen. De handlar bland annat om hur PHP använder minne, sessionsfunktioner och filuppladdningar.

Sådana åtgärder kan minska exponeringen, men ska inte betraktas som en fullständig ersättning för en säkerhetsuppdatering.

Svenska CERT-SE rekommenderar att berörda system som inte kan uppdateras isoleras från publika nätverk när det behövs för att minska risken.

Det innebär i praktiken att en osäker tjänst kan behöva göras otillgänglig från internet tills problemet har åtgärdats.

För en e-handel eller kundportal kan det vara ett svårt beslut. Men konsekvenserna av ett intrång kan bli betydligt större än av ett planerat driftavbrott.

Räcker Cloudflare, en brandvägg eller ett säkerhetstillägg?

Cloudflare var snabbt ute med skyddsregler för PHP2Shell när sårbarheterna blev offentliga.

Företaget uppgav den 21 oktober att nya regler aktiverats automatiskt för kunder som använder dess webbapplikationsbrandvägg, WAF. Skyddet omfattade även kostnadsfria nivåer där funktionen var tillgänglig.

En sådan brandvägg granskar trafiken till webbplatsen och kan stoppa förfrågningar som liknar kända angrepp.

Det är ett värdefullt extra skydd, särskilt när angripare snabbt börjar utnyttja nyupptäckta säkerhetshål.

Men det finns en begränsning.

En brandvägg kan inte garantera att varje möjlig variant av ett angrepp stoppas. Den ändrar inte heller den sårbara koden i PHP.

Säkerhetsuppdateringen är därför fortfarande den viktigaste åtgärden.

Detsamma gäller säkerhetstillägg i WordPress. De kan bland annat hjälpa till att upptäcka misstänkt aktivitet, begränsa inloggningsförsök och kontrollera ändringar i webbplatsens filer.

Men ett WordPress-tillägg lagar inte automatiskt ett fel i serverns PHP-motor.

Det bästa skyddet bygger på flera delar som samverkar: uppdaterad programvara, begränsade serverbehörigheter, trafikskydd, övervakning och fungerande säkerhetskopior.

Hur vet man om webbplatsen redan har blivit hackad?

Det finns en viktig skillnad mellan att en webbplats har varit sårbar och att den faktiskt har utsatts för ett lyckat intrång.

En osäker PHP-version betyder att det kan finnas en möjlighet att angripa servern. Det betyder inte att någon har lyckats göra det.

Samtidigt kan det vara svårt att upptäcka ett intrång genom att bara besöka webbplatsen.

En angripare kan i vissa fall komma åt information eller placera skadliga filer utan att webbplatsens utseende förändras.

Det är därför teknisk undersökning kan behövas.

Tecken som bör undersökas

Exempel på omständigheter som kan motivera en närmare kontroll är:

• Oväntade ändringar i webbplatsens filer.
• Nya administratörskonton som ingen känner igen.
• Okända processer som körs på servern.
• Avvikande trafik eller ovanliga anrop i serverloggar.
• Säkerhetsvarningar från webbhotellet eller en övervakningstjänst.

Inget av dessa tecken bevisar ensamt att PHP2Shell har utnyttjats. De kan ha andra förklaringar.

För att bedöma om ett intrång inträffat behöver man undersöka den faktiska servermiljön och vad loggarna visar.

Det är också viktigt att bevara relevant information. Att radera misstänkta filer eller installera om delar av systemet utan att dokumentera vad som hänt kan försvåra utredningen.

Är problemet löst när PHP uppdaterats?

Inte nödvändigtvis.

Uppdateringen åtgärdar de kända säkerhetsbristerna, men den tar inte automatiskt bort skadliga filer eller obehöriga konton som eventuellt skapats före uppdateringen.

Om det finns konkreta misstankar om intrång behöver verksamheten därför både stänga säkerhetshålet och undersöka om något skadligt har lämnats kvar.

Om personuppgifter faktiskt har röjts kan reglerna om personuppgiftsincidenter enligt GDPR bli aktuella. Anmälningspliktiga incidenter ska som utgångspunkt rapporteras till Integritetsskyddsmyndigheten inom 72 timmar efter att verksamheten fått vetskap om dem.

För vanliga webbplatsägare är det klokt att ta hjälp av webbhotellet eller en säkerhetsspecialist om misstankarna är konkreta.

Därför har PHP2Shell blivit en internationell säkerhetskris

Bara ett dygn efter att säkerhetshålen blivit offentliga rapporterades en mycket kraftig ökning av angreppsförsök.

Enligt uppgifter från Cloudflare steg antalet registrerade försök från tusentals till miljontals på kort tid.

Samtidigt stängdes vissa digitala tjänster tillfälligt i bland annat Finland och Japan. Bland de berörda verksamheterna fanns offentliga tjänster och andra samhällsviktiga system.

Det betyder inte att alla dessa system blivit hackade.

I Finland betonade den statliga it-leverantören Valtori att nedstängningar genomfördes i förebyggande syfte och inte som en följd av något konstaterat intrång.

Skillnaden är viktig.

När en allvarlig sårbarhet upptäcks kan ett företag eller en myndighet behöva stänga en tjänst för att undvika risken för angrepp, även om ingen obehörig har fått tillgång till systemet.

Varför kommer angreppen så snabbt?

När information om en kritisk sårbarhet blir offentlig börjar säkerhetsföretag och systemadministratörer arbeta med att installera rättningar.

Men samma information kan också användas av angripare.

Automatiserade verktyg kan söka efter servrar med sårbara versioner och försöka utnyttja bristerna i stor skala.

Utvecklingen inom AI bidrar dessutom till att förändra hur både säkerhetsarbete och angrepp genomförs. AI-verktyg har bland annat använts av säkerhetsforskare vid analysen av PHP2Shell.

Det betyder däremot inte att de registrerade PHP2Shell-angreppen automatiskt ska beskrivas som AI-attacker.

Automatisering och AI kan användas på olika sätt, vilket också framgår av andra incidenter där AI-agenter har använts för att angripa webbplatser. Det rör sig dock om en annan typ av säkerhetsproblem än de aktuella PHP-sårbarheterna.

Den praktiska konsekvensen är att tiden mellan offentliggörandet av ett säkerhetshål och omfattande angreppsförsök kan bli mycket kort.

Behöver vanliga internetanvändare göra något?

PHP2Shell är i första hand ett problem för den som driver eller ansvarar för en webbplats, server eller webbtjänst.

Du behöver inte installera PHP på din mobil eller uppdatera din dator bara för att du besöker webbplatser som använder programmeringsspråket.

En vanlig besökare kan inte heller själv åtgärda en sårbar PHP-installation hos exempelvis en bank, nätbutik eller myndighet.

Om en tjänst du använder däremot bekräftar att den blivit utsatt för intrång behöver du följa informationen från den ansvariga organisationen.

Vilka åtgärder som är relevanta beror på vad som har hänt och om dina uppgifter har påverkats.

Ett lösenordsbyte kan vara viktigt vid ett konstaterat läckage av inloggningsuppgifter, men det finns ingen anledning att utgå från att alla som använt en PHP-baserad webbplats har fått sina lösenord stulna.

Vanliga frågor om PHP-säkerhetshålen

Är alla WordPress-webbplatser sårbara?

Nej. Att WordPress använder PHP betyder inte att varje WordPress-webbplats är sårbar. Den faktiska PHP-versionen, installerade säkerhetsrättningar och serverns konfiguration avgör om de aktuella bristerna kan utnyttjas.

Är PHP 8.2 fortfarande säkert?

PHP 8.2.35 innehåller rättningarna för PHP2Shell inom den versionsserien. Däremot upphör det officiella säkerhetsstödet för PHP 8.2 den 31 december 2026. Det är därför klokt att planera en övergång till en nyare version.

Kan jag skydda webbplatsen genom att byta lösenord?

Ett lösenordsbyte reparerar inte PHP2Shell. Sårbarheterna kan under vissa förutsättningar utnyttjas utan inloggning. Däremot kan lösenordsbyten och andra skyddsåtgärder behövas om ett faktiskt intrång har upptäckts.

Behöver jag uppdatera både WordPress och PHP?

Ja, båda behöver hållas säkra och uppdaterade. De är separata delar av webbplatsens teknik. Att uppdatera WordPress innebär inte att serverns PHP-version automatiskt ändras.

Vad händer om mitt webbhotell använder en äldre version?

Kontakta webbhotellet och fråga om de aktuella säkerhetsbristerna har åtgärdats. En äldre versionsbeteckning betyder inte alltid att säkerhetsrättningen saknas, eftersom leverantörer kan installera särskilda uppdateringar.

Hur vet jag om ett angreppsförsök har lyckats?

Det går normalt inte att avgöra enbart genom att titta på webbplatsen. Vid misstanke om intrång behöver serverloggar och annan teknisk information granskas. Ett registrerat eller blockerat angreppsförsök är inte detsamma som ett lyckat intrång.

Det viktigaste är att kontrollera servern – inte bara webbplatsen

PHP2Shell visar varför säkerheten på en webbplats inte enbart handlar om lösenord, tillägg och de funktioner som syns i administrationspanelen.

Även programvaran under webbplatsen behöver underhållas.

För den som använder WordPress är den första åtgärden enkel: kontrollera PHP-versionen under Webbplatshälsa och ta reda på om den aktuella säkerhetsrättningen finns installerad.

För företag med egna servrar krävs en bredare genomgång av vilka system som använder PHP och om samtliga berörda installationer verkligen har uppdaterats.

Det finns ingen anledning att utgå från att en webbplats har blivit hackad bara för att den tidigare använt en sårbar version. Men det finns heller ingen anledning att låta ett känt och allvarligt säkerhetshål stå öppet längre än nödvändigt.