Negli ultimi giorni la vulnerabilità PHP2Shell è diventata un bersaglio prioritario per molti attori malevoli, con milioni di tentativi di exploit osservati a poche ore dalla divulgazione pubblica. Le falle identificate come CVE-2026-109618 e CVE-2026-109619, con punteggio CVSS 9.2, possono portare a remote code execution (RCE) non autenticata tramite richieste HTTP appositamente costruite.
Gli aggiornamenti di sicurezza sono disponibili nelle versioni PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mentre gli ambienti con release non supportate restano un punto critico per la sicurezza web.
Nonostante l’intensità delle scansioni e dei probe, molte campagne risultano inefficaci perché la catena di sfruttamento richiede precondizioni precise legate a configurazione del server, gestione delle sessioni e comportamento dei worker PHP. In diversi casi l’obiettivo è installare malware Mirai su sistemi Linux, arruolando i dispositivi in botnet dedicate ad attacchi DDoS. Alcuni campioni analizzati mostrano logiche tipiche di downloader, risoluzione DNS con fallback su server pubblici e verifica del payload atteso come binario ELF, segnale di un secondo stadio mirato.
Le analisi indicano anche tentativi di stabilire canali di comando e controllo su porte TCP specifiche e di usare script automatici per fingerprinting di siti esposti, inclusi controlli su versione PHP, presenza di pagine phpinfo, errori visibili e possibilità di injection tramite sessione. In parallelo emergono toolkit che puntano ad aggirare ASLR, la protezione che randomizza gli indirizzi di memoria rendendo più complessi gli exploit di tipo memory corruption. Alcuni strumenti descrivono un approccio in più fasi per riciclare i worker, ottenere leak di indirizzi tramite cookie di sessione e poi eseguire comandi sfruttando funzionalità legate all’upload progress delle sessioni.
Il quadro complessivo suggerisce una forte pressione sugli asset esposti, ma con compromissioni non confermate su larga scala. Resta comunque elevato il rischio operativo: una RCE riuscita può consentire accesso a chiavi API, credenziali, connessioni a database e servizi interni raggiungibili dall’applicazione web. Per ridurre la superficie di attacco, la priorità è aggiornare PHP alle versioni corrette, verificare configurazioni e limitare esposizione di endpoint e informazioni diagnostiche.