php2shell: due vulnerabilità critiche in PHP, cosa fare

Articolo

Cybersecurity

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

CyberAgent

Vulnerability assessment continuo e gap analysis: scansione, mappatura sui requisiti dei framework, evidenze documentali pronte all’uso.

Scopri CyberAgent →

Il 21 ottobre il team di sicurezza di PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, che correggono CVE-2026-109618 e CVE-2026-109619. Secondo l’advisory entrambe consentono l’esecuzione remota di codice senza autenticazione e hanno un punteggio CVSS v4.0 di 9.2. I ricercatori che le hanno scoperte le chiamano php2shell.

L’advisory riguarda tutte le installazioni che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è considerato più alto per mod_php, dove è stato dimostrato un exploit che parte con una richiesta non autenticata prima che venga eseguito il codice dell’applicazione.

Le due vulnerabilità

• CVE-2026-109618, corruzione per esaurimento della memoria. Quando la memoria finisce, PHP può essere interrotto mentre i dati interni della richiesta sono inizializzati solo in parte; la pulizia successiva può trattare quei dati non validi come validi.
• CVE-2026-109619, stato globale residuo. Uno stato interno legato alla richiesta può sopravvivere dopo che la memoria che lo contiene è stata liberata (use-after-free); una richiesta successiva servita dallo stesso worker può usarlo prima della normale inizializzazione.

Secondo la ricostruzione dei ricercatori di Calif, la catena sfrutta richieste multipart costruite per esaurire il limite di memoria e lasciare uno stato non coerente, che la richiesta successiva consuma attraverso l’upload progress delle sessioni o la deserializzazione. Calif riferisce di aver confermato l’esecuzione di codice prima dell’autenticazione su versioni specifiche di applicazioni diffuse, fra cui WordPress, Drupal, Joomla, Magento, Nextcloud e phpMyAdmin, e che il percorso vulnerabile più vecchio trovato risale a PHP 5.4.0. Sono dati dei ricercatori, non ancora verificati in modo indipendente.

Versioni da installare

Le distribuzioni Linux e i fornitori di supporto esteso hanno ricevuto le patch in anticipo: chi usa i pacchetti della distribuzione deve controllare gli aggiornamenti del proprio fornitore. Il repository volontario rpms.remirepo.net non avrà gli aggiornamenti il giorno del rilascio. CERT-EU segnala che possono essere coinvolti anche i prodotti di terze parti che includono PHP, e rimanda all’elenco curato dall’NCSC olandese, ancora incompleto.

Le segnalazioni di sfruttamento

Le informazioni disponibili sono ancora preliminari.

• Amazon Threat Intelligence riferisce di aver osservato un tentativo di sfruttamento il 17 ottobre nella rete di honeypot MadPot, quattro giorni prima della pubblicazione, e altri tentativi il 21 ottobre da infrastrutture diverse, con payload che fanno pensare a più attori. Amazon precisa che non è chiaro come l’attaccante abbia ottenuto le informazioni né se i tentativi sarebbero riusciti su sistemi reali, e scrive che php2shell è ora sfruttato su larga scala.
• Cloudflare: il 21 ottobre il CTO Dane Knecht ha scritto che l’azienda vede i primi attacchi e che ha attivato regole WAF per i vettori noti, disponibili anche per i piani gratuiti; le regole valgono solo per il traffico che passa dalla sua rete e lui stesso le definisce una soluzione provvisoria.
• Il team di sicurezza di PHP ha esaminato i proof of concept comparsi dopo la fuga di notizie e, al momento del rilascio, non ha trovato exploit funzionanti. Il codice che circola senza verifica può contenere malware.

Cosa fare subito

1. Inventario. Individuare tutte le installazioni PHP esposte, comprese quelle dentro prodotti di terze parti, container e immagini di base.

2. Aggiornare. Installare le versioni corrette o i pacchetti aggiornati della distribuzione, ricostruire le immagini dei container e riavviare tutti i worker PHP. Secondo il team di PHP l’aggiornamento è l’unica correzione completa.

