PHP rilascia patch d'emergenza per due RCE critiche

Aggiornare subito i server PHP: il 21 ottobre il progetto ha pubblicato patch d’emergenza per due vulnerabilità di esecuzione di codice da remoto. Amazon ha osservato tentativi di sfruttamento quattro giorni prima delle correzioni, segnale di attacchi in corso¹.

Le falle sono tracciate come CVE-2026-109618 e CVE-2026-109619, con severità 9,2 su CVSS v4.0 e soprannome “php2shell”¹. Gli sviluppatori indicano che non esistono mitigazioni complete: l’unica opzione sicura è aggiornare. Testo letterale: “There are no complete mitigations; updating is the only safe choice”¹.

I fix sono disponibili nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Gli avvisi specificano differenze di esposizione in base alla SAPI e al modo in cui si serve PHP¹.

Il difetto d’origine è in errori di sicurezza della memoria nel ciclo di vita della richiesta. Un bug riguarda la gestione di out-of-memory. L’altro coinvolge uno stato che sopravvive oltre la memoria che lo ospita. Secondo l’analisi citata, i problemi colpiscono tutte le installazioni non aggiornate a partire dalla 5.4¹.

Sulla superficie d’attacco, gli avvisi distinguono quanto è stato dimostrato in modo affidabile da quanto no. Su Apache con mod_php è stata riprodotta esecuzione di codice da remoto per entrambe le vulnerabilità, via HTTP, con limiti di input e memoria predefiniti di PHP¹.

Per PHP-FPM il quadro è diverso. Esiste una validazione per il problema legato al ciclo di vita della sessione. Per il bug di out-of-memory, invece, non è stato dimostrato un exploit completo per questa SAPI¹.

FrankenPHP entra nel perimetro come “probabilmente suscettibile”. La valutazione deriva dall’analisi del sorgente, non da una dimostrazione pratica pubblica¹.

Sulla cronologia degli attacchi, il resoconto di Amazon parla di attività malevole quattro giorni prima del 21 ottobre. In altre parole, i tentativi sono partiti prima che le patch fossero disponibili pubblicamente¹.

Cosa fare ora. Applicare le versioni 8.5.12, 8.4.27, 8.3.36 o 8.2.35 appena possibile. Gli avvisi non offrono mitigazioni equivalenti: ridurre la superficie non basta. Chi usa Apache con mod_php è nel profilo di rischio più immediato dato che l’esecuzione remota è stata dimostrata in quel contesto. Anche gli ambienti con PHP-FPM e le installazioni basate su FrankenPHP devono trattare l’aggiornamento come prioritario¹.

Un punto operativo utile: gli avvisi separano in modo esplicito gli scenari già replicati da quelli non ancora provati. Questa distinzione orienta la gestione dell’urgenza, ma non cambia la raccomandazione principale: aggiornare rimane la sola misura completa di difesa¹.

La nota pratica per i team che gestiscono fleet ampie: le differenze di esposizione tra SAPI possono aiutare a ordinare i rollout, iniziando dai nodi con mod_php dove l’exploit è confermato, e proseguendo con FPM e FrankenPHP. Gli indizi di attacchi già in corso lasciano poco margine per rimandare¹.