La vulnerabilità PHP2Shell sfruttata con successo, e non più solo tentata: è quanto documenta Adel Karimi, responsabile detection and response di Perplexity, i cui honeypot (server esca) hanno registrato il 24 ottobre 2026 l’esecuzione di codice da remoto su un’installazione Apache mod_php con PHP 8.4.26, una versione precedente alla correzione. Lo riportano BleepingComputer e SecurityWeek, che parlano di 35 shell avviate dagli attaccanti.
Le falle in questione sono la CVE-2026-109618 e la CVE-2026-109619, corrette dal team di PHP il 21 ottobre, come avevamo raccontato nell’articolo su le due falle critiche di PHP.
PHP2Shell sfruttata: cosa hanno registrato gli honeypot
Secondo SecurityWeek, Karimi gestisce honeypot che espongono normali pagine basate su PHP 8.4.26, eseguito con Apache mod_php e un solo processo worker. Il suo primo rapporto, relativo a poco più di 26 ore di attività, aveva registrato errori di memoria e crash dei worker, ma nessuna esecuzione di codice.
Il 24 ottobre la situazione è cambiata: i sensori hanno rilevato 35 shell avviate su tre honeypot da due indirizzi IP. Uno ha prodotto tre shell su un singolo server esca, l’altro 32 shell distribuite su tutti e tre. «Ora è un RCE confermato con divulgazione di memoria utilizzabile, non solo un crash seguito da un processo sospetto», ha scritto il ricercatore, citato da BleepingComputer. SecurityWeek precisa che non è stato osservato il download di un payload di secondo stadio.
La catena d’attacco in quattro richieste
Gli attaccanti hanno usato una sequenza di quattro richieste HTTP: alcune esaurivano la memoria di PHP, un’altra faceva trapelare contenuti della memoria del server, l’ultima eseguiva un comando di shell. Il traffico, spiega SecurityWeek, corrisponde da vicino a un exploit proof of concept pubblico ed è compatibile con lo sfruttamento della CVE-2026-109618.
Marcus Hutchins, ricercatore di Expel, ha definito i dati «di gran lunga la conferma di più alta qualità» di uno sfruttamento in the wild di PHP2Shell vista finora.
I limiti della scoperta
Lo stesso Karimi invita alla prudenza: le prove dimostrano il funzionamento della catena su una configurazione volutamente favorevole, con un solo worker mod_php, e non misurano l’affidabilità dell’exploit con altri numeri di worker, altre build di PHP o altre applicazioni.
Fino a questa segnalazione, secondo le fonti citate da BleepingComputer, l’attività osservata da diverse aziende di sicurezza si era limitata a scansioni, fingerprinting ed exploit non funzionanti. La CISA ha pubblicato una regola di rilevamento Sigma per i tentativi di sfruttamento, ma, secondo SecurityWeek, la mattina del 26 ottobre (ora statunitense) non aveva ancora inserito le due vulnerabilità nel catalogo KEV delle falle sfruttate attivamente.
Cosa fare subito
- Aggiornare PHP alle versioni corrette (8.2.35, 8.3.36, 8.4.27, 8.5.12) e riavviare i processi PHP, così che il codice aggiornato sia davvero in esecuzione.
- Per la terza falla ancora senza patch, la CVE-2026-115560, il team di PHP indica come mitigazione l’impostazione
session.upload_progress.enabled=0. - Controllare i log alla ricerca di errori di memoria esaurita, crash anomali dei worker e richieste multipart di grandi dimensioni verso la pagina principale o
index.php. - Dare priorità ai server esposti su Internet e a quelli con versioni di PHP non più supportate.
- Chi usa un hosting gestito dovrebbe chiedere conferma al provider dell’avvenuto aggiornamento.
Per il quadro italiano resta valido l’alert dell’ACN, secondo cui l’81,9% dei servizi PHP in Italia con versione identificata risultava potenzialmente vulnerabile.
Fonti: BleepingComputer; SecurityWeek; Adel Karimi, report su GitHub.
