Två kritiska säkerhetshål i PHP: vad som hänt och vilka som är i fara

En ny PHP-sårbarhet kan låta främlingar köra kod på din server

Om din sajt körs på PHP kan en främling över internet i värsta fall få servern att köra egen kod, utan att logga in och utan att något plugin är felkonfigurerat. Det är kärnan i två kritiska säkerhetshål som PHP rättade den 21 oktober 2026. Felen sitter i PHP självt, alltså i motorn som kör sajten, och inte i ditt tema eller dina tillägg.

Det här inlägget handlar om felen i sig: vad som går fel inne i PHP, varför det bedöms som så allvarligt, vilka sajter som berörs och vad det innebär för ett företag med en WordPress- eller PHP-sajt. Vi bygger våra egna och många kunders webbplatser på Cloudflare utan PHP på servern, så de berörs inte. Men en stor del av webben gör det, och då är frågan värd att ställa i dag.

Bakgrund: vad PHP är och varför en läcka förde fram släppet

PHP körs under WordPress, Drupal, Magento, Joomla och Laravel

PHP är programmeringsspråket och motorn som kör serversidan på en stor del av webben. När någon öppnar en sida på en WordPress-sajt är det PHP på servern som bygger sidan innan den skickas till besökaren. Enligt Patchstack är WordPress, Drupal, Magento, Joomla, Laravel och andra PHP-applikationer utsatta om de körs på en sårbar PHP-version. WooCommerce ligger ovanpå WordPress och delar därför samma grund.

Det är viktigt att förstå att PHP inte är en del av sajtens egen kod. Det kommer från serverpaketet, hostingleverantören eller containerbilden som sajten körs i.

Läckan, förhandsbeskedet och släppet den 21 oktober

Enligt Rescana läckte detaljerna den 20 oktober, en dag före den planerade publiceringen den 22 oktober. PHP gick då ut med ett förhandsbesked, och CERT-EU publicerade samma dag sin varning 2026-018. Cloudflare bekräftar att sårbarheterna läckte före släppet och att de sett riktiga attacker. Klockan 05:02 svensk tid den 21 oktober lade Cloudflare automatiskt ut 14 nya regler i sin brandvägg (WAF), på alla planer, även gratisplanen. Det var flera timmar före släppet klockan 14:00 UTC, alltså 16:00 svensk sommartid.

PHP släppte rättningarna den 21 oktober i versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. PHP:s egen varning säger att felen kan ge oautentiserad fjärrkörning av kod (RCE) och att man ska uppdatera direkt.

Vad som går fel inne i PHP

Två minnesfel i PHP:s motor, förklarade utan jargong

Det rör sig om två sårbarheter, CVE-2026-109618 och CVE-2026-109619, som i media går under namnet PHP2Shell. Båda är minnesfel av typen use-after-free. Förenklat betyder det att servern läser i ett minne som redan är återlämnat, och om en angripare kan påverka vad som hamnat där kan hen styra vad PHP gör härnäst.

Enligt PHP:s egna advisories, så som Patchstack refererar dem, ser de två felen ut så här:

• CVE-2026-109618: PHP kan avbrytas av slut på minne medan intern förfrågningsdata bara är delvis klar. Städningen efteråt kan då behandla trasig data som giltig.
• CVE-2026-109619: Intern data från en förfrågan lever kvar efter att minnet frigjorts. En senare förfrågan i samma arbetsprocess kan då använda den gamla datan.

Cloudflare beskriver felen på samma sätt. Källorna är däremot inte helt överens om den exakta tekniska orsaken. Sansec beskriver det första felet som ett fel i hanteringen av uppladdningsförlopp (upload-progress) och det andra som ett fel i felbacktrace och OPcache. Vi håller oss här till PHP:s egen beskrivning, och detaljerna kan komma att förtydligas.

Oautentiserad fjärrkörning: varför ingen inloggning behövs

Oautentiserad RCE betyder att en angripare som kan nå sajten över internet kan få servern att köra egen kod utan att logga in. Koden körs med samma rättigheter som PHP-processen. CERT-EU skriver att betyget 9,2 pekar på just den risken. Cloudflare nämner också överbelastning och att data kan läcka ut som möjliga följder.

Patchstack skriver att PHP bedömer risken som störst för mod_php. Där kan en oautentiserad förfrågan utlösa attacken innan någon applikationskod hunnit köras.

