CyberQuake, Via Francesco Domenico Guerrazzi, 23, Florence (2026)

03/09/2026

Dall'11 settembre lo stesso attacco può obbligarti a tre notifiche diverse.
Con tre destinatari diversi. La più stretta corre in 24 ore.

Il Cyber Resilience Act aggiunge un obbligo nuovo: chi immette sul mercato UE prodotti con elementi digitali deve notificare una vulnerabilità attivamente sfruttata entro 24 ore dalla scoperta, con un report più dettagliato entro 72 ore (Agenda Digitale, ICT Security Magazine).

La notifica passa dalla Single Reporting Platform di ENISA, diretta al CSIRT del proprio Stato. Per l'Italia: CSIRT Italia / ACN.

Il punto non è la scadenza. Quella la conoscono tutti ormai.

Il punto è che il CRA non sostituisce nulla. Si affianca. Un singolo incidente può quindi far scattare fino a tre canali distinti:

📊 CRA → vulnerabilità sfruttata su un prodotto digitale (24h a ENISA)
NIS2 → se sei soggetto essenziale o importante in perimetro
GDPR → se nell'incidente ci sono dati personali

Soglie diverse. Destinatari diversi. Orologi diversi che partono nello stesso momento.

E qui la mappa la si costruisce prima, non a caldo. Perché durante un attacco nessuno ha 24 ore per capire chi chiamare e in che ordine.

La compliance non è il documento. È sapere, alle 3 di notte, chi preme quale gr*****to.

Nella vostra organizzazione esiste già una mappa scritta "un incidente → quali notifiche, a chi, entro quante ore"? E chi ha il mandato di far partire le 24 ore CRA: DPO, legale, IT o board?

02/09/2026

Tra la pubblicazione della vulnerabilità e il primo furto di chiavi sono passate ore.

Non settimane. Ore.

La CVE-2026-0768 su Langflow (CVSS 9.8) permette a un attaccante di eseguire codice come root. Langflow è una piattaforma low-code per costruire agenti AI: il tipo di strumento che un team installa "per fare prima", spesso senza dirlo all'IT.

VulnCheck ha registrato oltre 50 detection di sfruttamento nelle prime ore dal 30 agosto (fonte: The Hacker News). Il bottino: chiavi API OpenAI e AWS. Le stesse chiavi che pagano le tue bollette cloud.

Stesso copione su Ruby on Rails (CVE-2026-66066, CVSS 9.5): lettura file arbitrari, furto di credenziali, codice remoto. Disclosure, poi sfruttamento nel giro di ore.

Qui la lettura di CyberQuake è una: il problema non è Langflow, che è software open-source con una CVE come tanti. Il problema è lo strumento AI in produzione che non sta in nessun inventario e non ha nessuno responsabile della patch.

Il patch management classico ragiona a settimane. La shadow AI ha portato in casa asset che vanno patchati in ore. Il calendario è cambiato. La governance no.

Non serve vietare gli strumenti AI. Serve sapere che esistono, dove girano e chi li aggiorna.

Nella tua azienda, chi tiene l'inventario degli strumenti AI in produzione, e chi ha il mandato di patcharli entro 24 ore da una CVE critica? L'IT, il team che li ha installati, o nessuno finché non succede qualcosa?

01/09/2026

Il pericolo di un data breach contabile non è che qualcuno entri nel tuo conto.
È che qualcuno ti scriva una mail perfetta con dentro i tuoi numeri veri.

Dopo l'accesso non autorizzato al servizio "Contabilità in Cloud" di TeamSystem (rilevato il 24 agosto), sono usciti anagrafiche, IBAN, importi e descrizioni di operazioni reali. Le credenziali degli utenti non risultano compromesse (Cybersecurity360, Agenda Digitale, Federprivacy).

Traduzione per uno studio professionale: chi ha quei dati non attaccherà i vostri account. Costruirà una frode su misura.

Una richiesta di cambio IBAN con importi coerenti, controparti reali, tono credibile. La classica truffa del bonifico, ma senza gli errori che di solito la smascherano.

