Microsoft ha dichiarato guerra alle anteprime in Esplora File

Con gli aggiornamenti di sicurezza di ottobre 2025 (in particolare quelli applicati alle build Windows 11 24H2 e 25H2 e a Windows 2025, ma non solo su quelle), Microsoft ha introdotto una modifica che sta avendo un impatto pesante su tutte le aziende e organizzazioni: Explorer (o Esplora File) non mostra più l’anteprima dei file scaricati da Internet.

La decisione è stata presa per chiudere una vulnerabilità pericolosa, legata al rischio di esfiltrazione di credenziali e altri dati sensibili attraverso l’anteprima di certi file creati ad hoc.

Sicurezza sempre, ma la produttività?

Il problema è che Microsoft non ha lavorato col cesello ma ha deciso che tutti i file non specificamente definiti come sicuri siano considerati “scaricati da Internet”, compresi file già presenti sul computer o, peggio, provenienti da percorsi di rete locale.

Quindi la modalità con cui la modifica è stata applicata, improvvisa, rigida e profondamente invasiva, sta creando notevoli difficoltà in ambienti reali, sia per gli utenti finali sia per chi gestisce infrastrutture IT.

Il risultato? Una delle funzioni più utilizzate in Esplora File è diventata inaccessibile proprio per quel pubblico che ne dipende di più.

Una vulnerabilità concreta, una soluzione drastica

Microsoft ha spiegato che il preview pane può essere sfruttato da file contenenti riferimenti a risorse esterne su server remoti (HTML incorporato, immagini remote, link SMB, ecc.). Quando la preview cerca di caricare tali elementi, Windows tenta un’autenticazione automatica verso il server remoto, esponendo le credenziali dell’utente, che poi possono essere riutilizzate o esfiltrate.

Un rischio? Sì, senza dubbio. Una mitigazione necessaria? Probabilmente sì.
Ma la scelta di disabilitare praticamente ogni anteprima per qualsiasi file marcato con Mark of the Web (MoTW, ossia Marchio del web, che in teoria identifica i soli file scaricati da Internet), compresi quelli provenienti da percorsi di rete non perfettamente classificati come Intranet o Siti Attendibili, è una risposta da “tutto o niente” che colpisce soprattutto chi lavora sui file più utilizzati: PDF, immagini, documenti Office.

Per molti utenti, la preview di Explorer non è un extra: è parte fondamentale del lavoro quotidiano. Revisionare rapidamente file, sfogliare documenti senza aprirli, individuare il contenuto corretto tra decine di PDF: senza anteprima, tutto rallenta.

Il problema esplode nel mondo reale

Nella nuova configurazione, che Microsoft definisce una feature di sicurezza e non un bug, gli utenti vedono al posto della solita e confortante anteprima un messaggio che dice che il file non può essere mostrato perché potenzialmente dannoso per il PC.

Suggerisce anche di aprire il file, che è esattamente l’azione che l’utente che usa l’anteprima vuole evitare. Peraltro senza controllarlo, cosa che scatena un minimo di dissonanza cognitiva: se è pericoloso, mi consigli di aprirlo?

La scelta di Microsoft ha innescato una serie di conseguenze operative che, in contesti aziendali, si trasformano in un percorso a ostacoli. Si possono riassumere in quattro scenari critici.

1) Aggiornamento a 25H2: anteprime disattivate all’improvviso

Dopo l’aggiornamento, gli utenti scoprono che molte anteprime non funzionano più.
La soluzione, ossia modificare il registro per ignorare la Zone Information o rimuovere manualmente il MoTW, non è alla portata degli utenti comuni e richiede interventi IT su larga scala e/o file per file.

2) Percorsi di rete trattati come Internet

Tutte le condivisioni che non sono Intranet “pura” o Trusted Sites vengono trattate come Internet Zone. Risultato: migliaia di file legittimi, conservati magari da anni su file server aziendali, vengono improvvisamente considerati “a rischio”.

Definire le zone di sicurezza delle risorse è una best practice da decenni, ma ormai dimenticata, perché i sistemi hanno applicato layer di sicurezza diversi nel tempo, come segmentazione, Zero Trust, firewall perimetrali, xDR: le Zone Internet sul PC, per i più, sono una reminiscenza di Internet Explorer. Microsoft con questi aggiornamenti le ha riportate pesantemente alla ribalta.

Pertanto l’IT o l’utente è costretto a:

• ripulire i file dal MoTW,
• aggiungere manualmente i percorsi alla Zona Intranet o Siti Attendibili,
• correggere path e UNC per evitare blocchi ricorrenti.

3) Accesso ai file server tramite IP = autenticazione NTLM = anteprime bloccate

Su sistemi più recenti, aprire un percorso SMB tramite indirizzo IP (una pratica usata da… sempre) forza l’uso di NTLM.
Poiché NTLM è esattamente il protocollo interessato dalla vulnerabilità, Windows applica automaticamente le restrizioni, bloccando ancora una volta la preview.
Soluzione: inserire il nome di dominio completo (FQDN) o al limite il nome del file server, con cambiamento di ogni singolo link messo sul desktop negli anni, e solo in certe notazioni specifiche. Di nuovo operazione non banale in grandi aziende (o anche piccole ma stratificate).

4) Notazioni diverse a seconda della versione di Windows

Per inserire un percorso nella zona intranet o trusted sites, ogni versione recente di Windows supporta logiche diversa:

• versioni di Windows più vecchie sbloccano le anteprime anche aggiungendo l’indirizzo IP come intranet,
• quelle moderne richiedono il nome del server,
• le più recenti richiedono anche il protocollo quindi la forma file://<server>.

