Amazon ha riferito che MadPot, il suo sistema honeypot (un’esca digitale usata per rilevare attacchi), ha registrato il 17 ottobre 2026 un tentativo di sfruttamento di PHP2Shell contro un honeypot, quattro giorni prima della divulgazione pubblica. Il 21 ottobre PHP ha pubblicato le correzioni per le due vulnerabilità: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. L’osservazione di Amazon riguarda attività diretta ai propri sensori e non documenta una compromissione riuscita di sistemi reali.
Che cosa ha registrato MadPot
Amazon ha riferito anche di attività contro i sensori MadPot il 21 ottobre. Ha collocato i primi exploit proof of concept, cioè dimostrazioni tecniche di un attacco, attorno alle 02:00 UTC e ha segnalato ulteriori tentativi tra le 02:00 e le 08:00 UTC. Dopo le 14:00 UTC, quando PHP ha divulgato le vulnerabilità e le correzioni, Amazon ha osservato altra attività contro i propri sensori.
Questi dati descrivono tentativi rilevati dall’infrastruttura di Amazon. Amazon non ha riferito una compromissione confermata di sistemi reali. Il resoconto di Amazon su MadPot colloca quindi l’attività osservata prima della divulgazione senza attribuire all’attaccante una provenienza precisa delle informazioni sulle vulnerabilità.
Quali sistemi e vulnerabilità sono coinvolti
PHP2Shell è il nome collettivo di CVE-2026-109618 e CVE-2026-109619, due vulnerabilità critiche del core PHP che possono consentire l’esecuzione di codice da remoto senza autenticazione nelle installazioni che servono richieste web. PHP include nell’ambito PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed, e indica Apache mod_php come la configurazione a rischio più elevato.
Le due falle coinvolgono problemi di gestione della memoria, ma seguono percorsi diversi. CVE-2026-109618 riguarda una condizione di memoria esaurita che può lasciare dati della richiesta inizializzati solo in parte. CVE-2026-109619 è una use-after-free: il processo può conservare un riferimento a memoria già liberata e riutilizzarla durante una richiesta successiva. PHP assegna a entrambe un punteggio CVSS 4.0 di 9,2. I dettagli sono nei bollettini ufficiali delle due vulnerabilità e della seconda falla.
Versioni corrette e rami precedenti
PHP ha indicato come corrette per entrambe le vulnerabilità le versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. L’avviso ufficiale del progetto riporta le quattro release e il loro ambito.
Il progetto PHP non pubblica più aggiornamenti per PHP 8.1 e le versioni precedenti. Alcune distribuzioni e alcuni fornitori con supporto a lungo termine possono però integrare le correzioni nelle proprie versioni; PHP ha inoltre fornito backport del codice per 7.4, 8.0 e 8.1. Per i pacchetti distribuiti da terzi, conta quindi la correzione applicata dal fornitore, non soltanto il numero della versione upstream. L’avviso di sicurezza di PHP elenca le release corrette e le configurazioni interessate.
Un WAF non sostituisce la correzione
PHP considera l’aggiornamento a una release corretta l’unica soluzione completa. Le misure di configurazione possono ridurre specifici percorsi d’attacco, ma non rendono sicura un’installazione vulnerabile. Un WAF, o firewall per applicazioni web, può essere una misura difensiva aggiuntiva, non un sostituto della versione corretta.