Om felet slår till innan WordPress har hunnit göra något hjälper varken inloggningsskydd eller säkerhetsinställningar inne i WordPress.

Vad CVSS 9,2 betyder och vad vi ännu inte vet

CVSS är en skala upp till 10 för hur allvarlig en sårbarhet är, och allt över 9 räknas som kritiskt. Båda felen har fått 9,2, och siffran gäller CVSS version 4.0. Du kan se andra siffror i debatten, men PHP:s officiella betyg är 9,2.

Vad vi inte vet lika säkert är hur utbrett utnyttjandet är. Cloudflares teknikchef beskrev enligt Insurance Journal attackerna som ett stopgap-läge och sa att man ska patcha så fort PHP släpper uppdateringen. Patchstacks telemetri visade strax efter släppet bara sondering utan hårda belägg för intrång, men de räknar med att det ändras när detaljerna blir kända. Rescana kunde inte bekräfta utnyttjande i det vilda, och ingen av sårbarheterna fanns i CISA:s KEV-katalog vid deras uppdatering. Rätt formulering i dag är alltså att tidiga attacker har rapporterats, inte att sajter hackas i stor skala.

Vilka sajter berörs

Det spelar ingen roll vilka plugins du har

Felen sitter i PHP, så det avgörande är vilken PHP-version och vilken körmiljö din sajt använder, inte vilka plugins eller teman du har installerat. Enligt Laravel News gäller det varje PHP-installation som hanterar webbförfrågningar: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Laravel News skriver också att PHP-teamet säger att det inte finns några fullständiga skyddsåtgärder.

Säkerhetsföretaget Wiz Research säger sig ha visat oautentiserad RCE mot WordPress, Drupal och Joomla, och Sansec skriver att forskare bekräftat det mot Magento 2.4.9 och tio andra PHP-applikationer. Observera att både Wiz och Sansec är säkerhetsföretag, inte PHP-projektet självt. Wiz hävdar dessutom att felen påverkar "70 procent av internet", men det är företagets egen siffra i en rubrik och inget vi kan intyga.

PHP 8.2 till 8.5 kan patchas, PHP 8.1 och äldre får ingen officiell rättning

PHP-projektet rättar bara de fyra stödda grenarna, 8.2 till 8.5. Bara för dessa är det bekräftat att de är påverkade och att rättning finns. CERT-EU skrev före släppet att alla versioner från PHP 5 och uppåt kan vara påverkade, och Sansec, Wiz och Cloudflare anger PHP 5.4 och senare. Det omfånget är inte bekräftat av PHP, men äldre versioner är sannolikt drabbade.

PHP 8.1 och äldre är sedan tidigare utan support och får ingen officiell rättning. Laravel News skriver att PHP ändå publicerat minimala källkodsbackportar för PHP 7.4, 8.0 och 8.1 till den som bygger själv utan en LTS-leverantör. Enligt uppgift har också Ondřej Surýs paketkälla, som många Debian- och Ubuntu-servrar hämtar PHP från, släppt rättade paket ända tillbaka till PHP 5.6. För ett företag betyder det i praktiken att sajten behöver flyttas till en stödd version, eller att hostingleverantören måste backporta fixen. Vissa distributioner och LTS-leverantörer gör just det, så versionsnumret ensamt räcker inte alltid som besked.

Vad det betyder för ett företag med WordPress eller PHP-sajt

Så kollar du vilken PHP-version din sajt kör

I WordPress hittar du versionen under Verktyg, Webbplatsstatus, Info, Server. Skriv ner den och fråga sedan ditt webbhotell när PHP patchas för CVE-2026-109618 och CVE-2026-109619. Kör sajten PHP 8.1 eller äldre ska den flyttas till 8.2 eller nyare, och enligt Moatline går det ofta att byta per domän i hostingpanelen, till exempel cPanel.

Innan du byter version bör du ta backup av filer och databas och testa på en staging-kopia. Äldre plugins och teman kan gå sönder på nyare PHP, enligt Unlimited Web Hosting. Klicka igenom viktiga sidor, formulär och kassa efteråt.

Vem ansvarar för vad: hosting, byrå och du

