CVE-2026-55040: krytyczna luka JWT w Microsoft SharePoint Server — dlaczego PoC Rapid7 uruchomił lawinę ataków i co to oznacza dla Twojego on-prem?

13 August 2026 10 min read 2149 words

CVE-2026-55040 (CVSS 9.1, Weak Authentication / CWE-1390) to krytyczna luka w Microsoft SharePoint Server (Subscription Edition, 2019, 2016), która umożliwia zdalne, nieuwierzytelnione obejście procesu uwierzytelnienia i wykonywanie operacji jako dowolny użytkownik — w tym administrator farmy. Błąd leży w walidacji tokena JWT w pipeline'ie SharePoint; Microsoft zaadresował podatność w Patch Tuesday July 2026 (severity zmienione z medium na critical 14.07.2026), ale kluczowe jest to, co stało się po publicznym PoC.

11.08.2026 Stephen Fewer (Rapid7 Labs) opublikował pełny opis techniczny i kod PoC (wcześniej prezentowany na Pwn2Own Berlin). 12.08.2026 Defused potwierdził aktywną eksploatację PoC w atakach na honeypoty SharePoint, a Shadowserver wskazał >8 500 serwerów SharePoint wystawionych publicznie. Microsoft nie oznaczył jeszcze flaw jako „exploited in the wild" w CISA KEV (stan na 12.08.2026), ale presja na patch management w polskich organizacjach z on-prem SharePoint (zwłaszcza tam, gdzie M365 jest federowany) jest teraz wyraźna — CERT Polska opublikował komunikat 143/2026 właśnie w związku z upublicznieniem PoC.

Dla firm B2B i produkcji: priorytet to (1) potwierdzić build version vs. advisory Microsoft i załatać natychmiast, (2) sprawdzić farmy pod kątem śladów kompromitacji z ostatnich 30 dni (anomalne logowania, tokeny JWT bez wcześniejszego MFA flow, eskalacja uprawnień), (3) zweryfikować integracje federacyjne (ADFS / Entra hybrid) — luka może być wektorem do M365.

Najważniejsze fakty

CVE-2026-55040 to luka typu Weak Authentication (CWE-1390) w Microsoft SharePoint Server — błąd w walidacji tokena JWT umożliwia zdalne, nieuwierzytelnione obejście uwierzytelnienia i działanie jako dowolny użytkownik SharePoint, w tym administrator farmy. Dotyczy wyłącznie wersji on-prem (Subscription Edition, 2019, 2016); SharePoint Online w M365 zarządzany przez Microsoft nie jest dotknięty.
CVSS 9.1 (severity critical). Microsoft zaadresował podatność w Patch Tuesday July 2026 — severity zmienione z medium na critical 14.07.2026, co sygnalizuje wewnętrzną rewizję ryzyka po zgłoszeniu od Rapid7.
Odkrywca: Stephen Fewer, Senior Principal Security Researcher w Rapid7 Labs. Łańcuch dwóch CVE (w tym CVE-2026-55040) demonstrowany był na Pwn2Own Berlin; pełny opis techniczny i PoC opublikowane 11.08.2026 w oficjalnym blogu Rapid7. CERT Polska opublikował komunikat 143/2026 dzień później (12.08.2026) w związku z upublicznieniem szczegółów i rosnącym ryzykiem ataków.
Aktywna eksploatacja (stan na 12.08.2026): Defused honeypot telemetry potwierdziła — „Attackers are now using the @rapid7 POC for CVE-2026-55040 against our SharePoint honeypots" (12.08.2026). Shadowserver wskazał >8 500 serwerów SharePoint wystawionych online (globalnie).
Status KEV: Microsoft nie oznaczył jeszcze flaw jako „exploited in the wild" w CISA KEV (stan na 12.08.2026), ale CISA wskazało w alert z lipca 2026 ryzyko „Exploitation More Likely" dla pokrewnych CVE w tej rodzinie produktów (CVE-2026-58644 trafiło do KEV 16.07.2026). Brak wpisu w KEV nie oznacza bezpieczeństwa — to luka nieuwierzytelniona z publicznym PoC.
Łańcuch ryzyka: JWT bypass → impersonacja dowolnego użytkownika SharePoint (w tym administratora) → dostęp do dokumentów, list, workflows, ustawień farmy → możliwy ruch boczny do Microsoft 365 w organizacjach z federacją (ADFS / Entra hybrid trust). Ryzyko wzrasta, gdy SharePoint ma włączone integracje Power Automate / Power Apps z dostępem do danych LOB.
Sektor: cross-sector, ale populacja ryzyka koncentruje się w organizacjach z on-prem SharePoint utrzymywanym z przyczyn regulacyjnych (dane wrażliwe, automotive Tier-1, medycyna, instytucje publiczne, administracja). Polski kontekst: CERT Polska wprost zaadresował komunikat do organizacji z SharePoint on-prem w PL.
Perspektywa klasyfikacji: luka dotyczy naruszenia poufności i integralności; przy udanej eksploatacji na farmie przechowującej dane osobowe lub IP — wchodzi w zakres art. 21 NIS2 (środki zaradcze) i art. 23 (procedury obsługi incydentów). Klasyfikacja konkretnego incydentu wymaga oceny Twojej organizacji — interpretacja prawna wymaga współpracy z kancelarią.

