PHP2Shell, 650 URL della PA a rischio: AWS rimuove le CA eMudhra

🛡️ Executive Summary

• CERT-AGID individua 650 URL della PA potenzialmente vulnerabili a PHP2Shell: rappresentano il 3,2% degli indirizzi raggiungibili nel campione IPA analizzato, non 650 siti compromessi.
• AWS pubblica un nuovo bollettino sulla crisi eMudhra: otto chiavi crittografiche prevedibili hanno reso necessario modificare gli archivi di certificati considerati affidabili da diversi servizi cloud.
• Le scadenze operative arrivano tra il 28 ottobre e il 2 novembre: amministrazioni e fornitori devono verificare runtime PHP, certificati degli identity provider, configurazioni CloudFront e aggiornamenti dei sistemi AWS.

PHP2Shell interessa direttamente i servizi della pubblica amministrazione italiana: una prima ricognizione del CERT-AGID ha individuato 650 URL che dichiarano versioni PHP potenzialmente vulnerabili, pari al 3,2% degli indirizzi raggiungibili nel campione ricavato dall’Indice delle Pubbliche Amministrazioni (IPA). È un dato di esposizione preliminare, non un elenco di enti compromessi. In parallelo, Amazon Web Services ha pubblicato il bollettino 2026-150-AWS sulle chiavi crittografiche eMudhra e sulla rimozione di certificati considerati non affidabili dai servizi cloud. I due problemi sono tecnicamente distinti, ma pongono agli amministratori italiani una questione comune: verificare quali componenti siano effettivamente aggiornati e quali dipendenze esterne possano ancora compromettere la sicurezza dei servizi digitali.

PHP2Shell, CERT-AGID trova 650 URL potenzialmente vulnerabili nella PA

Il nuovo avviso del CERT-AGID comunica l’esito della prima scansione avviata il 22 ottobre 2026 sugli indirizzi pubblicati nell’IPA. I 650 URL, equivalenti al 3,2% dei servizi raggiungibili analizzati, esponevano negli header HTTP una versione dell’interprete PHP compatibile con quelle interessate dalle vulnerabilità PHP2Shell. La scansione era passiva: non sono stati inviati exploit e non è stato verificato se un attaccante potesse realmente eseguire codice. Non è possibile ricavare dal numero quante pubbliche amministrazioni distinte siano coinvolte, né quante installazioni risultino ancora vulnerabili dopo gli aggiornamenti. Il risultato può contenere sovrastime perché alcuni fornitori applicano correzioni tramite backport, conservando lo stesso numero di versione; può anche sottostimare l’esposizione perché i server che nascondono PHP negli header risultano difficili da classificare. Inoltre il censimento non comprende automaticamente sottodomini e applicazioni esclusi dal perimetro IPA. CERT-AGID ha avvisato gli enti associati agli indirizzi segnalati, invitandoli a coinvolgere fornitori e amministratori. Rispetto ai 22,6 milioni di istanze PHP potenzialmente esposte nel mondo, questa è una fotografia specifica degli indirizzi censiti nella PA italiana.

Leggi anche: PHP2Shell, rilasciate le patch PHP contro due RCE senza autenticazione

Le amministrazioni devono verificare PHP sul server, non soltanto la versione dichiarata

I due difetti PHP2Shell, CVE-2026-109618 e CVE-2026-109619, sono classificati CVSS 4.0 9,2 e possono consentire, nelle configurazioni vulnerabili, esecuzione remota di codice senza autenticazione. Le versioni corrette distribuite dal progetto PHP sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; per i rami più vecchi occorre verificare le patch del fornitore o pianificare la migrazione. Il bollettino tecnico CERT-AGID sulle due RCE richiama l’attenzione su Apache mod_php e sulle condizioni che possono riguardare anche PHP-FPM. Controllare php -v sulla console non basta: la versione dell’interprete da riga di comando può essere diversa da quella utilizzata dai processi Web. Occorre verificare pacchetti, changelog, backport, riavvio dei worker e applicazioni raggiungibili. Non basta aggiornare WordPress, Drupal o i plugin, perché la falla è nell’interprete. Una terza vulnerabilità, CVE-2026-115560, presenta condizioni di sfruttamento molto più ristrette e al 24 ottobre non disponeva ancora di una patch ordinaria; in specifici ambienti può essere mitigata disabilitando session.upload_progress.enabled, dopo aver valutato l’impatto applicativo. La nuova ricognizione italiana non sostituisce gli aggiornamenti, ma permette di definire priorità operative sui servizi istituzionali.