Peraltro, inserire l’indirizzo IP era una “brutta pratica” comoda perché superava eventuali problematiche di DNS (che spesso non è perfetto in domini AD non gestiti in modo proattivo). Quindi l’IT non solo deve affrontare le lamentele degli utenti giustamente indispettiti per una funzionalità perduta, ma magari si trova a dover bonificare un server DNS dalla sera alla mattina, processo che è tutt’altro che da fare in volata e sotto stress.

Quindi tutta la gestione diventa complessa e al limite della gestibilità non solo per l’utente finale, ma anche per chi amministra una o più reti.

L’errore? La sicurezza informatica è percepita come un ostacolo

La patch risolve un problema vero, ma il modo in cui è stata distribuita impone un costo molto alto a chi usa normalmente il sistema.

La sicurezza è una componente essenziale dell’ecosistema Windows, ma l’approccio “blocchiamo tutto ciò che potenzialmente potrebbe essere rischioso” è destinato a fallire quando colpisce flussi di lavoro quotidiani e consolidati.

In altre parole: la cura rischia di essere più dannosa della malattia.
Perché?
Perché gli utenti, privati di una funzione chiave, cercheranno scorciatoie come:

• disabilitando policy di sicurezza,
• copiando file localmente,
• aggirando protezioni per riavere le anteprime,
• o sovraccaricando l’IT con ticket e richieste di “ripristinare il funzionamento normale”.

Quindi una patch di sicurezza nata per ridurre il rischio fa sì che questo aumenti perché costringe migliaia di persone a cercare workaround.

E oltretutto passa il messaggio che la sicurezza sia un male perché, quando è applicata così, inibisce la produttività. Come fai ad argomentare al cliente che patchare è necessario e i sistemi vanno tenuti alle ultime versioni, quando un aggiornamento blocca o rallenta l’operatività per giorni o settimane?

Si poteva fare meglio? Sì, decisamente

Microsoft avrebbe potuto scegliere un approccio più equilibrato:

• una policy opzionale e configurabile per azienda,
• una whitelist gestibile centralmente,
• un sistema più trasparente che informa l’utente,
• un meccanismo che blocca solo i contenuti esterni nella preview, non l’intera anteprima,
• strumenti integrati per classificare automaticamente come sicuri i percorsi interni.

Soluzioni tecniche meno invasive esistono e avrebbero ridotto drasticamente l’impatto sugli utenti, senza compromettere la sicurezza.

Tra l’altro, quelle patch sono state rilasciate proprio nel giorno dell’End of Life di Windows 10. Gli utenti stanno già affrontando sostituzioni forzate, cambi di abitudini e nuovi workflow per migrare a Windows 11. Era davvero necessario introdurre aggiornamenti così restrittivi in un momento già di per sé delicato? Forse sì, se c’erano rischi concreti da mitigare; ma è altrettanto possibile che una pianificazione più attenta avrebbe evitato di sovraccaricare un periodo già critico.

Cosa possono fare oggi aziende e amministratori?

Finché Microsoft non introduce un approccio più modulare, le soluzioni pratiche sono:

• Classificare correttamente le condivisioni interne, evitando IP e usando nomi host su Kerberos.
• Rimuovere in modo centralizzato il MoTW per file provenienti da fonti affidabili.
• Aggiungere un valore di registro per singolo utente:

HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments\

SaveZoneInformation = 1

per non preservare le informazioni di zona su file nuovi (ATTENZIONE: questo inibisce del tutto la policy di sicurezza per i nuovi file – e serve riavvio);

• Aggiungere le risorse di rete nella zona Intranet o Siti attendibili, usando le notazioni più compatibili tra versioni (file://<FQDN> o file://<NomeDNS> sono accettati da tutti)
• Verificare che la risoluzione DNS funzioni;
• Se possibile, preparare la rete a queste modifiche prima dell’aggiornamento;
• Monitorare l’impatto sulle attività per decidere eventuali eccezioni.

Non sono soluzioni ideali, abbassano la sicurezza con responsabilità di chi le applica o le impone, e richiedono tempo e coordinamento. Ma sono oggi l’unico modo per riportare la preview a un comportamento accettabile.

“Sicurezza” non deve essere per forza antonimo di “Produttività”

La mossa di Microsoft nasce da una reale esigenza di sicurezza, ma la sua implementazione mostra un limite ricorrente: la tendenza a privilegiare la mitigazione tecnica indipendentemente dal suo impatto sulla produttività reale.

L’anteprima dei file non è una funzione marginale: è una parte essenziale dell’esperienza d’uso, uno strumento di efficienza per milioni di persone.
Bloccarla in modo massivo e improvviso, sulla base di una classificazione spesso opaca dei file “di Internet”, non è una scelta sostenibile.

Il messaggio che arriva agli utenti è chiaro ma problematico: “Non possiamo garantire che il vostro ambiente sia sicuro; quindi, disattiviamo funzioni che riteniamo troppo rischiose. Se volete tornare al funzionamento insicuro, la responsabilità è vostra”.

È una implementazione cieca del paradigma Zero Trust (“presumo che nulla sia sicuro”), che però spazza via anni di stratificazione e punisce anche chi ha negli anni aggiunto altri livelli di sicurezza.

È comprensibile, ma non è accettabile.

La sicurezza non può essere perseguita sacrificando il lavoro di chi usa il sistema. Serve un equilibrio più maturo, e Microsoft dovrebbe ripensare questo approccio: meno interventi “ex machina”, più strumenti per permettere agli amministratori e agli utenti di gestire in modo consapevole e proporzionato i rischi, senza dover scegliere tra sicurezza e usabilità.

E, alla fine, la vera conseguenza è sempre la stessa: la sicurezza, quando è progettata senza attenzione all’uso reale, è percepita come un ostacolo, non come un aiuto. E quindi è più difficile far capire quanto è necessaria.