Windows Shell CVE-2026-96951: „Important” w MSRC, zero-day w KEV — bypass Mark-of-the-Web to ogniwo łańcucha, nie RCE

Październikowy Patch Tuesday (13.10.2026) przyniósł poprawkę dla CVE-2026-96951 w Windows Shell. Microsoft opisuje ją jako Security Feature Bypass o wadze Important, ale jednocześnie oznacza „Exploitation Detected”. CISA dodała CVE do KEV tego samego dnia z terminem 16 października. Sam błąd nie wykonuje kodu. Wyłącza za to ostrzeżenie, które miało zatrzymać złośliwy załącznik, zanim użytkownik go uruchomi. To klasyczny przypadek, w którym etykieta producenta i rzeczywiste zagrożenie rozjeżdżają się najbardziej.

Attack path

Dlaczego „Important” to zła podstawa SLA

Na papierze wszystko przemawia za niższym priorytetem: kategoria „security feature bypass”, wymagana interakcja użytkownika, waga Important zamiast Critical. Tyle że MOTW to dokładnie ta kontrola, która ma działać w momencie, gdy użytkownik już kliknął. Microsoft opisuje go tak: Windows dodaje MOTW do plików z niezaufanych lokalizacji, takich jak internet czy strefa Restricted sites, na przykład do pobrań z przeglądarki i załączników poczty. Na podstawie tego znacznika Office domyślnie blokuje makra w plikach z internetu. Bypass MOTW nie daje atakującemu kodu. Usuwa natomiast bezpiecznik między „ofiara otworzyła plik” a „payload się uruchomił”.

Wektor CVSS potwierdza, że to nie jest kosmetyka: C:H/I:H/A:H i wynik 8.8, a w wersji temporal od Microsoftu E:F (działający exploit) i 8.2. CISA w SSVC ocenia technical impact jako total. Ten sam wzorzec opisywałem przy JFrog Artifactory, gdzie „Medium” było w KEV, oraz przy wrześniowych EoP w Windows, gdzie o priorytecie decydowała pozycja w łańcuchu, a nie wynik bazowy. Tu jest odwrotnie: CVE-2026-96951 to pierwsze ogniwo, etap dostarczenia. Jeśli Twoja polityka mapuje SLA wprost z severity producenta, ten finding dostanie 30 dni zamiast kilku.

Które KB zamykają podatność

Poprawki to październikowe aktualizacje zbiorcze. Według CVRF MSRC każda wymaga restartu. Numer buildu poniżej to „FixedBuild” z MSRC i to on, a nie sama obecność KB w raporcie, jest kryterium zamknięcia:

Dwie pułapki. Po pierwsze, Windows 11 24H2 i Server 2025 mają ten sam bazowy build 26100, ale różne KB i różne numery UBR (9711 vs 33650). Reguła w skanerze typu „26100 ≥ 9711 = OK” da błędny wynik w jedną albo w drugą stronę, więc porównuj build w parze z edycją systemu. Po drugie, CVRF wskazuje, które KB zastępują poprzednie (np. KB5126868 zastępuje KB5123099, KB5127648 zastępuje KB5124008). Wrześniowy CU nie zamyka tej podatności.

Jak zweryfikować wdrożenie

