Siti di enti locali alterati: che cosa insegna il rapporto ACN di agosto 2026

In breve

Nel rapporto operativo relativo ad agosto 2026, pubblicato il 28 settembre, l’Agenzia per la cybersicurezza nazionale segnala diverse decine di siti web alterati tra amministrazioni locali, enti di ricerca, università, associazioni e piccole imprese. Alcuni episodi sono stati collegati allo sfruttamento attivo di una vulnerabilità critica del plugin Pods per WordPress. Il dato non prova che ogni sito di questi settori sia esposto nello stesso modo e non consente di attribuire tutti gli attacchi a quel componente. Mostra però un problema concreto: un portale istituzionale o aziendale può essere compromesso attraverso una dipendenza dimenticata, mentre il titolare continua a considerarlo un semplice servizio di comunicazione affidato al fornitore.

 

Un mese stabile nei numeri, ma non tranquillo per i siti esposti

Ad agosto l’Agenzia ha registrato 309 eventi cyber, quasi gli stessi 305 di luglio, e 185 incidenti, contro i 188 del mese precedente. Questa stabilità non equivale a un livello di rischio immutabile per ogni organizzazione. I dati descrivono ciò che entra nel campo di osservazione dell’Agenzia e dipendono dalle notifiche, dalle attività di monitoraggio e dalle altre fonti utilizzate; non sono una probabilità di attacco per il singolo Comune o per la singola impresa.

Nel quadro del mese emergono comunque tre famiglie di minacce: esposizione di dati, alterazione dei siti web e ransomware. Il rapporto richiama in particolare diverse decine di portali riconducibili ad amministrazioni locali, enti di ricerca, università, associazioni e piccole imprese sui quali sono stati osservati defacement, cioè modifiche non autorizzate delle pagine visibili. Negli episodi descritti l’Agenzia non segnala conseguenze sull’operatività o sulla continuità dei servizi né rivendicazioni. Questo limita la gravità osservata, ma non elimina la necessità di capire come sia avvenuta l’intrusione: una pagina alterata prova che qualcuno ha superato le difese del sito, mentre eventuali creazioni di account, modifiche dei file o accessi a informazioni richiedono verifiche ulteriori.

 

Il plugin vulnerabile spiega alcuni episodi, non tutti

L’Agenzia collega alcuni dei defacement allo sfruttamento attivo di una vulnerabilità del plugin Pods, usato su WordPress per gestire tipi di contenuto e campi personalizzati. La struttura nazionale di risposta agli incidenti informatici, CSIRT Italia, aveva pubblicato un alert il 21 agosto e lo aveva aggiornato il 27 agosto dopo avere rilevato lo sfruttamento della vulnerabilità. Nelle versioni interessate, un attaccante non autenticato poteva aggirare i controlli e ottenere privilegi amministrativi. Il produttore aveva già rilasciato il 14 agosto la correzione per la vulnerabilità richiamata dall’alert; il 31 agosto ha poi pubblicato una nuova versione di sicurezza relativa ad altre vulnerabilità.

È importante mantenere il perimetro della fonte. Il rapporto non afferma che Pods sia all’origine di tutti i siti alterati né che WordPress sia, in quanto tale, inadatto alla pubblica amministrazione. Dice che il componente è stato effettivamente sfruttato in alcuni casi osservati. Da qui discende una verifica mirata per chi lo usa, non una condanna generale della piattaforma o dei plugin.

La prima domanda, quindi, è molto concreta: il sito utilizza Pods e quale versione è installata? La risposta dovrebbe provenire da un inventario aggiornato dei componenti, non dalla memoria del fornitore. Se il plugin è presente, occorre verificare la versione installata e applicare gli aggiornamenti di sicurezza indicati dal produttore. Il semplice aggiornamento, però, chiude la vulnerabilità nota senza dimostrare che il sito non sia già stato compromesso.

 

Dopo l’aggiornamento serve guardare indietro

Quando una vulnerabilità risulta sfruttata attivamente, l’aggiornamento è il primo passo, ma la verifica dovrebbe comprendere ciò che è accaduto prima. Su un portale WordPress significa controllare almeno gli account amministrativi creati o modificati nel periodo interessato, gli accessi anomali, le variazioni dei file, i plugin aggiunti, le password reimpostate e i contenuti pubblicati senza autorizzazione. I registri tecnici del server, dell’applicazione e degli strumenti di sicurezza devono essere conservati abbastanza a lungo da rendere possibile questa ricostruzione.

Un sito che torna a mostrare la pagina corretta non è necessariamente un sito risanato. Ripristinare l’aspetto visibile da un backup può lasciare attivi account illegittimi o file introdotti dall’attaccante; allo stesso modo, cambiare soltanto la password dell’amministratore non rimuove eventuali modifiche al codice. La bonifica richiede di definire il punto di compromissione, verificare l’integrità dei componenti e cambiare le credenziali che potrebbero essere state esposte.

