# Client-supplied identity trusted for login

Login or token issuance keyed on email, actor id, or subject taken from the request without verification

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; one confirmed bounty: $1,000; latest 2026-09-10. Updated 2026-10-24._

## How it works
A login or token-issuance path decides *who the caller is* from a value the caller controls — an email field, a federated actor `id`, or an OAuth/SCIM subject claim — instead of from a verified credential. The assumption that breaks is "this identifier was produced by a trusted party." When the server never checks that the identifier is bound to a proof of identity (a validated OAuth token, a signature whose key origin matches the claimed origin, an exact-match lookup), anyone who can name the victim becomes the victim.

## Where it shows up
- Auth handlers that accept an `email`/`user`/`subject` parameter alongside (or instead of) an OAuth token [E2](https://bugbountylibrary.com/r/h1%3A245408.md)
- Federated inbox/signature code that fetches an actor by `keyId` URL but never compares the returned `id` origin to that URL [E1](https://bugbountylibrary.com/r/h1%3A461308.md)
- Identity lookups using `contains()`/`LIKE`/substring or wildcard matching on subject or external-ID columns [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md)
- Hand-written per-dialect query branches that look symmetric but emit different operators [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md)
- Mobile/API login endpoints that accept more fields than the flow needs [E2](https://bugbountylibrary.com/r/h1%3A245408.md)

## How to review
Trace every field in the login/token request to where it is *verified*, not just parsed. The invariant: the identity used to mint a session or token must be derived from a validated credential, and any identifier must be bound to that credential's origin/issuer. For federation, require the fetched actor's `id` origin to equal the `keyId` URL origin [E1](https://bugbountylibrary.com/r/h1%3A461308.md). For OAuth, confirm the server validates the provider token and ignores client-supplied email [E2](https://bugbountylibrary.com/r/h1%3A245408.md). For lookups, require exact equality on the subject/external-ID column, and check what SQL each dialect branch actually emits [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md). Strip requests to single fields to see what still authenticates [E2](https://bugbountylibrary.com/r/h1%3A245408.md).

## Variants seen
- Federated actor `id` not bound to `keyId` origin, enabling impersonation via cache-priming [E1](https://bugbountylibrary.com/r/h1%3A461308.md)
- OAuth login trusting a client-supplied email with no token validation [E2](https://bugbountylibrary.com/r/h1%3A245408.md)
- Subject-claim lookup degrading to wildcard `LIKE` on SQLite, binding sign-in to the wrong (possibly admin) account [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md)

## Impact and severity
Full account takeover, including admin accounts [E2](https://bugbountylibrary.com/r/h1%3A245408.md)[E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md), and unauthenticated impersonation of any local user [E1](https://bugbountylibrary.com/r/h1%3A461308.md). Severity rises when the trusted field is unauthenticated, when the matched account can be an administrator, and when wildcard or substring matching widens the set of accounts a single input can reach [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md).

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A461308.md
- E2: https://bugbountylibrary.com/r/h1%3A245408.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-wpmr-8h3q-fwj7.md