AWS segnala CVE-2026-111943: otto chiavi eMudhra recuperabili

Il Security Bulletin AWS 2026-150, pubblicato il 24 ottobre secondo l’orario Pacifico, riguarda CVE-2026-111943, problema di generazione delle chiavi delle autorità intermedie eMudhra/emSign. Otto chiavi private, sei per TLS e due per la firma del codice, erano state generate con valori matematicamente minuscoli anziché con segreti crittograficamente robusti. Di conseguenza potevano essere recuperate senza strumenti specialistici, creando la possibilità di emettere certificati fraudolenti contro client che continuassero a fidarsi delle catene interessate. Non si tratta di un’intrusione nei sistemi AWS: il difetto origina da una Certificate Authority esterna, ma coinvolge gli archivi di fiducia impiegati da AWS per verificare connessioni TLS in uscita verso identity provider, server di origine e webhook. Amazon indica tre radici coinvolte: AAA Certificate Services, emSign Root TLS CA – G3 ed emSign ECC Root CA – G3. L’autorità emittente ha revocato gli intermedi il 18 ottobre e quella di firma incrociata il 19 ottobre; i client che verificano le revoche tramite OCSP o CRL e interrompono la connessione in caso di controllo fallito non sono interessati dal percorso d’attacco descritto da AWS. La crisi delle otto chiavi intermedie eMudhra era già nota: il fatto nuovo è il piano tecnico di rimozione nei diversi servizi Amazon.

CloudFront e autenticazione AWS, le scadenze dal 28 ottobre al 2 novembre

AWS dichiara di avere distribuito il 21 ottobre la rimozione delle radici interessate dall’archivio di fiducia condiviso e di avere aggiornato STS e Cognito. Sono già disponibili aggiornamenti per Amazon Linux 2 e Amazon Linux 2023, con il comando sudo yum update ca-certificates, e per Amazon Corretto; gli sviluppatori Python devono verificare l’uso di botocore 1.43.117 o successivo. Alcune tappe sono però ancora future: CloudFront prevede di completare la rimozione dal proprio archivio dei certificati edge entro il 28 ottobre, mentre gli Application Load Balancer esistenti con autenticazione OIDC o JWT sono in aggiornamento tra il 29 e il 31 ottobre; quelli di nuova creazione saranno protetti entro il 2 novembre, secondo il bollettino. Per i clienti con identity provider i cui certificati dipendono dalle radici interessate, AWS raccomanda la sostituzione entro il 28 ottobre. Anche i certificati delle origini CloudFront potrebbero non essere più accettati quando la catena perde fiducia, causando errori TLS pur in assenza di attacchi. Restano programmati aggiornamenti per Bottlerocket, RDS per SQL Server ed EMR. La decisione di eMudhra di uscire dal mercato internazionale dei certificati HTTPS rende essenziale verificare non soltanto la scadenza formale del certificato, ma l’intera catena e le librerie che la convalidano.

Continua con:

AWS Strands Agents, falla può esporre le conversazioni tra tenant

CISA conferma exploit su Arista e Collabora, Cisco e AWS lanciano nuovi allarmi

PA italiane e fornitori cloud, quali controlli servono immediatamente

Le due allerte non indicano la stessa vulnerabilità e non provano compromissioni nelle amministrazioni italiane. PHP2Shell interessa l’esecuzione di codice sui server che utilizzano interpreti PHP vulnerabili; eMudhra interessa la fiducia crittografica accordata a determinati certificati nei client e nei servizi cloud. Per responsabili della transizione digitale, CISO, gestori di siti istituzionali e fornitori SaaS, la verifica dovrebbe produrre due evidenze distinte: per PHP, versione e patch realmente presenti sui processi che servono le richieste Web; per AWS, catene TLS degli endpoint federati, origini CloudFront, versioni degli archivi di fiducia e calendario degli aggiornamenti. La mancata notifica CERT-AGID non esclude un sistema vulnerabile, così come l’assenza di errori HTTPS oggi non garantisce che un endpoint continui a funzionare dopo la rimozione di una CA. È opportuno registrare esiti, date e responsabilità del fornitore, effettuare prove di connessione prima delle scadenze AWS e predisporre un piano di ripristino. La novità sostanziale è passare dalle allerte generiche ai controlli documentabili sui servizi pubblici italiani e sulle dipendenze crittografiche del cloud, senza confondere un’esposizione potenziale con un attacco riuscito.