Två kritiska sårbarheter i PHP kan möjliggöra kodkörning utan autentisering, och Amazon säger att företaget upptäckte ett misstänkt exploitförsök fyra dagar innan sårbarheterna offentliggjordes.
Så utsätter sårbarheterna servrar för risk
Sårbarheterna, CVE-2026-109618 och CVE-2026-109619, kallas gemensamt PHP2Shell och påverkar PHP:s centrala körmiljö. Den ena innebär att en förfrågan får slut på minne medan PHP konfigurerar interna data. Rensningen kan då hantera dessa data felaktigt. Den andra kan lämna kvar ett föråldrat internt tillstånd som pekar på minne som redan har frigjorts, vilket en senare förfrågan som hanteras av samma workerprocess kan använda.
PHP pekar ut Apache med mod_php som den mest riskfyllda konfigurationen, eftersom en förfrågan utan autentisering kan utlösa ett angrepp innan applikationskoden körs. Forskare har också demonstrerat kodkörning via applikationsvägar med PHP-FPM. PHP säger att alla installationer som hanterar webbförfrågningar är utsatta, däribland PHP-FPM, Apache mod_php, php-cgi, FrankenPHP och LiteSpeed.
Vad behöver uppdateras?
Det räcker inte att ändra webbplatsens applikation eller innehållshanteringssystem: sårbarheterna finns i själva PHP, under program som WordPress och Drupal. De åtgärdade versionerna är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. PHP stöder inte längre version 8.1 och äldre, så organisationer som använder dessa versioner behöver kontrollera om deras operativsystemsleverantör eller leverantör av långtidssupport har en bakåtporterad korrigering, eller uppgradera till en version som fortfarande stöds.
Cloudflare uppskattar att PHP används på nästan 70 procent av webbplatserna. Det är en uppskattning av hur utbrett språket är, inte av hur många system som är sårbara eller har utsatts för intrång. Ett lyckat angrepp kan ge en angripare webbserverns behörigheter, med möjlighet att stjäla data, störa tjänster eller använda servern för att ta sig vidare i nätverket.
Varför det tog tid att ta fram korrigeringarna
PHP Foundation säger att tecken på problemet med minnesbrist framkom under en extern säkerhetsgranskning 2024, men att man då inte hade hittat någon konkret angreppsväg. Ändringar i den centrala minneshanteringen kan medföra risker: de ansvariga utvecklarna sade att tänkbara lösningar kunde försämra kompatibiliteten, sänka prestandan eller kräva ändringar i PHP:s omfattande ekosystem av tillägg. OpenAI säger att företaget använde sin GPT-5.6 Sol-modell, Calif, för att hjälpa till att hitta en kritisk sårbarhet, medan Wiz oberoende upptäckte och rapporterade båda. PHP:s utvecklare ledde arbetet med korrigeringarna.
En pressad releaseplan
CVE-identifierarna dök upp på nätet den 20 oktober, innan några korrigeringar fanns tillgängliga. PHP tidigarela den planerade releasen till den 21 oktober och sade att den kunde publicera uppdateringen tidigare om detaljer läckte ut eller aktiva angrepp upptäcktes. PHP Foundation sade senare att Chainguard publicerade korrigerade containeravbilder mer än sex timmar före den samordnade releasen, vilket potentiellt gav angripare tid att studera korrigeringen. Chainguards vd försvarade beslutet med hänvisning till rapporter om pågående angrepp.
Vad rapporterna säger om angreppen
Amazon säger att företagets honeypotnätverk MadPot registrerade ett misstänkt PHP2Shell-försök den 17 oktober, fyra dagar före det offentliga avslöjandet. Amazon vet inte hur aktören fick information om exploiten. Företaget rapporterade fler försök före och efter releasen den 21 oktober, men säger att det inte har kunnat fastställa om de tidigaste försöken skulle ha fungerat mot verkliga system. I sin varning den 21 oktober sade CISA att myndigheten inte hade observerat några angrepp vid tidpunkten för publiceringen. Försök är inte bevis på lyckade intrång, och rapporterna beskriver observationer från olika tidpunkter.
PHP kan finnas dolt i containrar, apparater, värdplattformar eller andra produkter, vilket gör det svårt att hitta. CISA uppmanade organisationer att inventera sina system, prioritera servrar som är åtkomliga från internet och koppla bort PHP-baserade tjänster om de inte kan uppdateras snabbt. En brandvägg för webbapplikationer kan ge tillfälligt skydd, men Cloudflare säger att den inte ersätter en uppdatering av PHP och rapporterar att angripare har ändrat sina nyttolaster för att testa skydden.
Vad försvarare bör göra nu
Amazon säger att angreppen nu är omfattande och uppmanar organisationer att behandla kritiska korrigeringar för system som är åtkomliga från internet som brådskande, i stället för att förlita sig på veckolånga uppdateringsscheman. Försvarare bör hitta alla PHP-körmiljöer, kontrollera att själva körmiljön – inte bara applikationen – har åtgärdats och granska loggar efter misstänkt aktivitet. Eftersom Amazons tidigaste observerade försök inträffade innan den offentliga varningen bör organisationer inte utgå från att risken började den dag sårbarheterna offentliggjordes.