Contro questo tipo di frode la tecnologia serve poco. Serve una procedura. Tre controlli, applicabili da lunedì mattina:

1. Ogni cambio di IBAN si verifica fuori banda. Si richiama la controparte su un numero già in rubrica, mai quello indicato nella mail.

2. Doppia firma sopra una soglia. Sopra un certo importo, nessun pagamento a coordinate nuove parte con l'ok di una sola persona.

3. La fretta è un segnale, non una scusa. "Urgente, entro oggi" è il tratto più ricorrente delle frodi BEC. Più è urgente, più si verifica.

Nessuno di questi tre passaggi costa denaro. Costano trenta secondi e la disciplina di non saltarli quando c'è coda in segreteria.

Nel vostro studio, chi autorizza un cambio di IBAN di un fornitore: c'è una regola scritta, o si decide di volta in volta quando arriva la mail?

27/08/2026

Due organizzazioni. Stesso red team. Tecniche comparabili.
Una l'ha visto arrivare. L'altra non si è accorta di niente.

Il CISA ha condotto due assessment in parallelo su infrastrutture critiche USA — dettagli riportati da The Hacker News. Entrambe compromesse fino al controllo del dominio. Ma una delle due non ha rilevato nessuna delle attività del red team per l'intera durata dell'esercizio.

Stessa tecnica. Attaccante equivalente. Esito di detection opposto.

La variabile differenziante non erano gli strumenti.

Ecco la parte scomoda per chi sta in trincea: "abbiamo l'EDR, abbiamo un SOC, abbiamo il SIEM" non è una frase sulla detection. È una frase sull'acquisto.

Avere sensori accesi non vuol dire vedere. Vuol dire che i dati passano. Poi qualcuno deve averli tunati, correlati, letti — e messi alla prova contro chi cerca davvero di non farsi vedere.

La differenza tra le due organizzazioni CISA non era nel budget speso in licenze. Era in cosa succedeva a valle di quei sensori.

Uno strumento di detection non configurato e mai testato non è una protezione. È una ricevuta.

Nella tua azienda, quando è stata l'ultima volta che la capacità di rilevamento è stata messa alla prova da qualcuno che provava sul serio a non farsi vedere, non da un alert di test? E quel test lo decide l'IT o il board?

26/08/2026

Il 75% delle estensioni AI chiede permessi alti o critici. Il 16,3% ha già CVE note.

E quasi metà dell'uso AI in azienda non passa dai tuoi controlli. Secondo Akamai.

Sono i numeri del report Akamai SOTI 2026. Vanno letti con l'attribuzione: è una fonte vendor. Ma il quadro che disegnano è difficile da ignorare per chi costruisce prodotto.

Perché l'immagine mentale dello "shadow AI" è ancora quella sbagliata.

Non è l'impiegato che incolla dati in ChatGPT. Quello lo governi con una policy.

È lo strato di strumenti che i team tecnici adottano per lavorare meglio: assistenti di codice, estensioni, agenti che eseguono azioni. Tutti con permessi elevati. Quasi mai censiti.

Un attaccante non ha bisogno di forzare il tuo firewall se può vivere dentro un'estensione che il tuo dev ha già installato e autorizzato.

Il report lo chiama "CursorJacking": estensioni malevole che sottraggono API key e codice dagli assistenti di sviluppo. Sullo stesso filone, ricercatori hanno mostrato come una pagina web possa iniettare istruzioni in un'istanza AI locale. Il prompt injection è uscito dai paper ed è entrato nelle disclosure con vendor coinvolti.

Non si difende ciò che non si è mai censito.

Domanda seria, non retorica: nella tua azienda l'adozione di strumenti AI dai team tecnici è tracciata da qualche parte, o la mappa esiste solo nella testa di chi li usa?

24/08/2026

"Non ci hanno mai attaccati, quindi siamo a posto."

È la frase che sentiamo più spesso. Ed è esattamente il motivo per cui il problema resta invisibile fino al giorno in cui non lo è più.