Tabela decyzyjna

Obszar	Co wiemy	Co to oznacza dla firmy B2B / produkcji	Zalecane działanie 30 dni	Zalecane działanie 90 dni
Nieuwierzytelniony JWT bypass	CVSS 9.1, publiczny PoC 11.08.2026, aktywna eksploatacja w honeypotach 12.08.2026	Każda farma SharePoint on-prem podłączona do internetu jest potencjalnym celem — atak nie wymaga konta, nie wymaga interakcji użytkownika	Inwentaryzacja farm SharePoint on-prem (w tym build version), weryfikacja vs. advisory Microsoft Patch Tuesday July 2026	Wdrożenie stałego cyklu patch management z SLA 72h dla CVE critical (wzorzec z CISA KEV)
Impersonacja dowolnego użytkownika	JWT bypass → dowolna tożsamość, w tym administrator farmy	Logi SharePoint nie zawsze wskazują ślad kompromitacji — atakujący „wygląda" jak autoryzowany admin	Audyt logów SharePoint (ostatnie 30 dni) pod kątem: logowania bez MFA flow, eskalacji uprawnień, modyfikacji listy administratorów, nietypowych web service calls	Integracja telemetryczna SharePoint z SIEM (User Profile Service logs, SharePoint ULS, IIS), korelacja z auth logs (ADFS / Entra ID)
Ścieżka do M365 (federacja)	Organizacje z ADFS / Entra hybrid trust: kompromitacja farmy = potencjalne wejście do M365	SharePoint on-prem bywa pomijany w threat modelu M365-first — klasyczny blind spot	Audyt trust federacyjnego SharePoint ↔ M365, weryfikacja claim rules, przegląd conditional access policies dla farm on-prem	Migracja z ADFS do Entra ID cloud-only lub hybrid z Phishing-Resistant MFA, eliminacja legacy auth
Publiczny PoC = fala ataków	Rapid7 opublikował pełny opis techniczny i kod PoC 11.08.2026	Publiczny PoC obniża próg wejścia — eksploatacja nie wymaga już badaczy security	Threat hunting z użyciem IoC z Rapid7 / Microsoft / CERT Polska (YARA, sygnatury logów), skanowanie znanych lokalizacji webshell	Wdrożenie deception / honeypot SharePoint farmy wewnętrznej do wczesnego wykrywania skanowania pre-exploit
Brak wpisu w CISA KEV	Microsoft nie oznaczył flaw jako „exploited in the wild" w KEV (stan 12.08.2026)	Brak KEV nie oznacza braku eksploatacji — telemetry Defused ją potwierdza	Traktować CVE-2026-55040 jak KEV w wewnętrznym SLA patch management (72h) niezależnie od oficjalnego statusu	Stały monitoring: CISA KEV, CERT Polska, MSRC, Rapid7 research blog
Perspektywa NIS2/KSC	Luka dotyczy naruszenia poufności + integralności; raportowanie 24h/72h	Podmioty essential/important z on-prem SharePoint: obowiązek wczesnego ostrzegania CSIRT NASK przy potwierdzonej eksploatacji	Weryfikacja kanału zgłoszeniowego do CSIRT NASK, definicja wzoru incydentu krytycznego, eskalacja do zarządu	Ćwiczenie scenariusza „SharePoint pre-auth RCE → eskalacja M365" z udziałem IT + bezpieczeństwa + zarządu

Perspektywa inż. Marcina Białczyka

