Outlook CVE-2026-124194: falla di spoofing sfruttata espone l'hash NTLM
Microsoft corregge CVE-2026-124194, falla di spoofing di Outlook già sfruttata: aprire un file fa trapelare l'hash NTLMv2 senza alcun avviso.
Pubblicato da Zero Hunt, un red team AI autonomo su un'appliance on-premise con AI privata: penetration test automatizzato per reti e infrastrutture, in black box o gray box, con una persona che approva ogni passo che conta.
Il Patch Tuesday di novembre 2026 di Microsoft contiene una falla di Outlook già usata contro bersagli reali. CVE-2026-124194 è una vulnerabilità di spoofing in cui Outlook si collega a una risorsa controllata dall'attaccante senza mostrare l'avviso sui contenuti esterni su cui fai affidamento — e così facendo consegna il tuo hash di autenticazione NTLMv2. Microsoft la valuta solo "Moderate", CVSS 6.5, ma le applica l'etichetta che conta più di qualsiasi punteggio: Exploitation Detected. Un 6.5 che viene sfruttato batte un 9.8 che non lo è.
Notizia in evoluzione — pubblicata alle 19:30 (18:30 UTC) del 10 novembre 2026. Aggiornata man mano che Microsoft e CISA pubblicano.
In breve
| CVE | CVE-2026-124194 |
| Prodotto / versioni colpite | Microsoft 365 Apps for Enterprise (32-bit · 64-bit); Microsoft Office LTSC 2024; Microsoft Office LTSC 2021 |
| Corretta in | Office LTSC 2024 build 16.0.17932.21140; Office LTSC 2021 build 16.0.14334.21048; Microsoft 365 Apps tramite le Office security releases del 10 novembre 2026 |
| CVSS | 6.5 Moderate · CVSS 3.1 · assegnato da Microsoft · AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N |
| Sfruttata attivamente | Sì — Microsoft ("Exploitation Detected") |
| CISA KEV | Non presente (catalogo versione 2026.11.09) |
| PoC pubblico | Nessuno pubblico al 2026-11-10 |
| Advisory ufficiale | MSRC CVE-2026-124194 |
Cosa fa davvero CVE-2026-124194
La classe è vecchia e la lista delle correzioni continua a riaprirla. Outlook elabora un messaggio o un file Office e, da qualche parte in quell'elaborazione, viene indotto a raggiungere un percorso remoto — un percorso UNC, un URL WebDAV, una risorsa su un server controllato dall'attaccante. Windows autentica premurosamente quella connessione in uscita con le credenziali dell'utente connesso. Ciò che attraversa la rete non è una password ma una risposta NTLMv2: un challenge-response derivato dall'hash NTLM dell'utente. Catturala e puoi crackarla offline oppure, più pericoloso, rilanciarla in tempo reale (relay) verso un altro servizio che accetta ancora NTLM — Exchange, LDAP, un file server, un'applicazione web interna — e agire come quell'utente.
Le FAQ di Microsoft per questa CVE sono insolitamente dirette sul risultato:
Questa vulnerabilità divulga l'hash NTLMv2 di un utente all'attaccante, che potrebbe usarlo per autenticarsi come l'utente.
La vulnerabilità è classificata come CWE-356: Product UI does not Warn User of Unsafe Actions. È tutto il bug in una riga: l'avviso sui contenuti esterni che normalmente dà all'utente la possibilità di dire "no" non compare, quindi la fuga avviene con un singolo clic e nulla a schermo da mettere in dubbio. Due dettagli dell'advisory restringono lo scenario e vanno detti con precisione:
- Il Riquadro di anteprima non è un vettore d'attacco. La vittima deve aprire davvero il file costruito, non limitarsi a selezionare il messaggio. È una mitigazione concreta contro il caso puramente zero-click.
- È richiesta interazione utente (
UI:R): l'attaccante invia un file Office malevolo e convince l'utente ad aprirlo. È un bug veicolato via phishing, non wormable.
Se suona familiare, è giusto così. CVE-2023-23397 — il bug del promemoria di Outlook usato da un attore state-aligned tra il 2022 e il 2023 — era lo stesso meccanismo di fuga delle credenziali, innescato da un percorso del suono di promemoria costruito ad hoc. Il settore ha bloccato quel trigger specifico; il problema di fondo, "Outlook si autentica in uscita se riesci a fargli raggiungere qualcosa", è riemerso su un percorso diverso. CVE-2026-124194 è l'istanza 2026, e questa volta il flag di sfruttamento era attivo il giorno stesso della patch.
Chi è esposto e come verificare
I prodotti colpiti sono i tre canali di manutenzione attuali di Office:
- Microsoft 365 Apps for Enterprise (32-bit e 64-bit) — il canale Click-to-Run che usa la maggior parte delle aziende.
- Microsoft Office LTSC 2024 — corretta nella build
16.0.17932.21140. - Microsoft Office LTSC 2021 — corretta nella build
16.0.14334.21048.
Verifica la build installata da qualsiasi app Office: File → Account → Informazioni su Outlook, oppure interroga la versione Click-to-Run nel registro:
reg query "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" /v VersionToReport
Se la build riportata è inferiore a quella corretta per il tuo canale, sei esposto.
Remediation
1. Sono interessato?
Conferma la build di Outlook/Office come sopra. Qualsiasi installazione di Microsoft 365 Apps, Office LTSC 2024 o Office LTSC 2021 non ancora alla build di sicurezza del 10 novembre 2026 è interessata.
2. Patch — versioni corrette esatte
Aggiorna a Office LTSC 2024 16.0.17932.21140, Office LTSC 2021 16.0.14334.21048, o alla build di sicurezza attuale di Microsoft 365 Apps elencata nell'indice delle Office security releases di novembre 2026. Gli aggiornamenti Click-to-Run si applicano al riavvio di Office; forza l'aggiornamento invece di attendere la finestra di manutenzione, trattandosi di un bug già sfruttato.
3. Non puoi aggiornare tutti stasera? Controlli compensativi
L'exploit dipende dal fatto che il client raggiunga un server dell'attaccante e vi si autentichi via NTLM. Taglia una delle due gambe:
- Blocca l'SMB in uscita sul perimetro. Nega l'egress TCP 445 e 139 verso internet sul firewall. Non c'è quasi mai un motivo legittimo perché una workstation parli SMB con un host esterno arbitrario, e questo spezza il percorso di relay più comune.
- Limita l'NTLM in uscita. Usa l'impostazione di Group Policy Sicurezza di rete: limita NTLM: traffico NTLM in uscita verso server remoti — impostala prima su Audit per dimensionare l'impatto, poi su Deny all per gli account che non hanno motivo di autenticarsi fuori rete.
- Imponi l'SMB signing così che qualsiasi risposta catturata non possa essere rilanciata verso i file server interni.
- Rinforza il messaggio all'utente: su un bug di phishing già sfruttato, il controllo tampone è "non aprire allegati Office inattesi", sostenuto dal sandboxing degli allegati sul gateway di posta.
4. Cerca segni di compromissione
Non esiste ancora una lista di IOC dal vendor per questa CVE, quindi cerca sul comportamento, non sugli hash:
- Autenticazioni SMB/WebDAV/HTTP in uscita verso host esterni mai visti prima, originate da
OUTLOOK.EXEo da sessioni WebClient mediate dasvchost. - Event ID 4624/4648 di Windows Security che mostrano logon NTLM verso destinazioni esterne, e avvii del servizio WebClient su host dove di norma è inattivo.
- Correla a MITRE ATT&CK T1187 Forced Authentication, T1557.001 (avvelenamento LLMNR/NBT-NS e SMB relay) e al successivo T1550.002 Pass the Hash / movimento laterale T1021 se un relay è riuscito.
5. Eradica e verifica
Se trovi prove che una risposta NTLMv2 ha lasciato l'ambiente, tratta il segreto dell'account esposto come compromesso: forza il reset della password e invalida le sessioni attive, verifica cosa può raggiungere quell'identità via NTLM, e conferma che l'egress 445/139 sia davvero bloccato sul bordo. Poi ri-testa inviando un file innocuo che inneschi un fetch esterno e verificando che nessuna credenziale lasci l'host — la patch non è "finita" finché il percorso di fuga non è dimostrato chiuso, non supposto chiuso.
Cosa non si sa ancora
- Nessun record NVD e nessun CVSS da NIST — alla pubblicazione NVD non ha ancora ingerito CVE-2026-124194; l'unico punteggio è il 6.5 di Microsoft.
- Non ancora su CISA KEV (catalogo 2026.11.09). Un bug Microsoft già sfruttato è un forte candidato a un inserimento a breve con scadenza BOD 26-04; ricontrolla il catalogo.
- Nessuna attribuzione, nessun IOC, nessun PoC pubblico. Microsoft dichiara lo sfruttamento rilevato ma non ha pubblicato chi, quanto diffusamente o contro chi.
- Il trigger esatto in uscita (quale tipo di file Office e quale proprietà forza il fetch) non è stato divulgato: per questo i controlli perimetrali e su NTLM contano più di qualsiasi blocco su un singolo tipo di file.
Chiudere la finestra mentre il parco macchine si aggiorna
Il problema onesto di un bug così è la sequenza. Non puoi riavviare Office su ogni endpoint nell'ora dopo il Patch Tuesday, e "Exploitation Detected" significa che l'orologio è già partito. Quindi la prima domanda non è quale macchina non è aggiornata — a questo risponde una scansione di versione — ma quale correzione, in quale ordine, impedisce davvero alla credenziale di uscire. È il lavoro che fa l'AI Remediation Advisor di Zero Hunt: classifica l'esposizione per sfruttabilità reale (prima CISA KEV, poi ciò che questo motore ha dimostrato raggiungibile nel tuo ambiente, poi CVSS, poi EPSS), e per CVE-2026-124194 fornisce la build corretta esatta con nota di rollout e rollback più il controllo compensativo — blocca l'SMB in uscita, limita l'NTLM in uscita — per gli host che non possono aggiornare stasera, poi ri-verifica che il percorso di fuga sia chiuso con lo stesso test che lo ha dimostrato. Un red team AI autonomo che gira on-premise su modelli privati, con una persona che approva ogni passo, significa che gli hash degli account su cui ragiona non lasciano mai il tuo apparato.
La seconda metà è la rilevazione durante la finestra di patch. Una fuga di autenticazione forzata è invisibile nel log applicativo — l'utente ha cliccato, Outlook ha obbedito, nulla ha avvertito — ma è rumorosa sul filo: un'autenticazione in uscita verso una destinazione con cui l'host non ha mai parlato. L'AI Traffic Analysis di Zero Hunt fa girare un modello di deep learning con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) a velocità di linea multi-gigabit sulla GPU dell'apparato, così l'egress NTLM anomalo viene segnalato mentre sta accadendo, non nel digest SIEM della mattina dopo. Validarlo da capo a fondo — un file costruito forza davvero un fetch, e cosa può raggiungere un hash rilanciato — è esattamente ciò che il penetration testing automatizzato dimostra sulla tua build installata, non su una stringa di versione. È lo stesso schema di bypass dell'avviso che abbiamo raccontato nel bypass del Mark-of-the-Web di Windows Shell: l'interfaccia che avrebbe dovuto lasciare all'utente la possibilità di dire "no" non ha mai chiesto. Inizia la conversazione da contatti.
Tutte le vulnerabilità che CISA segnala come sfruttate, con le scadenze federali: tracker CISA KEV →
Una patch per ogni CVE? Un programma CTEM verifica quali esposizioni sono davvero sfruttabili prima del prossimo advisory: cos'è il CTEM →
È sfruttabile nel tuo ambiente?
Zero Hunt lo verifica sulla tua rete: un red team AI autonomo su un'appliance on-premise, con AI privata, in black box o gray box e con una persona che approva ogni passo che conta. La prova di cosa è sfruttabile, la correzione e le evidenze firmate — nessun dato esce dal tuo perimetro.