ITSOS.it

PHP2Shell: le RCE critiche di ottobre 2026 (CVE-2026-109618 / 109619)

Vulnerabilità critiche PHP2Shell: RCE non autenticata

Il 21 ottobre 2026 il team di sicurezza PHP ha rilasciato patch di emergenza per due falle critiche di remote code execution (RCE) non autenticata, note collettivamente come PHP2Shell: CVE-2026-109618 e CVE-2026-109619. Il 26 ottobre la CISA le ha inserite nel catalogo Known Exploited Vulnerabilities (KEV): non è più solo un avviso teorico, c’è evidenza di sfruttamento nel mondo reale.

Contenuto informativo basato su advisory PHP, CISA e reportistica di settore. Non sostituisce una valutazione sul perimetro specifico della vostra organizzazione.

Cosa è successo

Entrambe le vulnerabilità riguardano il runtime PHP che serve richieste web: PHP-FPM, Apache con mod_php (rischio considerato più alto dal progetto PHP), php-cgi, FrankenPHP, LiteSpeed. In sintesi, PHP può lasciare la memoria in uno stato invalido quando una richiesta termina in modo anomalo; un attaccante remoto, senza login, può tentare di trasformare quel disordine in esecuzione di codice con i privilegi del worker web.

  • CVE-2026-109618 — corruzione legata a condizioni di out-of-memory (OOM): la gestione della memoria può interrompere la richiesta mentre strutture interne sono solo parzialmente inizializzate.
  • CVE-2026-109619 — «stale global state»: stato interno legato a una richiesta può sopravvivere dopo che la memoria sottostante è stata liberata; una richiesta successiva sullo stesso worker può riusarlo prima del reset.

Il progetto PHP ha pubblicato fix in 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non ci sono aggiornamenti upstream regolari: servono backport del vendor/LTS oppure (meglio) passaggio a un ramo supportato. Il team ha comunque messo a disposizione backport sorgente minimi per 7.4 / 8.0 / 8.1 per chi compila da sorgente.

Perché conta per PMI e siti «normali»

PHP non è solo «il linguaggio dei developer». È il motore di WordPress, di tanti CMS, di portali clienti e di pezzi di gestionale web. Spesso non compare come prodotto a sé nello stack diagram: è dentro l’hosting, il container, l’immagine Docker «LAMP» lasciata lì da anni.

Due punti operativi:

  • Niente autenticazione richiesta sul vettore principale: se il sito è raggiungibile, il worker PHP è il bersaglio.
  • Sfruttamento confermato: oltre alle probe di massa, ricercatori (honeypot su mod_php) hanno documentato catene che arrivano a shell effettive; la CISA ha aggiornato l’alert e messo entrambe le CVE nel KEV (26 ott 2026).

Cosa fare subito (checklist)

  • Inventario: dove gira PHP? Hosting condiviso, VPS, container, appliance web, WordPress «gestito» dal provider. Chiedete la versione esatta (php -v / pannello / ticket al provider).
  • Patch prioritaria su internet-facing: aggiornate a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (o pacchetto vendor equivalente). Riavviate i worker (FPM/Apache) dopo l’update.
  • PHP 8.1 o più vecchio: non è «ancora ok perché finora non è successo nulla». Piano di migrazione o backport LTS adesso; se non potete patchare, CISA suggerisce di considerare offline i sistemi esposti fino a fix/upgrade.
  • Mitigazioni temporanee ≠ fix: l’advisory PHP elenca misure che riducono alcune path (es. limiti di richiesta, controlli su session upload progress / serialize handler). Nessuna sostituisce l’aggiornamento.
  • Monitoraggio: processi worker che lanciano shell, download anomali, crash ripetuti OOM, pattern HTTP insoliti. La CISA ha anche condiviso indicazioni di detection (incl. regole Sigma nell’alert aggiornato).
  • WAF: può aiutare a ridurre l’esposizione durante la finestra di patching; non è la chiusura del rischio.

Nota del 23 ottobre: session upload progress

Due giorni dopo le patch critiche, PHP ha pubblicato un advisory informativo: in una combinazione poco comune di configurazione (serialize handler cambiato a runtime + session.upload_progress ancora attivo) resta un vettore RCE improbabile ma reale. Mitigazione consigliata fino al prossimo bugfix: session.upload_progress.enabled=0. Se l’avevate già applicata come mitigazione per CVE-2026-109619, tenetela.

Dove si collega nel percorso ITSOS

Se non avete ancora chiaro dove gira PHP e cosa è esposto: partite da una fotografia del perimetro — Audit / Security Status Report. Per chiudere aperture dopo l’assessment (patch, hardening hosting, riduzioni di superficie): Hardening. Per monitoraggio continuo su sistemi concordati: 003 Intelligence.

Fonti

Prossimo passo

Verificate la versione PHP su ogni proprietà web esposta e patchate prima di «chiudere il ticket nella testa». Se la coda di sistemi è lunga e le priorità non sono scritte, conviene partire dall’esposizione reale. Contatti: itsos.it/contatti · hub: Cybersecurity.