(1) Odczytaj na hoście aktualny build razem z UBR, na przykład (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR razem z CurrentBuild, i porównaj z tabelą powyżej. (2) Sprawdź oczekujący restart. Skoro MSRC wymaga restartu dla każdej poprawki, host z zainstalowanym, ale nieprzeładowanym CU nadal jest podatny, choć agent zarządzania może raportować KB jako „installed”. (3) Rozlicz pokrycie: Windows 10 21H2/22H2 i Server 2012 R2 są na liście produktów MSRC, ale to, czy dany host faktycznie dostaje te aktualizacje, zależy od kanału wsparcia w Twojej organizacji. Host bez kanału aktualizacji to wyjątek do udokumentowania, a nie „pending”.

Kontrole kompensujące — co jest udokumentowane, a co nie

MSRC dla CVE-2026-96951 nie publikuje workaroundów ani mitygacji. Poniższe kontrole to ogólne mechanizmy z dokumentacji Microsoftu, ograniczające etap dostarczenia. Microsoft nigdzie nie twierdzi, że blokują ten konkretny bypass. Traktuj je jako defense-in-depth do czasu wdrożenia CU, nie jako zamiennik poprawki:

Reguły ASR wymagają Microsoft Defender Antivirus, a część z nich ma ograniczenia na Server 2012 R2 i 2016 (modern unified solution). Przed przełączeniem w tryb Block uruchom je w Audit i sprawdź zdarzenia AsrExecutableEmailContentAudited oraz AsrUntrustedExecutableAudited w advanced hunting. MSRC nie wskazuje, które typy kontenerów (archiwa, obrazy dysków, skróty) są użyte w obserwowanych atakach, ani które konkretne mechanizmy oparte na MOTW (SmartScreen, Protected View, blokada makr) są omijane. Dlatego nie podaję listy rozszerzeń „do zablokowania”, której nie potwierdza żadne źródło.

Co powinien zrobić VE

(1) Nadpisz SLA: KEV + „Exploitation Detected” oznacza termin liczony w dniach, niezależnie od etykiety Important. (2) Kolejność: stacje użytkowników z pocztą i komunikatorami, potem serwery, na których ktoś otwiera pliki (RDS, jump hosty, Citrix). Serwery bez interaktywnych użytkowników mają mniejszą ekspozycję, ale też dostają CU. (3) Zamykaj finding po buildzie i restarcie, nie po statusie KB. (4) Ponieważ CISA wymaga forensic triage, a podatność jest wykorzystywana, przejrzyj w EDR, czy w okresie przed wdrożeniem nie było uruchomień z katalogów pobrań i tymczasowych katalogów poczty, które nie wywołały ostrzeżenia. (5) Powiąż ten finding z kontrolami pocztowymi. Bypass MOTW jest ogniwem łańcucha, więc filtr załączników i reguły ASR skracają okno ryzyka, gdy patch czeka na restart. To dobry przykład, dlaczego KEV i EPSS mówią coś innego niż severity producenta.

Powiązane na blogu

• Windows wrzesień 2026: dwa EoP w KEV — priorytet z pozycji w attack chainie
• CVSS 5.3 Medium, ale CISA KEV — gdy etykieta severity myli
• KEV vs EPSS — któremu wskaźnikowi zaufać

Źródła

• Microsoft Security Response Center — CVE-2026-96951, Windows Shell Security Feature Bypass Vulnerability — msrc.microsoft.com
• MSRC CVRF API — October 2026 Security Updates (cvrf/2026-Oct) — api.msrc.microsoft.com
• CISA Known Exploited Vulnerabilities Catalog — CVE-2026-96951 — cisa.gov
• NVD — CVE-2026-96951 — nvd.nist.gov
• Microsoft Learn — Attack surface reduction rules reference — learn.microsoft.com
• Microsoft Learn — Macros from the internet are blocked by default in Office (Mark of the Web) — learn.microsoft.com

Nota redakcyjna: stan informacji 16 października 2026, na podstawie CVRF MSRC „October 2026 Security Updates” (rewizja 1.0 z 13.10.2026), katalogu CISA KEV (wersja 2026.10.15) i rekordu NVD. Numery KB i FixedBuild pochodzą wprost z CVRF. Kontrole ASR i polityka makr to ogólne zalecenia z dokumentacji Microsoftu, nie mitygacje wskazane dla tego CVE, a ich skuteczność wobec tego konkretnego bypassu nie jest potwierdzona. Microsoft nie publikuje szczegółów technicznych ani wskaźników kompromitacji dla obserwowanych ataków.