Truffle Security ha analizzato repository pubblici, cronologie Git, dataset e immagini Docker da agosto 2022 ad agosto 2026.

Ha trovato 64.024 chiavi AWS uniche. Tra quelle verificabili, l'88% era ancora attiva al 10 agosto 2026 (fonte: Truffle Security via BleepingComputer).

Non chiavi teoriche. Non chiavi revocate. Attive.

Nel dataset complessivo: 526 chiavi root e 242 con AdministratorAccess. Accesso completo all'infrastruttura, in mano a chiunque abbia scaricato un repo.

Il dettaglio che pesa di più: età mediana delle chiavi 1.831 giorni, circa 5 anni. Solo il 13,7% era stato ruotato almeno una volta.

Cinque anni. Nessuno le monitorava.

Una credenziale esposta non fa rumore. Nessun alert, nessun sintomo. Funziona in silenzio finché qualcuno decide di usarla. Ecco perché "non ci hanno mai attaccati" non è una prova di sicurezza: è l'assenza di una prova.

Il dato è globale, ma AWS è l'infrastruttura di base di migliaia di startup e PMI italiane. Il problema non è "grande azienda americana". È chiunque abbia un repo e un cloud.

La domanda giusta non è "siamo stati attaccati?". È: quante access key attive abbiamo, quanti anni hanno, e chi potrebbe averle già viste?

Nella tua azienda, chi è responsabile di sapere quante access key sono attive in questo momento, e ogni quanto vengono ruotate? Se la risposta è "nessuno di preciso", è lì che comincia il problema.

20/08/2026

Hai attivato l'MFA su Microsoft 365.
Su 23 aziende colpite di recente, 15 avevano fatto lo stesso. Gli attaccanti sono entrati comunque.

Non è un exploit sofisticato. È un buco di configurazione. E riguarda il tuo tenant, non un report americano astratto: quasi ogni PMI e media azienda italiana gira su M365/Azure.

Il meccanismo è freddo. Un flusso di autenticazione legacy chiamato OAuth ROPC manda username e password direttamente all'endpoint /token. Salta del tutto l'MFA interattiva. Nessun codice, nessuna push da approvare.

Nella campagna analizzata da Huntress: oltre 81 milioni di tentativi di login in due settimane contro Azure. Password spraying cresciuto di 155 volte nel primo semestre 2026.

E delle 23 organizzazioni colpite, 15 avevano l'MFA attiva. Scope errato, esclusioni per location troppo larghe, Conditional Access lasciato in report-only. L'etichetta diceva "MFA: ON". La porta era aperta.

Quindici tenant su ventitré con l'MFA accesa. E aperti lo stesso.

L'MFA non è quello che attivi. È quello che verifichi.

Nella tua azienda l'MFA su Microsoft 365 è stato "attivato" o è stato "verificato"? Chi ha controllato l'ultima volta se i flussi legacy sono ancora aperti, e quando?

17/08/2026

Squilla il telefono. "Salve, sono dell'assistenza IT, stiamo sistemando un problema urgente sul suo account, mi conferma il codice che le è appena arrivato?"

In questa frase c'è un intero data breach.

È successo davvero. RingCentral, piattaforma di comunicazione cloud con oltre 600.000 aziende clienti, ha visto esposti 1,6 milioni di account. Nome completo, email, telefono, indirizzo di casa. Tutto pubblicato, anche se l'azienda ha fatto la cosa giusta e non ha pagato il riscatto.

Il punto d'ingresso non è stato un software da aggiornare. È stata una persona convinta a cedere le proprie credenziali.

Ora fai un esercizio. Pensa a chi, in azienda, alza la cornetta più spesso: reception, amministrazione, il commerciale sempre di fretta.

Se domani ricevono quella telefonata, sanno cosa fare?

La maggior parte delle PMI italiane investe in firewall e antivirus, e fa bene. Ma nessuno ha mai spiegato a chi risponde al telefono che una voce cortese e sicura di sé è oggi un vettore d'attacco, esattamente come un allegato infetto.