Questa indagine deve essere proporzionata alle evidenze e alla funzione del portale. Se il sito raccoglie dati tramite moduli, newsletter, aree riservate o servizi integrati, una compromissione può coinvolgere dati personali. Il Regolamento generale sulla protezione dei dati considera violazione non solo l’accesso o la divulgazione non autorizzati, ma anche la distruzione, la perdita e l’alterazione accidentale o illecita dei dati. Il defacement, quindi, non prova da solo che si sia verificata una violazione di dati personali, ma non permette neppure di escluderla senza controllare quali dati siano stati alterati, resi indisponibili, distrutti, divulgati o consultati. Se emerge una violazione, occorre poi valutarne i rischi e gli eventuali obblighi di notifica previsti dall’articolo 33.

 

Il contratto con il fornitore non sostituisce il controllo

Molti Comuni e molte piccole organizzazioni affidano all’esterno sviluppo, hosting e manutenzione del sito. È una scelta normale, ma il servizio viene spesso descritto con formule generiche: assistenza, aggiornamenti, backup, sicurezza. Quando si verifica un incidente, quelle parole devono diventare attività verificabili.

Chi decide e finanzia il servizio dovrebbe sapere con quale frequenza vengono installate le correzioni urgenti, chi riceve gli alert, quali componenti sono censiti, per quanto tempo si conservano i log, come si prova il ripristino e in quali tempi il fornitore comunica un possibile incidente. Dovrebbe inoltre poter ottenere un rapporto sintetico sulle operazioni eseguite, senza dipendere da rassicurazioni informali. Il tema riguarda la sicurezza, ma tocca anche la protezione dei dati quando il fornitore tratta informazioni personali per conto dell’ente o dell’impresa.

Il controllo non richiede di trasferire ogni decisione tecnica all’amministrazione. Richiede che responsabilità e soglie di intervento siano chiare. Un fornitore può scegliere come applicare una correzione, mentre il cliente deve poter verificare che la correzione sia stata valutata, eseguita e, quando necessario, accompagnata da una ricerca di compromissioni pregresse.

 

Che cosa verificare adesso

La pubblicazione ACN offre un motivo concreto per aprire il contratto e l’inventario del sito. Per prima cosa occorre stabilire chi gestisce il portale, dove è ospitato e quali componenti sono attivi. Se Pods è presente, va controllata la versione e il gestore tecnico deve verificare la versione installata e applicare gli aggiornamenti di sicurezza indicati dal produttore. Se non è presente, la notizia resta comunque utile per verificare che esista un processo analogo per gli altri plugin, per il tema e per il nucleo WordPress.

Il secondo controllo riguarda gli indizi di compromissione. Account amministrativi inattesi, accessi da origini insolite, modifiche recenti ai file, reindirizzamenti, pagine aggiunte o avvisi degli strumenti di sicurezza richiedono un esame tecnico, non una semplice correzione grafica. Il terzo passaggio riguarda la capacità di recupero: un backup è utile soltanto se è separato dal sistema compromesso, recente, integro e già provato in un ripristino.

Infine serve una catena di comunicazione. Tecnici, responsabile del servizio, vertice, responsabile della protezione dei dati e referente per la sicurezza non devono essere coinvolti tutti nello stesso modo, ma devono sapere chi valuta l’impatto, chi decide il ripristino e chi verifica gli eventuali obblighi di notifica. L’incidente di un sito non va automaticamente trasformato in violazione di dati personali, ma neppure chiuso prima di avere escluso, con elementi sufficienti, che dati personali siano stati distrutti, perduti, alterati, divulgati o consultati senza autorizzazione.

 

Conclusione

Il dato più utile del rapporto ACN non è il confronto fra 309 e 305 eventi. È il collegamento tra episodi osservati su siti reali e una vulnerabilità già nota, corretta dal produttore e tuttavia sfruttata in rete. La correzione può non bastare se chi gestisce il portale non sa con certezza quali componenti siano installati, non ha tempi definiti per gli aggiornamenti urgenti o non cerca tracce di una compromissione precedente.

Per un Comune o una piccola impresa, la manutenzione del portale non è un dettaglio tecnico invisibile. È una parte della continuità del servizio e, quando il sito tratta dati personali, della responsabilità sul loro trattamento. La domanda da portare al fornitore non è soltanto «avete aggiornato?», ma «quali componenti avete controllato, quando li avete aggiornati e quali evidenze avete cercato per escludere una compromissione già avvenuta?».

 

Fonti e riferimenti

• Agenzia per la cybersicurezza nazionale, Online l’Operational summary di ACN con i dati e gli indicatori della minaccia cyber in Italia, 28 settembre 2026.
• Agenzia per la cybersicurezza nazionale, Operational Summary – agosto 2026, pubblicazione PL03/260928/CSIRT-ITA.
• CSIRT Italia, WordPress: rilevato sfruttamento di vulnerabilità nel plugin Pods, alert AL08/260821/CSIRT-ITA, pubblicato il 21 agosto e aggiornato il 27 agosto 2026.
• Pods Framework, Pods 3.3.9.1 Security Release and Backported Releases, 14 agosto 2026.
• Pods Framework, Pods 3.3.9.2 Security Release and Backported Releases, 31 agosto 2026.
• Unione europea, Regolamento (UE) 2016/679, articoli 4, punto 12, e 33.

 

Nota di trasparenza. Questo contenuto è stato predisposto con il supporto di strumenti di intelligenza artificiale ed è stato revisionato dalla redazione iSimply, che ne assume la responsabilità editoriale.