CVE-2026-16093 spot-check: unsigned JWT client assertion rejected
- Condition
- CVE-2026-16093 (26.7.3: required signed-JWT assertion policy bypassable with unsigned assertion headers)
Method
Created a confidential client (jwt-assert-client) with
clientAuthenticatorType=client-secret-jwt, then exercised the
client_credentials grant with a JWT client assertion in both forms:
- HS256 — a properly HMAC-signed assertion over the client secret.
alg:none— the same header/payload with no signature (the bypass).
Result
| Assertion | Response |
|---|---|
| HS256 (signed) | HTTP 200 — access token issued |
alg:none (unsigned) | HTTP 400 — {"error":"invalid_client","error_description":"Invalid signature algorithm"} |
Finding
26.7.3 rejects unsigned JWT client assertions (alg:none → "Invalid
signature algorithm"), so the CVE-2026-16093 bypass is closed. The signed path is
unaffected. This confirms the OIDC client-assertion fix in the 26.7.3 batch.
Still open (need external IdPs / dedicated harness)
- CVE-2026-18215 / CVE-2026-18214 — Microsoft/Google token-exchange tenant/hosted-domain bypasses. These need a real (or mocked) external IdP; the lab has no Google/Microsoft fixture.
- CVE-2026-79652 — jwt-bearer grant
consentRequiredenforcement (same client-assertion harness could be extended).