# Token verifier fails open

Verifier returns success on empty, garbage, or error-returning crypto checks instead of failing closed

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; latest 2026-09-22. Updated 2026-10-24._

## How it works
A verifier is supposed to answer one yes/no question: is this credential valid? The bug is that it answers "yes" to everything else. Three shapes appear in the evidence: a handler catches the rejection from key validation and returns an empty-but-successful identity object [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise.md); a verifier returns a token object for any non-empty string [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md); and a crypto check is negated loosely so an error return value counts as success [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-mv28-wj57-f57g.md). In each case the code treats "I could not confirm this is bad" as "this is good." The assumption that breaks is that failure paths are equivalent to rejection. They are not: exceptions, error codes, and absent input are all distinct from a valid credential, and the code collapses them into the accept branch.

## Where it shows up
- `try/except` around token validation that returns a default/empty auth object instead of raising [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise.md)
- Verifier docstrings or code that accept "any non-empty" token [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md)
- Auth provider builder returning `None` by default, with middleware that does not reject missing `Authorization` headers [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md)
- Loose negation of crypto calls: `!openssl_verify(...)`, `if not verify(...)`, truthiness tests on functions returning 1/0/-1/false [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-mv28-wj57-f57g.md)
- Tool layers that silently fall back to operator/env credentials when no user token is present [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md)

## How to review
Trace the full credential-resolution chain, not just the verifier: header presence check, verifier, middleware, and the tool layer's credential fallback [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md). The invariant: every path that is not an explicit, positive validation result must reject the request. For crypto, require strict comparison to the success value (`=== 1` for `openssl_verify`), never truthiness or negation [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-mv28-wj57-f57g.md). For handlers, confirm a caught 401/403 propagates as rejection rather than a default identity [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise.md). Check that a missing header is rejected before any verifier runs.

## Variants seen
- Exception-swallowing handler returning empty auth object [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise.md)
- Permissive verifier accepting any non-empty token, compounded by absent-header tolerance and env-credential fallback [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md)
- Loose boolean negation of a tri-state crypto return, forced into the error path via mismatched key/algorithm types [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-mv28-wj57-f57g.md)

## Impact and severity
Unauthenticated access to protected tools and data: Bazar entry create/update/delete [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-mv28-wj57-f57g.md), Jira/Confluence tools under operator credentials [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md), and in LiteLLM an auth bypass chained to unsandboxed code execution and cloud compromise [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise.md). Severity rises when the bypassed identity carries operator or environment credentials, and when the bypass is only one link in a chain to code execution.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise.md
- E2: https://bugbountylibrary.com/r/ghsa%3AGHSA-mv28-wj57-f57g.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-wrhw-j3f9-8vc6.md