— na ten temat nie mam jeszcze publicznego case study u klienta; chętnie opiszę konkretne wdrożenie po zgodzie klienta. To powiedziawszy, poniżej dzielę się ramą operacyjną, której używam przy ocenie ekspozycji SharePoint on-prem w kontekście JWT bypass.

Dlaczego ta luka jest poważniejsza niż „kolejny RCE". Większość nagłówków wokół SharePoint w 2026 roku dotyczy CVE-2026-58644 (ToolShell, ransomware, kradzież kluczy IIS). CVE-2026-55040 działa w innym wektorze — nieuwierzytelniony JWT bypass — ale w tej samej rodzinie produktów. Kluczowa różnica: tu nie ma fazy uwierzytelnienia do obejścia, więc nie ma logu „failed login" w klasycznym sensie. Atakujący przedstawia sfałszowany token JWT i od razu działa jako administrator. Dla organizacji, które monitorują wyłącznie failed authentication, ta luka jest praktycznie niewidoczna — do momentu, aż ktoś zmodyfikuje listę administratorów farmy lub wyciągnie dokumenty z bibliotek SharePoint.

Dlaczego publikacja PoC zmienia wszystko — i to szybko. Historia CVE-2026-55040 pokazuje klasyczny schemat: badacz (Rapid7 Labs, Stephen Fewer) znajduje lukę w ramach badań Pwn2Own, współpracuje z Microsoft nad patchem, Microsoft zaadresowuje podatność 14.07.2026 (zmiana severity z medium na critical). Ale pełny PoC publikuje dopiero 11.08.2026 — miesiąc po patchu. To standardowy „responsible disclosure" cykl, który daje czas obrońcom, ale też dokładnie mierzy czas reakcji atakujących. 12.08.2026 Defused honeypots już widzi exploitation. To jest tempo, w którym patch management nie nadąża za threat landscape — organizacje, które nie załatały w lipcu, teraz nie mają już bufora.

Co bym zrobił w pierwszych 30 dniach, gdybym zarządzał farmą SharePoint on-prem.

Weryfikacja buildu: sprawdzić build version każdej farmy SharePoint on-prem (Central Administration → Upgrade and Migration → Check upgrade status) i porównać z advisory Microsoft z Patch Tuesday July 2026. Jeśli farma nie jest na najnowszym buildzie — zaplanować okno serwisowe ASAP, najlepiej w trybie failover jeśli jest topologia active-passive.
Threat hunting post-exploitation: audyt logów SharePoint (ULS, IIS, SharePoint audit logs) z ostatnich 30 dni pod kątem: logowania bez wcześniejszego MFA flow, eskalacji uprawnień (dodanie do grupy Farm Administrators), modyfikacji Claims Providers, tworzenia nowych site collections z nietypowymi szablonami, anomalii w SPSecurityTokenService.
Federacja i ruch boczny: jeśli farma jest w trust federacyjnym z Entra ID / ADFS — sprawdzić logi ADFS pod kątem nietypowych token issuance (szczególnie bez wcześniejszego MFA flow w Entra ID). Sprawdzić, czy SharePoint ma włączone integracje z Power Platform (Power Automate, Power Apps) i jakie konta service principal są używane.
Sygnały środowiskowe: sprawdzić, czy SharePoint nie był już eksploatowany — szukamy: anomalii w w3wp.exe, nowych plików .aspx w TEMPLATE\LAYOUTS\15\, nietypowych aktywności w SPSecurityTokenService, dumpów w c:\windows\temp. IoC z Rapid7 / Microsoft / CERT Polska jako baseline.
Backupy: weryfikacja procedury offline + immutable backup + test restore z wybranej farmy SharePoint (szczególnie ważne, bo SharePoint ma specyficzne wymagania dla backup/restore — nie jest to zwykły katalog plików).

W 90 dni — program ciągłości: skrócenie cyklu patch management do 72h dla CVE critical (niezależnie od statusu KEV), integracja SharePoint telemetry z SIEM, threat hunting playbook dla SharePoint, ćwiczenie scenariusza „pre-auth RCE → eskalacja M365" z udziałem IT, bezpieczeństwa i zarządu. To jest zakres, w którym CHORS NIS2/KSC Continuous Readiness ma dla takich klientów praktyczne zastosowanie — nie jako „certyfikacja", lecz jako zbudowanie ciągłości operacyjnej z realnymi ćwiczeniami i evidence.

