← Alla nyheter
ARTIKEL
Rykten
23 oktober 2026 3 min läsning
Producerad av Neska

PHP2Shell-sårbarheten: uppdatera PHP i dag, båda RCE-felen utnyttjas redan

Två kritiska PHP-fel, CVE-2026-109618 och CVE-2026-109619, ger kodkörning utan inloggning och utnyttjas redan. Rättade versioner kom den 21 oktober.

I den här artikeln
  1. Vad som är bekräftat
  2. PHP2Shell-sårbarheten: vilka PHP-versioner som är säkra
  3. Vad som sägs
  4. Varför det spelar roll
  5. Det här gör du i dag

PHP2Shell-sårbarheten är i själva verket två kritiska fel i programspråket PHP, CVE-2026-109618 och CVE-2026-109619, som låter en angripare utan inloggningsuppgifter köra kod på en webbserver. PHP-projektet släppte rättade versioner den 21 oktober 2026, och de första attackerna sågs samma dag. Kör någon av dina servrar, eller en kunds, PHP: uppdatera i dag.

En stor serverhall sedd uppifrån, med rader av serverrack och skyltar för e-postservrar och webbservrar.
Foto: Florian Hirzinger - www.fh-ap.com (CC BY-SA 3.0), Wikimedia Commons.

Vad som är bekräftat

PHP-projektet fick de första rapporterna den 11 augusti 2026. Amazon Threat Intelligence rapporterade ett utnyttjandeförsök den 17 oktober, före den offentliga publiceringen. Den 20 oktober läckte detaljerna ut på nätet före det överenskomna datumet, och PHP tidigarelade nödsläppet till den 21 oktober. Samma dag såg watchTowr aktivt utnyttjande i sitt nätverk av honeypots.

CVE-2026-109618 finns i hanteringen av minnesbrist (out-of-memory): om PHP får slut på minne medan förfrågningsdatan sätts upp lämnas datan delvis initierad, och den avslutande städningen behandlar den som giltig. CVE-2026-109619 är ett fel där gammalt globalt tillstånd blir kvar, vilket leder till use-after-free på heapen, med minnesläckage och kodkörning. Båda möjliggör fjärrkodkörning utan autentisering, med webbserverkontots behörigheter. Säkerhetsleverantörernas rådgivningar ger dem 9,2 enligt CVSS v4.0.

Varje PHP-installation som hanterar webbförfrågningar berörs: Apache med mod_php, PHP-FPM, php-cgi, LiteSpeed och FrankenPHP. PHP-projektet bedömer risken som störst för mod_php, eftersom attacken kan lyckas innan någon applikationskod körs. Av samma skäl kanske en brandvägg för webbapplikationer eller en RASP-agent inuti PHP-processen inte stoppar den.

PHP2Shell-sårbarheten: vilka PHP-versioner som är säkra

  • PHP 8.5: uppdatera till 8.5.12.
  • PHP 8.4: uppdatera till 8.4.27.
  • PHP 8.3: uppdatera till 8.3.36.
  • PHP 8.2: uppdatera till 8.2.35.
  • PHP 8.1, 8.0 och 7.4: ingen officiell version. Minimala backports finns bara som källkod, eller som paket från distributioner och LTS-leverantörer.
  • PHP 7.3 och äldre, inklusive PHP 5: ingen rättning, du måste gå över till en gren som fortfarande stöds.

Linuxdistributioner rättar ofta ett fel utan att ändra versionsnumret: kontrollera paketets changelog, inte bara utdata från php -v.

Rykte

Vad som sägs

Källorna är oeniga om exploatens status. Vissa forskare säger att de två felen redan är kedjade i ett enda fungerande skript och att analyser och ett verktyg är offentliga. Huntress skrev att de inte har reproducerat något proof of concept, och JFrog varnade för att falska exploits cirkulerar. Den som laddar ner en påstådd PHP2Shell-exploit från ett forum riskerar att installera skadlig kod.

Den 22 oktober fanns felen inte i CISA:s KEV-katalog, enligt watchTowr. Storbritanniens nationella cybersäkerhetscentrum (NCSC) uppmanade organisationer att uppdatera omedelbart eller ta exponerade system offline. VirusTotal uppskattar att över 5,1 miljoner PHP-värdar går att nå från internet.

Varför det spelar roll

Om du sköter IT åt ett litet eller medelstort företag eller åt flera kunder finns PHP inte bara i de webbplatser du byggt själv. Det finns i WordPress, Joomla, Magento, PrestaShop, webbmejl, gamla affärssystem och i varje container vars basavbild innehåller PHP. En container behåller den PHP-version den byggdes med: du måste bygga om, eller hämta en rättad avbild, och göra en ny deploy.

Det här gör du i dag

  1. Gör en inventering: php -v på varje värd och docker exec <container> php -v på varje container som kör PHP.
  2. Uppdatera till den rättade versionen, eller till leverantörens rättade paket, och starta sedan om PHP-FPM eller Apache.
  3. Om du inte kan uppdatera direkt, ta bort systemet från direkt internetåtkomst.
  4. Som nödlösningar som inte skyddar fullt ut: session.upload_progress.enabled=0 och omstart av workers, ett lågt post_max_size (8M, eller 32M om du behöver uppladdningar) och minnesgränser på containernivå.
  5. Gå igenom åtkomstloggarna från den 17 oktober och, om du misstänker att processminne har lästs, byt lösenord, tokens och API-nycklar.

PHP-projektet är tydligt med att ingen konfiguration helt avhjälper felen och att uppdatering är det enda varaktiga skyddet. Vill du ha hjälp att sätta prioriteringar och rätta snabbt, se våra cybersäkerhetstjänster.

Källor: watchTowr, vanliga frågor om PHP2Shell; BleepingComputer; Qualys; JFrog; Huntress.

← ← Alla nyheter