PHP2Shell nel catalogo KEV della CISA: prime shell su honeypot

📌 Sviluppi successivi: PHP2Shell su PAN-OS: correzioni per cinque rami e Panorama (29 ottobre 2026) · PHP2Shell e Fragnesia: root sui firewall PAN-OS in 15 minuti (28 ottobre 2026)

Il 26 ottobre 2026 la CISA, l’agenzia statunitense per la cybersicurezza e la sicurezza delle infrastrutture, ha aggiunto le due vulnerabilità PHP2Shell, CVE-2026-109618 e CVE-2026-109619, al catalogo Known Exploited Vulnerabilities (KEV). Le agenzie civili federali degli Stati Uniti devono correggerle entro giovedì 29 ottobre. Nello stesso fine settimana sono arrivate le prime prove pubbliche di esecuzione di codice riuscita, ottenute però su honeypot.

I nostri articoli precedenti riportavano l’annuncio delle due falle, le versioni corrette del 21 ottobre, la terza RCE CVE-2026-115560 e una settimana di tentativi di sfruttamento senza successi confermati. Di seguito le novità.

Cosa significa l’inserimento nel KEV

Secondo The Register, la settimana precedente la CISA aveva avvertito del pericolo senza aver osservato sfruttamenti riusciti. Ora l’agenzia considera entrambe le vulnerabilità sfruttate attivamente, ma non ha indicato vittime, attori né dettagli degli attacchi. Un portavoce, citato da The Record, ha rimandato alle regole del KEV, secondo cui lo «sfruttamento attivo» comprende sia i tentativi sia gli attacchi riusciti. Secondo Computer Weekly, la CISA non sa se le falle siano state usate in campagne ransomware.

In pratica l’inserimento conferma che le vulnerabilità sono prese di mira, non quanti sistemi in produzione siano stati davvero compromessi. La scadenza vale solo per le agenzie federali statunitensi, ma la CISA invita tutte le organizzazioni a dare priorità alle correzioni.

Nell’avviso aggiornato, riportato da The Record, la CISA chiede di:

• individuare e inventariare i sistemi con qualsiasi versione di PHP;
• applicare le correzioni oppure togliere dalla rete i sistemi che non si possono aggiornare subito;
• tenere presente che in alcuni casi un web application firewall può dare una protezione per un periodo limitato.

L’avviso rimanda anche alle indicazioni di PHP e delle agenzie di Australia, Canada, Nuova Zelanda e Regno Unito.

Le prime RCE riuscite

Secondo The Register, il 24 ottobre il ricercatore Adel Karimi (Perplexity) ha registrato 35 esecuzioni di shell riuscite su tre honeypot con PHP 8.4.26 sotto Apache mod_php. Anche Computer Weekly riporta un’esecuzione di codice da remoto su un honeypot con la stessa versione e la stessa configurazione, emersa domenica 25 ottobre. I dettagli, secondo The Register:

• gli attacchi venivano da due indirizzi IP e sfruttavano l’esaurimento e la divulgazione di memoria per arrivare all’esecuzione di codice;
• ottenuta la shell, gli attaccanti hanno cercato di contattare server esterni con PHP, curl e wget, senza riuscire a scaricare altro malware;
• l’attività è compatibile con CVE-2026-109618, che Computer Weekly descrive come corruzione della memoria; nessun segno di CVE-2026-109619, un difetto legato a uno stato interno della richiesta non più valido;
• Karimi avverte che gli honeypot avevano una configurazione favorevole, con un solo worker: i risultati non dicono quanto l’exploit sia affidabile contro i server di produzione.

Sempre secondo The Register, il Threat Intelligence Lab dell’Università di Delft ha contato oltre 50.000 richieste di sfruttamento da più di 600 indirizzi IP in 70 paesi; 171 di questi indirizzi non si sono limitati a cercare server vulnerabili e hanno inviato codice di exploit o dropper di malware. Le fonti non pubblicano gli indirizzi: non ci sono indicatori di compromissione pubblici.