Att uppdatera WordPress, plugins eller en webbapplikation uppdaterar inte PHP under den. Därför kan en webbyrå som äger din WordPress-sajt inte laga det här i sajtens kod. Det måste göras på serversidan, enligt The Hacker News.

Ansvaret fördelar sig ungefär så här:

• Delad hosting: Leverantören patchar ofta PHP, men du måste själv se till att sajten körs på en stödd version. Vissa leverantörer patchar bara de nyaste versionerna.
• Egen VPS: Du eller din byrå måste installera uppdateringen och starta om PHP-FPM eller webbservern.
• Byrån: Kan hjälpa till med test, versionsbyte och kontroll av att sajten fungerar efteråt, men inte rätta felet i sajtens kod.

CERT-EU rekommenderar att organisationer identifierar sina PHP-baserade applikationer och patchar direkt. Om det inte går bör man överväga att isolera internetexponerade applikationer från publika nätverk tills en fix finns, och Insurance Journal beskriver det som att sajter kan behöva tas offline.

Går sajten via Cloudflare har du ett extra skydd under tiden

Går trafiken till din sajt via Cloudflare stoppar deras nya brandväggsregler de kända attackerna redan nu, även på gratisplanen. Det köper tid tills PHP är uppdaterat. Två saker gäller ändå. Skyddet fungerar bara om all trafik verkligen går via Cloudflare, och servern inte kan nås direkt förbi. Och Cloudflare skriver själva att man ska patcha PHP även med deras regler på plats. Brandväggen är ett extra lager, inte en lösning.

Vanliga misstag: tillfälliga inställningar, brandväggar och antagandet att hostingen fixar allt

Att tro att en tillfällig inställning räcker. Förslag som att stänga av session.upload_progress eller blockera filuppladdningar har cirkulerat. PHP-kärnutvecklaren Gina Peter Banyard säger att den enda åtgärden är att patcha eller uppgradera PHP. Inställningen kan dessutom bara stoppa ena felet, och att blockera uppladdningar kan slå ut kontaktformulär och kassor. Laravel News skriver att PHP:s lista över inställningar minskar exponeringen men inte gör installationen säker.

Att lita på en brandvägg eller ett säkerhetsplugin. En WAF som Cloudflares stoppar kända attackmönster och är värd att ha, men den lagar inte sårbarheten i själva PHP-tolken. Nya varianter av attacken kan ta sig förbi, och en WAF hjälper inte om servern kan nås direkt. Ett säkerhetsplugin i WordPress hjälper inte alls, eftersom felet kan slå till innan WordPress körs.

Att anta att hostingen sköter det. Se ansvarsfördelningen ovan: på delad hosting måste du ändå kontrollera versionen, och på VPS är det ditt eget jobb.

Om det värsta ändå händer innebär en lyckad attack kodkörning på servern. Då är det klokt att se över segmentering mellan sajter, filrättigheter, hemligheter och loggning, till exempel separata PHP-FPM-pooler och tjänstekonton per applikation, begränsade skrivrättigheter i applikationskataloger och central loggning. CERT-EU, NCSC och PHP hade vid Rescanas uppdatering inte publicerat några kompromissindikatorer (IoC), så det går ännu inte att bekräfta att en sajt är "ren" på det sättet.

Sammanfattning: det här ska du göra idag

1. Ta reda på vilken PHP-version din sajt kör. I WordPress: Verktyg, Webbplatsstatus, Info, Server.
2. Fråga ditt webbhotell när PHP patchas för CVE-2026-109618 och CVE-2026-109619, och be om svar i klartext.
3. Kör sajten PHP 8.1 eller äldre: planera ett byte till 8.2 eller nyare, eller kräv att leverantören backportar fixen.
4. Ta backup och testa på en staging-kopia innan du byter version. Klicka igenom sidor, formulär och kassa efteråt.
5. Går sajten via Cloudflare har du ett extra skydd medan du väntar, men patcha ändå. Lita inte på tillfälliga inställningar, brandväggar eller säkerhetsplugin som enda skydd.
6. Har du en egen VPS: installera uppdateringen och starta om PHP-FPM eller webbservern.

Avslutning: PHP är under din sajt, så fråga om det

PHP syns aldrig i din dagliga administration, men det är grunden som allt annat står på, och nu är grunden det som behöver lagas. Är du osäker på vad din sajt kör eller vad som behöver göras, hör av dig till oss så hjälper vi dig att reda ut det.