Quei dati rubati, poi, non restano fermi: email e numeri reali diventano la base per la prossima telefonata, ancora più credibile.

La sicurezza di una PMI si gioca anche su chi, in azienda, è autorizzato a fidarsi di una voce al telefono.

Da voi, quando una richiesta urgente arriva per telefono, esiste una regola scritta per verificarla su un secondo canale? O ci si affida a chi risponde?

14/08/2026

Hai speso un budget importante per l'EDR, l'antivirus "di ultima generazione".
Poi qualcuno riavvia il PC in modalità provvisoria e il tuo scudo, semplicemente, non si accende.

Non è fantascienza. È una tecnica che un affiliato del ransomware Akira ha usato di recente.

La sequenza è banale, ed è questo che deve farti pensare.

Riavvio della macchina Windows in modalità provvisoria con rete (la schermata "base" che si usa per riparare un PC). In quella modalità molti agenti EDR non partono: il loro servizio resta spento.

Con lo scudo a terra, i dati vengono copiati fuori.

Nessuna zero-day, nessun exploit da film. È l'abuso di una funzione legittima di Windows, il boot in modalità provvisoria, catalogato da MITRE ATT&CK come T1562.009 (Safe Mode Boot). Documentata da anni. Nota. Non teorica.

La lezione non è "l'EDR non serve". L'EDR è la scelta giusta.

La lezione è che un prodotto è una difesa, non una garanzia. La protezione non è quello che compri: è il presidio che gli metti intorno.

Tre domande da girare oggi al tuo IT o al tuo fornitore:

1. Il nostro EDR ha la tamper protection? (blocca disinstallazione e avvio in modalità provvisoria)
2. Ci arriva un allarme se un PC aziendale parte in modalità provvisoria fuori orario?
3. Abbiamo backup offline o immutabili, che restano al sicuro anche se l'endpoint cade?

Se su una di queste la risposta è "ci devo pensare", quella domanda vale già l'investimento.

Quanto tempo ci metterebbe il tuo fornitore a rispondere alla domanda 1 con certezza, senza "ti richiamo"?

13/08/2026

Gunra non ha usato nessuna zero-day per entrare.
Ha usato due falle Fortinet già patchate da oltre un anno.

L'11 agosto FBI, CISA e l'agenzia sudcoreana hanno emesso un advisory congiunto (AA26-222A). Non è materia da tech blog. È materia da mettere sul tavolo del CFO.

Ecco cosa è successo, in ordine.

Gunra è entrata sfruttando CVE-2024-55591 (FortiOS) e CVE-2025-24472 (FortiProxy). Due vulnerabilità note, con patch disponibile da mesi.

Poi ha aggirato l'MFA. Non l'ha bucato: ha manipolato i file di autenticazione della SSL-VPN. L'MFA sembrava attivo. Non lo era più.

Infine, doppia estorsione: cifratura dei dati più esfiltrazione. 51 vittime documentate tra healthcare, financial services e professional services, con presenza europea confermata nell'advisory.

Il punto che ci interessa non è il prodotto. È il processo.

Una patch non installata non resta ferma: invecchia contro di te. Ogni settimana che passa è una settimana in cui la porta resta aperta e qualcuno impara a trovarla.

Il perimetro non è un oggetto che compri una volta. È un processo che mantieni.

Fortinet è tra i firewall più diffusi nelle reti italiane. Chi non ha un ciclo di patching disciplinato sulle appliance esposte è nel raggio d'azione oggi, non in astratto.

Nella tua azienda, chi ha in carico — con nome e cognome — l'aggiornamento delle appliance perimetrali? E qual è la finestra massima tra la pubblicazione di una CVE critica e la patch installata: 24 ore, una settimana, o "quando capita"?

CyberQuake

03/09/2026

02/09/2026

01/09/2026

27/08/2026

26/08/2026

24/08/2026

20/08/2026

17/08/2026

14/08/2026

13/08/2026

Indirizzo

Sito Web

Notifiche

Contatta L'azienda

Scelte rapide

Condividi

Digitare

Richiesta di rimozione dell’inserzione