L'IA ha scovato un bug ventennale nel cuore di PHP. Ora esegue codice sul tuo server. Applica subito la patch.

Il 21 ottobre il progetto PHP ha rilasciato quattro versioni contemporaneamente — 8.5.12, 8.4.27, 8.3.36 e 8.2.35 — per correggere due vulnerabilità critiche con punteggio CVSS 9,2 ciascuna: CVE-2026-109618 e CVE-2026-109619. Insieme vengono chiamate php2shell. Ciascuna consente a un attaccante non autenticato di eseguire codice su un server che non fa altro che servire PHP. Non è coinvolto alcun bug applicativo. Una semplice pagina «Hello World» su una versione vulnerabile è sufficiente.

Entrambe le vulnerabilità si trovano nelle parti di PHP che quasi ogni richiesta attraversa: gestione della memoria e gestione degli errori. CVE-2026-109618 corrompe la memoria nel modo in cui PHP fa pulizia dopo aver esaurito la memoria durante una richiesta. CVE-2026-109619 è un use-after-free, in cui lo stato interno di una richiesta persiste nella richiesta successiva gestita dallo stesso worker. Wiz Research le ha trovate con l'aiuto di agenti IA, le ha segnalate privatamente ad agosto e la correzione è arrivata il 21 ottobre in un rilascio coordinato con le distribuzioni e i vendor. Wiz afferma che sono interessate tutte le versioni di PHP dalla 5.4 in poi, ovvero circa l'ultimo decennio del linguaggio. PHP gestisce una grande parte del web, quindi il numero di server esposti è enorme.

Chi è effettivamente esposto

Il team di PHP considera Apache con mod_php il rischio più elevato. In quel caso, una singola richiesta non autenticata può innescare l'exploit prima che il tuo codice venga eseguito, quindi nessuna delle tue difese — middleware di autenticazione, validazione dell'input, controlli in-app — ha mai la possibilità di intervenire. L'esecuzione di codice remoto completa è stata dimostrata su mod_php con impostazioni predefinite contro container freschi di WordPress, Drupal e Joomla.

Nemmeno PHP-FPM è al sicuro. L'RCE attraverso il bug di stato non aggiornato è stato validato su FPM, anche se quel percorso richiede un'operazione adeguata nell'applicazione in esecuzione per raggiungerlo. php-cgi, FrankenPHP e LiteSpeed sono tutti nel perimetro. Se serve PHP via HTTP, consideralo vulnerabile finché non hai applicato la patch e riavviato.

Un punto per i team mobile, perché l'esposizione è facile da trascurare: nei nostri progetti nativi iOS e Android l'app stessa è pulita, ma comunica con un'API, e quell'API è molto spesso PHP. Un backend non patchato mette a rischio i tuoi utenti anche se sul dispositivo non c'è nulla di sbagliato. Controlla il server dietro l'app, non solo l'app.

Cosa faremmo per prima cosa

Dal nostro lavoro su PHP e Docker, l'errore che vediamo sotto pressione è patchare la cosa sbagliata. Due passaggi contano più degli altri.

1. Trova ogni istanza di PHP che esegui, non solo quella ovvia. Si nasconde in stack cPanel e Plesk, appliance dei vendor, vecchi siti di clienti che nessuno ha toccato da due anni, immagini CI e container base. La guida della CISA è fare prima un inventario, perché PHP è spesso sepolto all'interno di altri software e non puoi patchare ciò che non hai trovato.
2. Patcha, poi riavvia, poi verifica la versione che il processo in esecuzione riporta. Un nuovo pacchetto su disco non fa nulla finché non sostituisci i worker in esecuzione. Abbiamo visto team «patchare» e rimanere sfruttabili per giorni perché PHP-FPM non era mai stato effettivamente riavviato.

I container rendono questa trappola peggiore. Eseguire un aggiornamento all'interno di un container attivo non è una correzione, perché il tuo prossimo deploy dall'immagine vecchia riporta direttamente la versione vulnerabile. Ricostruisci su un'immagine base patchata, inviala e fai il rollout dei worker. Poi accedi al server e conferma che la versione che ti aspetti sia quella che risponde.

Se non puoi davvero patchare oggi

Il team di PHP è diretto: solo l'aggiornamento è una correzione completa, e le impostazioni temporanee restringono solo percorsi di attacco specifici. Quelle che vale la pena applicare sono memory_limit=-1 applicato dove l'app non può sovrascriverlo, usando php_admin_value nel tuo pool FPM o nella configurazione Apache, poi session.upload_progress.enabled=0 e un post_max_size conservativo. Se usi Cloudflare, la regola WAF gestita per questi CVE è già attiva, e guadagnare tempo con una regola edge mentre i worker vengono patchati è esattamente il tipo di cosa che configuriamo per i clienti durante un incidente. Una nota: quella regola si basa sul nome predefinito del campo upload-progress, quindi se hai rinominato session.upload_progress.name, non ti coprirà.

La parte che dovrebbe preoccuparti più di questo singolo bug

Ecco cosa mi colpisce di php2shell. Questi bug erano nel codebase da circa vent'anni. Nessuno li aveva armati perché trasformare una catena di corruzione della memoria in un exploit affidabile su ogni versione di PHP, set di estensioni e layout dell'heap era un lavoro lento e specialistico, del tipo che richiede mesi. Wiz ha usato modelli IA all'avanguardia per fare quell'adattamento, e ci ha impiegato un paio di settimane invece.

Durante i nostri engagement di pentesting per studi di gaming, la parte difficile era raramente individuare un percorso di codice sospetto. Era dimostrare un exploit reale e ripetibile prima che qualcuno fosse disposto a pagare per risolverlo. Quella logica economica è cambiata. Gli attaccanti ottengono la stessa accelerazione, il che significa che il divario tra la pubblicazione di una patch e la scansione di massa continua a ridursi. Cloudflare ha segnalato tentativi di sondaggio intorno al momento del rilascio, e una proof of concept sta già circolando.

Quindi la conclusione onesta è scomoda: il tuo ritmo di patching è ora la tua postura di sicurezza. Se non riesci a trovare e aggiornare un runtime critico su tutta la tua infrastruttura in un giorno, quello è il vero gap, e php2shell non sarà l'ultima cosa a metterlo alla prova.

Se mantenere PHP patchato, riavviato e verificato tra staging, produzione e una serie di vecchi siti di clienti ti suona familiare, parliamone.