# Token issuer and tenant not bound

Verifier checks signature but not issuer, tenant, audience, or client_id; caches keyed by kid alone

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; one confirmed bounty: $40,000; latest 2026-10-26. Updated 2026-11-01._

## How it works
A token is trusted because its signature verifies, but the verifier never checks *who* issued it or *who* it was meant for. The assumption that breaks: that a valid signature means the token belongs to this app and this tenant. In multi-tenant or multi-issuer setups, any party whose key the verifier will accept can mint a token that passes. The same failure appears in caches: if a key is stored under `kid` alone, a key fetched from issuer A is reused to verify a token claiming issuer B whenever both use the same `kid` [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md).

## Where it shows up
- Multi-tenant cloud apps (Azure App Service/Functions, AAD) relying on platform auth that validates only the signature [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-azure-active-directory-bing-misconfiguration.md)
- JWT verifiers with per-token templated JWKS URLs, where the cache or singleflight key omits the resolved endpoint [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md)
- JWT checks that validate `iss` but not `aud`, so a token minted for one resource is accepted by another [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md)
- OAuth flows with unauthenticated dynamic client registration, arbitrary redirect URIs, or consent-less auto-approval [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md)
- Tokens carrying broad group/role claims that the API layer never narrows to the requested scope [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md)

## How to review
Find every place a token is accepted and confirm the full trust decision, not just the signature. The invariant: a token is accepted only if its signature verifies **and** its issuer, tenant, audience and client_id match the specific trust domain this endpoint serves. For caches, the invariant is that the cache key includes the resolved JWKS URL/issuer/audience, never `kid` alone [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md). For OAuth, confirm registration is authenticated or redirect URIs are constrained, consent is required, and the minted token's audience is enforced at the API [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md). Ask: can I log in with a token from my own tenant? Can I get a key cached under one issuer and reuse it for another?

## How finders spotted it
- Scanned the internet for multi-tenant Azure apps, found ~25% vulnerable, then logged in to a Microsoft-hosted app with an external-tenant user and saw CMS controls [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-azure-active-directory-bing-misconfiguration.md)
- Code review of the JWKS manager: noticed `FetchKey` and the TTL cache key on `kid` while the templated JWKS URL is resolved later, so the cache namespace ignores the trust domain [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md)
- Analysis flagged the combination of unauthenticated DCR, consent-less auto-approval, and issuer-only JWT validation [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md)

## Variants seen
- Platform-managed auth validating signature only, no tenant/issuer check [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-azure-active-directory-bing-misconfiguration.md)
- JWKS cache keyed by `kid`, shared across issuers [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md)
- Audience not enforced, so a narrow-scope token grants broader authorization [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md)
- Unauthenticated client registration plus auto-approval enabling token theft [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md)

## Impact and severity
E1 chained CMS write access to stored XSS on Bing.com and then to Office 365 token theft across millions of users — high severity, raised by chaining and reach [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-azure-active-directory-bing-misconfiguration.md). E2 extended to subscription authorization and cross-tenant data access [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md). E3 let an attacker steal a victim's full API token, exceeding the requested MCP server scope [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md). Impact scales with how many tenants/issuers share the verifier and how broad the leaked claims are.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-azure-active-directory-bing-misconfiguration.md
- E2: https://bugbountylibrary.com/r/ghsa%3AGHSA-g6vg-wj8f-48cj.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-xwmw-prc4-v3cr.md