Senast uppdaterad 24 oktober 2026. Skriven av Joel Färnstrand, utvecklare och grundare av Vex Digitalt, teknikpartner för företag i Halland och Göteborgsområdet.
Den 20 oktober 2026 läckte detaljer om två kritiska säkerhetshål i PHP ut på sociala medier, två dagar innan de skulle ha offentliggjorts på ett kontrollerat sätt. Dagen efter, den 21 oktober, släppte PHP uppdateringar, och samma dag började säkerhetsföretag se de första attackförsöken mot riktiga servrar. Hålen har fått samlingsnamnet PHP2Shell.
Det här är inte ett problem bara för stora IT-avdelningar. PHP driver en mycket stor andel av alla hemsidor på nätet och ligger bakom bland annat WordPress, WooCommerce, Joomla och Drupal. Har ert företag en hemsida, en webbshop eller ett kundsystem är chansen stor att PHP finns någonstans i bilden.
Kort sagt: PHP2Shell är samlingsnamnet på sårbarheterna CVE-2026-109618 och CVE-2026-109619 i PHP. Alla PHP-installationer som serverar webbsidor och kör en äldre version än 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 räknas som sårbara. Det enda som helt stänger hålet är att uppdatera PHP och starta om alla PHP-processer. Inställningar och brandväggar kan minska risken under tiden, men ersätter inte uppdateringen.
Vill ni slippa gräva i serverinställningar själva? Jag har redan kontrollerat och åtgärdat PHP2Shell åt en kund och gör gärna samma kontroll åt er. Kontakta mig här så tittar jag på er hemsida. Vill ni hellre göra det själva, läs vidare.
Checklista: PHP2Shell i fem steg
- Ta reda på om er hemsida eller era system använder PHP.
- Kontrollera vilken PHP-version webbservern faktiskt kör.
- Uppdatera till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 (eller er distributions patchade paket) och starta om PHP.
- Kan ni inte uppdatera direkt: stäng av
session.upload_progress.enabledoch begränsapost_max_size. - Leta efter tecken på att någon redan tagit sig in.
Nedan går vi igenom varje steg.
Vad är PHP2Shell?
PHP2Shell består av två separata sårbarheter i själva programspråket PHP, CVE-2026-109618 och CVE-2026-109619. Båda har fått allvarlighetsgraden 9,2 av 10 (CVSS 4.0) och kan i värsta fall låta en angripare köra egen kod på er server, utan att behöva något lösenord eller konto. Det kallas remote code execution, och är bland det allvarligaste en sårbarhet kan leda till.
I praktiken betyder det att någon kan:
- Ta över hemsidan och ändra innehållet
- Komma åt databasen, med kunduppgifter, ordrar och inloggningar
- Använda er server för att sprida skadlig kod eller skicka spam
- Ta sig vidare till andra system som servern har åtkomst till
Det som gör hålet extra allvarligt är att attacken i vissa uppsättningar kan lyckas innan er egen kod ens körs. Det spelar alltså ingen roll hur välskriven er hemsida är, eller om alla WordPress-plugins är uppdaterade. Felet sitter i PHP, inte i er sida. Läcker kunduppgifter ut kan det dessutom bli en GDPR-incident som måste anmälas till IMY inom 72 timmar.
Är ert företag berört? Fyra frågor att ställa
1. Används PHP över huvud taget?
Kör ni WordPress, WooCommerce, Joomla, Drupal, Magento eller PrestaShop är svaret ja. Det gäller även många specialbyggda kundportaler, bokningssystem och intranät. Är ni osäkra, fråga den som byggt sidan eller er webbhotellsleverantör.
Är sidan byggd med till exempel Next.js, som ren statisk sida eller i en hemsidebyggare som Wix eller Squarespace körs den troligen inte på en PHP-server ni ansvarar för, men det kan finnas andra system i verksamheten som gör det.
2. Vilken PHP-version körs?
Det här är den viktigaste frågan. Följande versioner är säkra mot PHP2Shell:
| PHP-gren | Säker från version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1, 8.0, 7.4 | Ingen officiell version, endast patchar via distribution eller leverantör |
| 7.3 och äldre | Ingen fix, måste uppgraderas |
Så hittar ni versionen:
- Webbhotell (One.com, Loopia, Binero med flera): Logga in i kontrollpanelen och leta efter "PHP-version" eller "PHP-inställningar".
- WordPress: Gå till Verktyg → Webbplatsens hälsa → Info → Server. Där står PHP-versionen.
- Egen server: Lägg tillfälligt upp en fil med
<?php phpinfo();och öppna den i webbläsaren. Ta bort filen direkt efteråt, den visar mycket information om servern.
En vanlig fälla: kommandot php -v i terminalen visar versionen för kommandoraden, som inte alltid är samma PHP som faktiskt serverar hemsidan. Kontrollera alltid den version som webbservern använder.
3. Har er Linux-distribution redan patchat?
Kör ni en egen server med Ubuntu, Debian, Red Hat eller liknande kan versionsnumret se gammalt ut trots att säkerhetsfixen redan är inbyggd. Distributionerna fick tillgång till rättningarna innan de blev offentliga och lägger ofta in dem utan att ändra huvudversionen, så kallad backport. Kolla er distributions säkerhetsmeddelande för CVE-2026-109618 och CVE-2026-109619 i stället för att bara titta på siffran.
4. Hur körs PHP på servern?
Risken är högst om PHP körs som modul i Apache (mod_php). Där har angrepp visats fungera mot vanliga WordPress-, Drupal- och Joomla-installationer. Men även PHP-FPM, php-cgi, LiteSpeed och FrankenPHP är berörda, så det är ingen anledning att slappna av bara för att ni kör något av dem.
Känns det här som grekiska? Det är helt normalt, de flesta företagare har aldrig behövt fundera på hur deras server är uppsatt. Skicka ett meddelande med adressen till er hemsida så tar jag reda på det åt er.
Vad ni kan göra själva
Steg 1: Uppdatera PHP, den enda riktiga lösningen
PHP skriver själva att ingen inställning helt skyddar mot hålen. Uppdatering till en av versionerna i tabellen ovan är det som gäller.
- På webbhotell: Många leverantörer har redan uppdaterat. Kontrollera versionen enligt ovan. Står den fortfarande på en gammal version, byt i kontrollpanelen eller kontakta supporten och fråga rakt ut när de patchar för PHP2Shell.
- På egen server: Installera de uppdaterade paketen från er distribution och starta om alla PHP-processer (Apache eller PHP-FPM). En uppdatering som inte följs av omstart gör ingen nytta, de gamla processerna fortsätter köra den sårbara koden.
Glöm inte andra ställen där PHP kan gömma sig: testmiljöer, gamla kampanjsidor, Docker-containrar och interna verktyg. Angripare skannar hela internet, inte bara er huvudsida.
Testa också hemsidan efter uppdateringen. Särskilt äldre WordPress-teman och plugins kan sluta fungera när PHP uppgraderas en hel version, och det är bättre att upptäcka det själv än att en kund gör det.
Steg 2: Minska risken tills uppdateringen är på plats
Kan ni inte uppdatera direkt finns några inställningar som gör angreppen svårare. De görs i php.ini eller i serverns konfiguration, inte via .htaccess eller .user.ini:
- Stäng av uppladdningsförlopp för sessioner:
session.upload_progress.enabled = Off. Det är den viktigaste tillfälliga åtgärden mot CVE-2026-109619, och skyddar även mot ett närliggande fel (CVE-2026-115560) som inte täcks av uppdateringarna från 21 oktober. - Begränsa storleken på inkommande data: sätt
post_max_sizetill8Mom sidan inte tar emot filuppladdningar, eller32Mom den gör det. - Dölj PHP-versionen:
expose_php = Off, så att angripare inte direkt ser att ni kör en sårbar version. - Kör ni PHP 8.5: sätt även
fatal_error_backtraces = 0.
Starta om PHP efter varje ändring. Har ni en brandvägg för webbtrafik (WAF), till exempel via Cloudflare, kan den fånga en del attackförsök, men angripare har redan setts försöka ta sig runt sådana skydd. Se det som ett extra lager, inte som ett skydd i sig.
Om ett system inte går att uppdatera alls, överväg att tillfälligt stänga det för allmänheten, till exempel bakom inloggning eller IP-begränsning, tills det är åtgärdat.
Steg 3: Kontrollera att ingen redan varit inne
Hittills finns inga bekräftade rapporter om lyckade intrång i stor skala, men attackförsöken pågår och de första försöken loggades redan innan uppdateringarna släpptes. Har ni haft en sårbar version publik sedan mitten av oktober är det klokt att leta efter tecken på intrång:
- Okända filer i webbkatalogen, särskilt nya
.php-filer eller filer med namn somMARKER_följt av en slumpmässig kod - Nya administratörskonton i WordPress eller andra system som ingen känner igen
- Ovanliga POST-anrop i serverloggarna som innehåller
PHP_SESSION_UPLOAD_PROGRESS - Plötsligt ökad belastning eller utgående trafik från servern
Hittar ni något misstänkt: byt alla lösenord, inklusive databas och FTP, och ta hjälp av någon som kan gå igenom servern ordentligt. Att bara ta bort en misstänkt fil räcker sällan.
Det här kommer hända igen
PHP2Shell är inte det första stora säkerhetshålet och blir inte det sista. Det som skiljer företag som klarar sig från dem som drabbas är sällan tekniken, utan om någon faktiskt har koll på vilka system som finns, vilka versioner de kör och vem som ansvarar för att uppdatera dem. Jag har skrivit mer om varför underhåll ofta avgör säkerheten i min jämförelse mellan WordPress och skräddarsydda hemsidor.
Har ni äldre system som är svåra eller riskabla att uppdatera är det ofta ett tecken på att det är dags att se över dem. Det är precis den typen av arbete vi gör inom systemmodernisering, och som lokal teknikpartner i Halland hjälper vi företag att få ordning på sina system så att nästa säkerhetshål blir en rutinuppdatering i stället för en kris.
Vanliga frågor om PHP2Shell
Vad är PHP2Shell?
PHP2Shell är samlingsnamnet på två kritiska sårbarheter i PHP, CVE-2026-109618 och CVE-2026-109619, som offentliggjordes i oktober 2026. De kan låta en angripare köra egen kod på en webbserver utan att logga in.
Vilka PHP-versioner är säkra mot PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35 eller senare inom respektive gren. Linuxdistributioner kan också ha patchade paket med äldre versionsnummer. PHP 7.3 och äldre får ingen fix.
Är WordPress-sidor drabbade av PHP2Shell?
Ja, om de körs på en sårbar PHP-version. Felet sitter i PHP och inte i WordPress, så det hjälper inte att bara uppdatera WordPress och plugins. Det är PHP-versionen hos webbhotellet eller servern som måste uppdateras.
Hur vet jag om min hemsida är sårbar för PHP2Shell?
Kontrollera vilken PHP-version som webbservern kör, via webbhotellets kontrollpanel, WordPress Webbplatsens hälsa eller en tillfällig phpinfo()-fil. Är versionen äldre än de säkra versionerna och inte patchad av er leverantör är sidan sårbar.
Räcker det att ändra inställningar i stället för att uppdatera?
Nej. PHP skriver själva att ingen konfiguration helt skyddar mot PHP2Shell. Inställningar som session.upload_progress.enabled = Off minskar risken tillfälligt, men uppdatering och omstart är den enda fullständiga lösningen.
Kan någon hjälpa mitt företag att kontrollera och åtgärda PHP2Shell?
Ja. Vex Digitalt hjälper företag att kontrollera om de är berörda, uppdatera PHP, testa att hemsidan fungerar efteråt och leta efter tecken på intrång. Kontakta oss här.
Vill ni att jag kollar åt er?
Att gå igenom servrar, PHP-versioner och loggar går ganska snabbt för någon som gjort det förut, men kan vara både krångligt och nervöst om man inte gör det varje dag. Jag har redan hjälpt en kund att kontrollera och täppa till PHP2Shell, och gör gärna samma sak för er:
- Jag tar reda på om er hemsida och era system är berörda
- Uppdaterar PHP, eller ser till att er leverantör gör det
- Testar att sidan fungerar som den ska efteråt
- Går igenom loggar och filer efter tecken på intrång
Ni pratar direkt med mig som gör jobbet, utan mellanhänder. Hör av er via kontaktformuläret med adressen till er hemsida, så återkommer jag snabbt.
Källor
- PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Critical PHP RCE Flaws, Affected Versions, and How to Fix Them, SOCRadar
- PHP2Shell: Find, Mitigate, and Patch Now, Qualys
- PHP2Shell FAQ: CVE-2026-109618 & CVE-2026-109619 Fixes, watchTowr
- PHP2Shell: Critical PHP vulnerabilities patched, update now!, Help Net Security
Relaterade artiklar
- WordPress vs skräddarsydd hemsida: vad passar ditt företag?
- AI-integration, automatisering och systemmodernisering: så får svenska småföretag mer ut av sin teknik 2026
- GDPR och AI: Det du behöver göra innan du integrerar AI i din verksamhet
- Anlita webbutvecklare i Halland: vad du bör veta innan du väljer