Dodanie CVE-2026-45659 przez CISA do katalogu Known Exploited Vulnerabilities nie oznacza paniki dla każdego klienta Microsoft 365. To wyraźny sygnał dla organizacji, które nadal utrzymują lokalny, samodzielnie zarządzany SharePoint Server.

Lokalny serwer współpracy za firewallem z dokumentami, tożsamościami i listą poprawek

Microsoft poprawił problem w aktualizacjach z maja 2026 r. CISA dodała go do KEV 1 lipca po dowodach aktywnej eksploatacji i wyznaczyła 4 lipca jako termin dla objętych agencji federalnych USA. Dla reszty zostaje pytanie: czy wiecie, gdzie są lokalne farmy SharePoint, czy mają poprawione buildy, czy były wystawione i czy ktoś dotknął ich przed patchem?

To nie jest historia o anonimowym pre-auth wormie. Microsoft opisuje lukę jako wymagającą uwierzytelnienia i niskich uprawnień. To obniża hałas, nie priorytet. Konta low-privilege są phishowane, kradzione przez infostealery, zostawiane kontraktorom albo zapomniane w starych grupach. Authenticated RCE w SharePoint może zamienić problem tożsamości w problem serwera.

Co się stało

CVE-2026-45659 to zdalne wykonanie kodu w Microsoft SharePoint Server przez deserializację niezaufanych danych, CWE-502. Microsoft ocenia ją na CVSS 8.8: sieć, niska złożoność, niskie uprawnienia, brak interakcji użytkownika, wysoki wpływ na poufność, integralność i dostępność.

Lista dotyczy SharePoint Server Subscription Edition, SharePoint Server 2019 oraz SharePoint Enterprise Server 2016 / SharePoint Server 2016. Poprawione buildy to 16.0.19725.20280 z KB5002863, 16.0.10417.20128 z KB5002870 i 16.0.5552.1002 z KB5002868.

SharePoint Online nie jest wymieniony jako produkt wymagający patchowania przez klienta. Ryzyko leży w środku: hybrydowe i legacy farmy dla workflow, archiwów, działów, regulowanych obciążeń, custom web parts i niedokończonych migracji.

Poprawka była, ale priorytet się zmienił

MSRC pisze, że luka została naprawiona w majowych aktualizacjach, ale CVE omyłkowo pominięto w liście May 2026 Security Updates. Rewizja z 26 maja była informacyjna dla klientów, którzy już zainstalowali majowe aktualizacje.

Zespół, który zainstalował maj, może być bezpieczny. Inny mógł zobaczyć wpis później, z oceną exploitation less likely, i przesunąć go do zwykłego okna. KEV zmienia priorytet, bo oznacza realną eksploatację.

Nie trzeba zakładać złej woli. Vulnerability intelligence się zmienia. Ocena dostawcy jest zdjęciem chwili. Atakujący testują, obrońcy obserwują.

Authenticated nie znaczy bezpieczne

Microsoft mówi, że każdy uwierzytelniony atakujący może uruchomić lukę; admin nie jest potrzebny; Site Member może wystarczyć. W starych środowiskach collaboration to nie jest wysoka bariera.

Uprawnienia SharePoint rosną latami: projekty, partnerzy, działy, grupy dziedziczone, konta testowe, kontraktorzy. Skradzione konto może samo dawać mało, ale z podatną farmą może prowadzić do code execution, web shell albo lateral movement.

Dobra reakcja to scoping: edycje, buildy, ekspozycja internet/VPN/partner, szerokie grupy Site Member, świeże incydenty identity i anomalie SharePoint.

Dlaczego SharePoint jest cenny

SharePoint wygląda jak stary intranet, ale przechowuje dokumenty, approvals, workflow, aplikacje, archiwa i procesy biznesowe. Często stoi blisko Active Directory, SQL Server, kont serwisowych, integracji Office, custom code i backupów.

Lokalne farmy trudno patchować przez customizacje. To tłumaczy opóźnienia, ale active exploitation nie czeka na wygodne okno. BleepingComputer cytował dane Shadowserver o ponad 10 000 SharePoint servers exposed online. To nie liczba podatnych systemów, tylko sygnał ekspozycji.

KEV zmienia ticket w patchowanie z myślą o incydencie

Zwykły ticket pyta: czy update jest zainstalowany? Exploited vulnerability pyta też: czy serwer był wcześniej reachable, czy były próby i czy trzeba forensics triage?

