Bez znajomości hasła można zalogować się do SharePointa jako admin.

No więc trzymajcie się krzeseł (lub poręczy w tramwajach ;-) – pierwszym krokiem ataku jest ominięcie podpisu JWT poprzez użycie algorytmu none 😅 Czyli mówię SharePointowi, żeby zupełnie zignorował podpis kryptograficzny mojego (sfałszowanego) tokena. A SharePoint grzecznie to wykonuje. W skrócie wysyłamy token z takim nagłówkiem:

{“alg”: “none”, “typ”: “JWT”}

i jakiś tam randomowy podpis (który i tak nie jest weryfikowany).

Jest to znany typ podatności, który opisywałem w ebooku o bezpieczeństwie JWT.

I to tyle? No jeszcze potrzeba dać sobie radę z drugim tokenem JWT, który znajduje się w payloadzie pierwszego.

Tutaj sytuacja staje się nieco bardziej egzotyczna, bo trzeba wskazać w nagłówku x5t pewną wartość wyciągniętą z anonimowego endpointu SharePointa.

{ “alg”: “RS256”, “typ”: “JWT”, “x5t”: “i_gz5qfYp5YPWAK1__0YhZnipLI” }

Powoduje to pewien błąd. A dokładniej dość gruby błąd, bo podpis tego tokenu nie jest zupełnie sprawdzany. Finalny JWT wygląda mniej więcej tak (w nameid jest SID usera Windows, na którego chcemy się zalogować bez hasła – np. admina):

Header:

{“alg”: “none”, “typ”: “JWT”}
Payload:

{ “nameid”: “S-1-5-21-4203888158-2793536450-3921675298-500”,
“actortoken”: “{“alg”: “RS256”, “typ”: “JWT”, “x5t”: “i_gz5qfYp5YPWAK1__0YhZnipLI”}.
}

Podatność CVE-2026-55040 została załatana w lipcu tego roku. Otrzymała wycenę ryzyka 9.1 / 10 w skali CVSS (podatność krytyczna)

PS
Całe info lekko uproszczone w celu klarowności przekazu.

~Michał Sajdak