PHP2Shell: Kritiska PHP-sårbarheter drabbar mod_php-servrar hårdast

PHP tidigarelade sin säkerhetsutgåva till onsdagen den 21 oktober kl. 14.00 UTC efter att detaljer om två sårbarheter läckt på Hacker News dagen innan. Korrigeringarna ingår i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Båda felen finns i själva tolken snarare än i ett CMS. PHP:s säkerhetsmeddelanden för CVE-2026-109618 och CVE-2026-109619 ger båda betyget 9,2 enligt CVSS 4.0 och bekräftar oautentiserad fjärrkörning av kod med webbserverns arbetsprocessbehörigheter.

Hanteringen av minnesbrist lämnar minnet delvis initierat

Den första sårbarheten handlar om hur PHP hanterar minnesbrist. Vid minnesbrist (OOM) använder tolken longjmp() för att lämna den aktuella kontexten, även när minnet för begäran bara är delvis initierat. Avslutningsrutinen läser sedan detta tillstånd som giltigt. En angripare kan framtvinga minnesbristen med en multipart-begäran som håller sig under post_max_size, exempelvis genom ett obegränsat antal huvuden per del, tomma filfält som inte räknas mot max_file_uploads eller nästlade fältnamn. Korrigeringen ersätter longjmp() med mjuk OOM-hantering vid nästa säkra punkt i den virtuella maskinen och ett hårt _exit() över en andra, högre tröskel.

Den andra sårbarheten rör globalt tillstånd som lever kvar efter en begäran. Om ett fatalt fel avbryter en operation innan den återställer sitt tillstånd fortsätter ett globalt fält att peka på frigjort heapminne. När nästa begäran i samma arbetsprocess läser värdet före den normala initieringen blir resultatet användning av frigjort minne (use-after-free). PHP anger två bekräftade vägar: inställningen fatal_error_backtraces i PHP 8.5 och spårning av sessionsuppladdningars förlopp, som är aktiverad som standard och inte kräver att applikationen anropar session_start().

Varför mod_php är mest utsatt

Apache med mod_php anropar avslutningsrutinen för begäran även när initieringen av begäran redan har misslyckats. Det räcker att minnet tar slut medan PHP tolkar begärans kropp, och ingen applikationskod behöver köras. PHP verifierade fullständig kodkörning mot mod_php med standardgränserna för minne och indata. PHP-FPM avslutar en underprocess vars initiering misslyckas, vilket blockerar den direkta angreppsvägen. För den andra sårbarheten bekräftade PHP ändå ett fungerande angrepp mot en vanlig FPM-pool, även om det förutsätter en lämplig operation i applikationen. Källkodsanalys tyder på att FrankenPHP beter sig som mod_php, medan LSAPI är en möjlig kandidat under vissa förutsättningar. Den höga angreppskomplexiteten i CVSS-vektorn återspeglar att PHP-bygget och heapens layout påverkar tillförlitligheten.

Angreppsförsök och AI:s roll

watchTowr uppger att företaget observerar aktiva försök att utnyttja båda sårbarheterna, och Cloudflare berättade för The Hacker News att företaget såg tidiga attacker innan korrigeringen släpptes. Inget lyckat intrång har hittills bekräftats. Nederländska myndighetstjänster, däribland DigiD och MijnOverheid, togs ändå offline som en försiktighetsåtgärd, och brittiska NCSC rekommenderar att system som inte har korrigerats tas offline om inget annat alternativ finns.

Wiz Research hittade felen och rapporterade dem den 24 augusti. Enligt Wiz hjälpte Gemini 4 Argon och GPT-5.6 Sol till med upptäckt, utveckling av angreppskod och verifiering av korrigeringar, särskilt med att anpassa angreppskoden till varje mål. Wiz lyfter även fram OpenAI och Calif för deras hjälp med upptäckt och samordning. Det ligger i linje med vad Anthropic nyligen skrev om självkopierande AI som riktar in sig på billiga TV-boxar, där modeller också sänker tröskeln för attacker.

Vad administratörer bör göra nu

En uppdatering är den enda fullständiga lösningen. Linuxdistributioner och LTS-leverantörer fick korrigeringarna i förväg och bakåtporterar dem ofta under äldre versionsnummer, så kontrollera ändringsloggen efter CVE-ID:na i stället för versionssträngen. Grenarna 7.4, 8.0 och 8.1, som inte längre stöds, får bara minimala bakåtporteringar av källkoden. Om du inte kan uppdatera direkt rekommenderar PHP att memory_limit=-1 ställs in på administrativ nivå, eftersom det är en förutsägbar gräns per begäran som får det bekräftade OOM-angreppet att fungera. Lägg till session.upload_progress.enabled=0 och, i PHP 8.5, fatal_error_backtraces=0, och starta sedan om alla arbetsprocesser. Om din applikation inte använder multipart-formulär bör du blockera dem i frontendlagret. Ingen av dessa inställningar är en fullständig lösning. Om du använder delat webbhotell eller en NAS med webbserver bör du kontrollera vilken PHP-version din leverantör tillhandahåller.