Alcune segnalazioni precedenti si sono rivelate premature: Sophos ha ricondotto l’attività osservata a scansioni e tentativi falliti, e Palo Alto Networks ha ritirato il collegamento tra le falle e un’intrusione in un’agenzia governativa europea (The Register, The Record).

Sui tempi, CrowdStrike, citata da Computer Weekly, spiega che rendere operativi gli exploit ha richiesto più tempo perché il PoC va adattato alla versione di PHP e all’applicazione bersaglio, con conoscenze specifiche su container Docker e pacchetti. Secondo TechCrunch, unica fonte su questo punto, le due falle erano note da due anni ma erano state ritenute non sfruttabili in pratica, finché i ricercatori della società Calif hanno trovato un metodo con l’aiuto di un modello di IA.

Tecniche MITRE ATT&CK: T1190 (sfruttamento di applicazioni esposte su Internet) e, per i tentativi di scaricare strumenti con curl e wget, T1105 (Ingress Tool Transfer).

Aggiornamenti: i numeri dipendono dalla fonte

• Secondo la dashboard di Censys citata da The Record, dei 42 milioni di servizi PHP esposti su Internet oltre 10 milioni sono stati aggiornati dal 21 ottobre; il 22 ottobre erano circa 1 milione.
• Il PHP2Shell Tracker di Infrawatch, citato da Computer Weekly, contava alle 12:00 UTC del 27 ottobre circa 443.000 host visibili aggiornati, intorno al 20% del totale, con 31.000 in più nelle 24 ore precedenti: il 27,2% nel Regno Unito e il 19,7% negli Stati Uniti.

I due strumenti misurano insiemi diversi e i numeri assoluti non sono confrontabili, ma entrambi indicano che la maggior parte delle installazioni esposte non è ancora aggiornata.

Impatto per le aziende europee e italiane

Il KEV non obbliga le aziende europee, ma è un segnale da seguire. Le fonti indicano dove rischiano di restare installazioni dimenticate:

• siti piccoli o non più manutenuti e PHP «nascosto» dentro prodotti e piattaforme più grandi, anche presso partner esterni (William Wright, Closed Door Security, a Computer Weekly);
• i backend delle app per Android e iOS: secondo l’analisi di NowSecure ripresa da Cybersecurity360, le falle non colpiscono i telefoni, ma un backend PHP compromesso può esporre dati e API usati dalle app, compresi i servizi raggiunti tramite SDK di terze parti.

Per i soggetti NIS2 l’inserimento nel KEV è un elemento da documentare nella priorità delle correzioni, insieme alla verifica dei fornitori che gestiscono applicazioni PHP per conto dell’azienda; un eventuale incidente significativo va valutato ai fini della notifica al CSIRT Italia. Nella sanità vanno controllati per primi portali dei pazienti, prenotazioni online e app collegate.

Cosa fare subito

1. Aggiorna a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure alle versioni corrette della tua distribuzione o del tuo hosting, e controlla la versione usata davvero dal server web, non solo quella di php -v.
2. Versioni fuori supporto: passa a un ramo supportato o ottieni correzioni dal fornitore; se non è possibile, togli il sistema da Internet, come indica la CISA.
3. Priorità ad Apache mod_php: è la configurazione delle RCE riuscite sugli honeypot.
4. WAF solo come misura temporanea, in attesa dell’aggiornamento.
5. Lascia disattivato session.upload_progress.enabled se l’hai già fatto per CVE-2026-115560: la terza falla non è ancora corretta.
6. Chiedi conferma ai fornitori dell’aggiornamento di applicazioni, hosting e backend delle app mobili.
7. Cerca segni di compromissione: processi PHP che avviano shell, curl o wget, connessioni in uscita inattese dai server web, richieste anomale nei log.

Come aiuta ARXDOME

ARX Shield mostra per ogni macchina le vulnerabilità aperte per pacchetto, con in evidenza quelle già sfruttate. L’inventario di ARX Sentry elenca software e processi dei server con l’agent: aiuta a trovare PHP e PHP-FPM. ARX Expose indica quali servizi pubblici della tua azienda espongono prodotti riconosciuti, così puoi partire da quelli raggiungibili da Internet.

Ultimo aggiornamento: 27 ottobre 2026