CISA wspomina exposure evaluation i forensics triage. Patch jest konieczny, ale przy wcześniejszej ekspozycji może nie wystarczyć. Wewnętrzna, szybko załatana farma potrzebuje potwierdzenia. Wystawiona i podatna farma potrzebuje patcha albo izolacji plus przeglądu logów. Podejrzana aktywność wymaga incident response.

Co sprawdzić

Zrób inventory wszystkich farm SharePoint: migration, test, DR, partner portals, department servers, reverse proxies. Porównaj edition i build z MSRC.

Ogranicz exposure, jeśli natychmiastowy patch jest niemożliwy: zamknij public access, użyj trusted network paths, usuń zbędne wejścia, sprawdź proxy/WAF. Niepotrzebny service wyłącz do aktualizacji.

Przejrzyj IIS i SharePoint logs: unusual authenticated requests, uploads/scripts, nowe konta, zmiany site collections, dziwne worker processes, PowerShell, scheduled tasks, outbound connections. Sprawdź identity: suspicious accounts, broad groups, stale contractors i service accounts z interactive access.

Czego nie robić

Nie traktuj SharePoint Online jak lokalnej farmy do patchowania dla tego CVE. Nie używaj “authenticated” jako powodu do czekania przy exposed farm. Nie uruchamiaj losowych PoC i nie cytuj słabych repozytoriów GitHub jako dowodu kampanii. CISA potwierdza exploitation; to wystarczy do obrony. Nie przypisuj ransomware: CISA oznacza ten status jako unknown.

Pięć pytań

Czy jest pełny inventory? Czy wszystkie systemy są na fixed builds lub majowych updates? Czy któryś był internet-facing albo szeroko reachable? Czy sprawdzono logi i zmiany kont? Czy wiadomo, które low-privileged users mogą się uwierzytelnić?

CVE-2026-45659 jest poważna, bo łączy legacy collaboration, identity compromise i powolne patching. Nie oznacza, że każdy SharePoint jest stracony. Oznacza, że stare lokalne collaboration servers nie mogą być niewidzialne.

Priorytety bez paniki

Priorytet nie wynika tylko z CVSS. Wewnętrzna farma SharePoint, już zaktualizowana i dostępna tylko z kontrolowanych sieci, to inny przypadek niż serwer wystawiony do internetu z zewnętrznymi użytkownikami i uprawnieniami narastającymi latami. KEV zmienia jednak rozmowę: przy potwierdzonej eksploatacji trzeba sprawdzić stan, nie zakładać go.

Praktyczna kolejność to ekspozycja, wersja, tożsamość, sygnały. Ekspozycja: kto może dotrzeć do serwera. Wersja: czy build jest poprawiony. Tożsamość: jakie low-privileged konta mogą się logować. Sygnały: czy logi pokazują nietypową aktywność przed patchem. Taki porządek unika i paniki, i samozadowolenia.

Dla MSP i małych zespołów najczęstszy problem to niepełny inventory. Klient może uważać, że przeszedł do chmury, ale trzyma starą farmę dla archiwum, workflow albo działu, który nigdy nie zakończył migracji. Wtedy pytaniem nie jest bezpieczeństwo SharePoint Online, lecz zapomniany serwer nadal przyjmujący logowania.

Szersza lekcja

CVE-2026-45659 pokazuje, że vulnerability management w 2026 r. nie polega już na sortowaniu po score. Decyzje łączą dowody exploitacji, ekspozycję, znaczenie biznesowe, realia identity i zdolność do patchowania bez psucia procesów. SharePoint skupia te czynniki: jest stary, użyteczny, blisko tożsamości i często dostosowany.

Dobre zamknięcie to nie tylko “KB zainstalowane”. To zaktualizowany inventory, zweryfikowane buildy, ograniczona ekspozycja, przejrzane logi, obsłużone podejrzane konta i przycięte zbyt szerokie uprawnienia. Taka dokumentacja przyda się przy kolejnej luce, która zmieni status kilka tygodni po poprawce.

Spokojny wniosek jest prosty: jeśli nie prowadzisz lokalnego SharePoint Server, nie rób z tego niepotrzebnego strachu. Jeśli prowadzisz, nie traktuj go jak nudnego portalu. Traktuj go jak krytyczną infrastrukturę blisko dokumentów i tożsamości.