3. Se non si può aggiornare subito, le mitigazioni indicate nell’advisory riducono l’esposizione ma non rendono l’installazione sicura:

   • memory_limit=-1 impostato in modo che le applicazioni non possano sovrascriverlo (per esempio php_admin_value nel pool FPM), con post_max_size basso (8M senza upload, 32M con upload) e limiti alla dimensione e alla struttura delle richieste sul web server o sul proxy;
   • session.upload_progress.enabled=0 in php.ini o nel pool FPM, non con ini_set() né con .user.ini;
   • su PHP 8.5, fatal_error_backtraces=0;
   • correzione degli errori fatali e dei timeout raggiungibili da un attaccante, e rimozione delle impostazioni per richiesta non valide;
   • riavvio di tutti i worker dopo ogni modifica.

   CERT-EU suggerisce di valutare l’isolamento dalla rete pubblica delle applicazioni esposte finché la correzione non è applicata e verificata.

4. Verificare. Amazon consiglia di analizzare i log almeno dal 17 ottobre, cercando richieste POST che contengono la stringa PHP_SESSION_UPLOAD_PROGRESS, e di controllare esecuzioni di processi e modifiche ai file inattese sui web server.

Per i soggetti NIS2, se le verifiche trovano una compromissione con impatto significativo scattano gli obblighi di notifica dell’incidente, a partire dal preallarme entro 24 ore.

Come si è arrivati al rilascio

Dal resoconto della PHP Foundation: le prime tracce del problema di memoria emergono nell’audit del 2024 di Quarkslab; Calif segnala l’esecuzione remota di codice l’11 agosto 2026, lo stesso giorno di OpenAI, poi arrivano le segnalazioni di Wiz (24 agosto) e altri vettori da OpenAI (18 settembre). Il 20 ottobre gli identificativi CVE iniziano a circolare con un orario e un punteggio sbagliati (10.0 invece di 9.2), e il rilascio viene anticipato dal 22 al 21 ottobre; la mattina del 21 un distributore pubblica immagini con la correzione oltre sei ore prima del rilascio coordinato.

Nella scoperta e nella gestione hanno avuto un ruolo gli strumenti di AI: Calif descrive l’uso di un assistente basato su LLM e di agenti di audit, OpenAI ha partecipato con Codex Security, e il team di PHP usa l’AI per validare le segnalazioni e raggruppare quelle con la stessa causa, mentre le decisioni e le patch restano alle persone.

Cosa ne pensiamo

PHP serve una parte molto ampia del web, spesso in installazioni dimenticate: siti istituzionali, gestionali, plugin, appliance con PHP incorporato. Per questo la prima difficoltà non è applicare la patch ma sapere dove serve. Il caso conferma quanto si stia accorciando il tempo fra la scoperta e lo sfruttamento, anche con l’aiuto dell’AI su entrambi i fronti, come abbiamo scritto parlando di REA: per le vulnerabilità critiche esposte su internet, Amazon invita a ragionare in ore e non in giorni. Un inventario aggiornato delle componenti esposte e una procedura di aggiornamento rapida servono più di qualunque regola WAF, che resta una misura temporanea.

Cosa monitorare

• L’inserimento delle due CVE nel catalogo KEV della CISA e le conferme di compromissioni reali.
• L’analisi tecnica completa dei ricercatori e gli eventuali nuovi vettori.
• I pacchetti delle distribuzioni per i rami fuori supporto e l’elenco dei prodotti di terze parti coinvolti.

Fonti

• PHP, Security advisory: critical remote code execution vulnerabilities, update now
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, Today’s PHP security release
• CERT-EU, Security Advisory 2026-018
• Amazon Threat Intelligence, php2shell exploitation prior to public disclosure
• Calif, php2shell
• Dane Knecht (CTO di Cloudflare), post su X del 21 ottobre 2026
• NCSC-NL, php2shell (prodotti coinvolti, rilevamento e mitigazioni)
• REA: reverse engineering con gli agenti AI via MCP