Najczęściej zadawane pytania

Czy CVE-2026-55040 dotyczy SharePoint Online (Microsoft 365)?

Nie. Luka dotyczy wyłącznie on-prem SharePoint Server (Subscription Edition, 2019, 2016). Microsoft 365 SharePoint Online zarządzany przez Microsoft nie jest dotknięty. Ale integracje hybrydowe — Power Automate, Power Apps, on-prem data gateways, federacja ADFS / Entra hybrid — już tak. Warto zweryfikować ścieżkę danych między on-prem SharePoint a M365.

Czy patch z lipca 2026 w pełni eliminuje ryzyko?

Tak, jeśli farma została załatana przed 11.08.2026 (data publikacji PoC). Jeśli farma była eksploatowana wcześniej — patch zamyka lukę, ale skutki kompromitacji (skradzione dane, utrzymany dostęp, zmodyfikowane konfiguracje) wymagają osobnego post-incident review. Brak logu „failed login" nie oznacza braku eksploatacji — ta luka działa z sukcesem od razu.

Jak wykryć, czy farma była eksploatowana?

Wskaźniki: (a) logowania w ULS / IIS bez wcześniejszego MFA flow lub bez typowego sekwencjonowania request → token, (b) nieautoryzowane zmiany w Farm Administrators group, (c) nowe site collections lub web applications utworzone bez odpowiedniego change ticket, (d) anomalie w SPSecurityTokenService (token issuance z nietypowych źródeł), (e) pliki .aspx w katalogach TEMPLATE\LAYOUTS\15\ spoza standardowego zestawu. Rekomendacja: threat hunting playbook oparty na IoC z Rapid7 / CERT Polska + skanowanie YARA.

Czy ten incydent wpisuje się w NIS2/KSC?

Tak — wątek naruszenia poufności i integralności. Podmioty essential/important z on-prem SharePoint powinny rozważyć raportowanie wczesnego ostrzegania do CSIRT NASK w ciągu 24h od potwierdzenia eksploatacji, zgodnie z art. 23 NIS2. Klasyfikacja konkretnego incydentu wymaga oceny Twojej organizacji (zakres danych, sektor, skala) — interpretacja prawna wymaga współpracy z kancelarią. CERT Polska w komunikacie 143/2026 wskazuje tę podatność jako istotną dla organizacji w PL.

Czy warto wdrożyć EDR na serwerach SharePoint?

Z punktu widzenia tego incydentu — tak. JWT bypass jest trudny do wykrycia na poziomie logów SharePoint (brak failed login, token wygląda poprawnie), ale EDR z monitorowaniem procesów (w3wp.exe, PowerShell spawn z kontekstu SharePoint) i File Integrity Monitoring na katalogach SharePoint zwiększają szansę wykrycia post-exploitation. Wdrożenie EDR na front-endach SharePoint to element programowy w naszej CHORS NIS2/KSC Continuous Readiness.

Jak CHORS.NET pomaga

CHORS.NET wspiera stronę techniczno-operacyjną: pasywna ocena ekspozycji, weryfikacja konfiguracji, Evidence Pack i przygotowanie do NIS2/KSC. Zobacz: Usługi, Jak pracuje CHORS.NET, NIS2/KSC Readiness Center oraz Polityka AI.

Granice i założenia

Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu. Artykuł opisuje mechanizm i obserwacje z publicznie dostępnych źródeł (Rapid7, MSRC, CERT Polska, Shadowserver, Defused, CISA), nie stanowi gwarancji dla konkretnego środowiska.
Nie certyfikujemy zgodności z NIS2/KSC — CHORS NIS2/KSC Readiness to usługa przeglądu i budowania ciągłości (BCP/DR, governance, ćwiczenia), nie audyt certyfikacyjny. Nie wydajemy samodzielnej opinii prawnej.
Wyniki dotyczą stanu na moment artykułu (2026-08-12). Microsoft, Rapid7, CISA, CERT Polska publikują aktualizacje — w tym ewentualną zmianę statusu KEV; zalecamy śledzenie tych źródeł.
W interpretacji prawa (w tym klasyfikacji incydentu, raportowaniu, progach raportowania 24h/72h) CHORS współpracuje z kancelariami prawnymi.
Materiał ma charakter informacyjny i techniczny; nie stanowi porady prawnej.

Precyzyjna wiedza
o ciemnych systemach.