Secondo un report del 24 ottobre di Pierluigi Paganini su Security Affairs, che cita le osservazioni dei ricercatori AWS tramite honeypot, gli attaccanti avrebbero tentato di sfruttare PHP2Shell quattro giorni prima della divulgazione pubblica e della disponibilità della patch. I tentativi rilevati non dimostrano che i server siano stati compromessi con successo.
I due avvisi ufficiali di PHP, pubblicati il 21 ottobre 2026, descrivono vulnerabilità critiche nella gestione della memoria che possono consentire l'esecuzione remota di codice. Entrambi indicano le correzioni contenute nelle versioni PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12, mentre le versioni precedenti dei rispettivi rami di rilascio risultano vulnerabili. Le condizioni precise di sfruttamento variano in base alla vulnerabilità, all'interfaccia del server, all'applicazione e alla configurazione.
Uno sfruttamento riuscito potrebbe consentire a un attaccante di eseguire comandi con i permessi dell'account del worker web. Paganini ha descritto possibili conseguenze, tra cui furto di dati, installazione di malware, modifiche ai siti web e interruzioni del servizio. Si tratta di impatti potenziali, non di esiti confermati dei tentativi segnalati.
L'esaurimento della memoria può esporre uno stato non valido della richiesta
La prima vulnerabilità, CVE-2026-109618, riguarda l'uso di longjmp() da parte di PHP per interrompere l'elaborazione della richiesta dopo un errore di esaurimento della memoria. Se questa uscita avviene mentre la memoria della richiesta è solo parzialmente inizializzata, l'elaborazione della chiusura può incontrare uno stato non valido e portare all'esecuzione remota di codice.
L'avviso descrive diversi modi in cui le richieste multipart possono esaurire la memoria nonostante i limiti apparenti sull'input. Tra questi: richieste senza una lunghezza del contenuto dichiarata utilizzabile, intestazioni non limitate all'interno delle singole parti e controlli file vuoti che creano metadati senza essere conteggiati in max_file_uploads. Anche l'elaborazione specifica dell'applicazione di input controllati dall'attaccante può esaurire la memoria.
L'avviso di PHP indica che l'esecuzione remota di codice non autenticata è stata verificata via HTTP contro Apache mod_php, con i limiti predefiniti di input e memoria di PHP e con configurazioni prefork normali con più worker. Il parsing automatico del corpo della richiesta può innescare il problema prima che venga eseguito il codice dell'applicazione. Worker aggiuntivi e traffico non correlato possono aumentare il numero di tentativi necessari, mentre l'affidabilità dipende dalla build di PHP, dalle estensioni, dal comportamento del frontend e dalla disposizione dell'allocatore.
Le evidenze cambiano per gli altri tipi di deployment. FPM termina un processo figlio quando l'avvio della richiesta fallisce, impedendo che quel percorso di avvio consumi uno stato non valido. L'analisi del codice sorgente indica comunque una suscettibilità dopo l'avvio normale, anche se non è stato dimostrato alcun exploit completo per FPM. L'avviso ritiene che FrankenPHP sia probabilmente vulnerabile ad attacchi indipendenti dall'applicazione, mentre lo sfruttamento specifico dell'applicazione tramite LSAPI è considerato probabile ma non ancora verificato.
Lo stato obsoleto può superare i confini delle richieste
La seconda vulnerabilità, CVE-2026-109619, riguarda uno stato a livello di worker che conserva riferimenti alla memoria appartenente a una richiesta completata.
Lo sfruttamento richiede un'operazione che lascia accessibile lo stato di proprietà della richiesta dopo il rilascio della memoria, seguita da un'altra operazione che usa lo stato obsoleto prima che l'inizializzazione normale lo azzeri. Nel caso dimostrato, le due operazioni avvengono in richieste HTTP diverse gestite dallo stesso worker.
Gli errori fatali, incluso l'esaurimento della memoria, possono interrompere la pulizia. Anche diagnostiche non fatali possono ripopolare lo stato di errore dopo che è stato cancellato. Un heap disposto con cura può trasformare il use-after-free risultante in esecuzione remota di codice. La raggiungibilità dipende dallo stato specifico, dall'applicazione, dalle estensioni e dalla configurazione.
Gli aggiornamenti offrono la soluzione completa
Entrambi gli avvisi indirizzano gli operatori alle versioni corrette nei rispettivi rami di PHP:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
L'emittente afferma che l'aggiornamento è l'unica mitigazione completa per la falla di esaurimento della memoria e l'unica mitigazione affidabile per quella dello stato obsoleto.
Per le installazioni che non possono essere aggiornate, imporre amministrativamente memory_limit=-1 elimina il limite prevedibile per richiesta usato dall'exploit di esaurimento della memoria confermato. Ogni worker PHP deve essere riavviato, e gli operatori devono assicurarsi che le impostazioni di pool, directory o applicazione non ripristinino un limite finito. Si tratta comunque di una protezione incompleta: i fallimenti di allocazione sottostanti possono ancora innescare il percorso vulnerabile.
PHP sconsiglia esplicitamente l'uso di RLIMIT_AS o RLIMIT_DATA, perché possono causare errori di mmap() che innescano quel percorso. Anche i limiti di memoria di container o cgroup sono una mitigazione incompleta e possono terminare più worker o il processo master.
Per PHP 8.5, impostare amministrativamente fatal_error_backtraces=0 e riavviare ogni worker elimina la fonte usata nel caso confermato di RCE con stato obsoleto. Non copre altri stati globali o delle estensioni: l'avviso precisa che nessuna modifica generica della configurazione offre una protezione completa.
L'emittente raccomanda inoltre impostazioni prudenti di post_max_size, limiti sulla dimensione decodificata delle richieste applicati autonomamente dal frontend e limiti su annidamento dell'input, variabili, parti multipart, intestazioni per parte e upload. Le applicazioni che non usano dati di moduli multipart possono bloccarli già dal frontend. Questi controlli riducono il rischio ma non sostituiscono gli aggiornamenti.
Nel suo report del 24 ottobre, Paganini ha esortato gli operatori a verificare le attività sospette risalenti al 17 ottobre. Ha inoltre discusso di come l'IA potrebbe accelerare lo sviluppo degli exploit, avvertendo però che non si dovrebbe presumere automaticamente che gli attacchi siano guidati dall'IA.
