Kort sagt: CVE-2026-109618 är en av de två sårbarheterna bakom PHP2Shell. Ett out-of-memory-tillstånd kan avbryta PHP medan förfrågningsdata bara är delvis initierade; vid städningen kan ogiltiga data då räknas som giltiga. Det möjliggör kodkörning utan inloggning. Felet är åtgärdat i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35.
Vad är CVE-2026-109618?
CVE-2026-109618 (GitHub-beteckning GHSA-w8hw-w9fx-j79w) är en minnesfelssårbarhet i kärnan av PHP. Den är bedömd med CVSS v4.0 9,2. Tillsammans med CVE-2026-109619 bildar den det som i medierna kallas PHP2Shell.
Verkan är en så kallad unauthenticated Remote Code Execution: En angripare kan på distans och utan användarkonto köra kod på webbservern. Därmed hör sårbarheten till den farligaste klassen av svagheter som en webbserver kan ha.
Hur sårbarheten uppstår i princip
När PHP bearbetar en webbförfrågan skapar det internt datastrukturer för den förfrågan, till exempel för inskickade formulärdata. Når PHP därvid sin minnesgräns avbryts det med ett out-of-memory-tillstånd. Enligt php.net kan det ske medan förfrågningsdata bara är delvis initierade.
I slutet av varje förfrågan städar PHP upp och frigör minnet. Just där ligger felet: Städningen kan behandla ogiltiga, bara halvt skapade data som giltiga. Ur detta felbeteende går det under vissa förutsättningar att härleda kodkörning.
Varför är ett sådant fel så allvarligt? Ett minnesfel i programmeringsspråket berör alla applikationer som körs på det, oavsett hur noggrant de är programmerade. En välskött WordPress-installation med aktuella plugins är lika berörd som en gammal egenutveckling. Därför hjälper ingen uppdatering av applikationen här, utan bara en uppdatering av PHP.
Ytterligare tekniska detaljer om utnyttjandet publicerar vi medvetet inte. För försvaret behövs de inte: Avgörande är om er server använder en åtgärdad version och om de nya processerna faktiskt körs.
Berörda versioner och driftlägen
| PHP-gren | Sista version före rättningen | Åtgärdad från |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 och äldre | ingen officiell uppdatering | bara minimala backports i källkoden för 7.4, 8.0, 8.1 |
Berörda är driftlägena PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. PHP-teamet bedömer risken som högst vid mod_php. Distributioner och webbhotell levererar ibland backports, så att ett äldre versionsnummer visas fast felet är åtgärdat. Avgörande är paketstatus och leverantörens bekräftelse.
Om storleksordningen: Palo Alto Networks (Unit 42) räknade mer än 22,6 miljoner exponerade, potentiellt sårbara instanser. BSI (Tysklands federala myndighet för informationssäkerhet) har utlyst varningsnivå 3 (orange) och räknade med snabbt utnyttjande i stor skala.
Åtgärda CVE-2026-109618: uppdatering och omstart
Den enda fullständiga åtgärden är uppdateringen. Kontrollera först version och paketstatus. Paketnamn skiljer sig mellan distributioner; exemplen utgår från PHP 8.3:
php -v
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
Nämner paketets changelog CVE-numret är backporten installerad. Saknas det betyder det inte automatiskt att paketet är sårbart; då hjälper jämförelsen med versionstabellen eller en förfrågan hos leverantören.
Efter uppdateringen måste alla PHP-processer startas om, till exempel med systemctl restart php8.3-fpm eller vid mod_php med en omstart av Apache. Hur ni säkerställer att ingen gammal worker längre körs står under Starta om PHP-FPM och alla workers.
Övergångsåtgärder om uppdateringen ännu inte går
php.net har publicerat övergångsåtgärder för PHP2Shell. De gäller för båda sårbarheterna gemensamt och är uttryckligen inget fullständigt skydd. Att flera av dem avser minnesgränser passar med out-of-memory-utlösaren för CVE-2026-109618; någon officiell koppling av enskilda åtgärder till enskilda CVE:er finns dock inte.
; exempel på FPM-pool, t.ex. /etc/php/8.3/fpm/pool.d/www.conf (sökvägen skiljer sig mellan distributioner)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M, om uppladdningar behövs
php_admin_value[upload_max_filesize] = 6M ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
Värdena måste sättas så att applikationer inte kan skriva över dem, därför php_admin_value. Med memory_limit=-1 behöver tjänsten en minnesgräns utifrån, via container eller cgroup, inte via RLIMIT_AS eller RLIMIT_DATA. På PHP 8.5 tillkommer fatal_error_backtraces=0. Alla detaljer står under Akutåtgärder om ni ännu inte kan patcha.
Om varken uppdatering eller övergångsåtgärder är möjliga genast rekommenderar BSI att tillfälligt ta berörda webbservrar från nätet.
Hur hjälper PHP SOS konkret?
Via vår PHP-patchtjänst stänger vi CVE-2026-109618 strukturerat:
- Kartlägga nuläget: PHP-gren, driftläge, paketkälla och backportstatus per server.
- Installera uppdateringen från rätt paketkälla eller, där det inte går, sätta in övergångsåtgärderna rent i pool- eller serverkonfigurationen.
- Kontrollera omstarten: Vi kontrollerar att inga gamla PHP-processer längre körs.
- Intyg: Ni får en dokumentation med versioner och paketstatus före och efter ingreppet, till exempel för ledning, försäkringsgivare eller dataskydd.
Vanliga frågor
Hur kritisk är CVE-2026-109618?
Sårbarheten är bedömd med CVSS v4.0 9,2 och därmed kritisk. Den möjliggör körning av skadlig kod på distans utan inloggning. BSI har utlyst varningsnivå 3 (orange) för PHP2Shell.
Räcker det att höja memory_limit?
Nej. php.net anger memory_limit=-1, fast inställt i serverkonfigurationen, som en av flera övergångsåtgärder. Den är uttryckligen inget fullständigt skydd och kräver en minnesgräns via container eller cgroup. Lösningen förblir uppdateringen.
Vilken GHSA-beteckning hör till CVE-2026-109618?
I GitHub Security Advisory förs sårbarheten under GHSA-w8hw-w9fx-j79w. Den andra PHP2Shell-sårbarheten, CVE-2026-109619, har beteckningen GHSA-6wmf-4rv5-p3rp.