# Shared singleton request context bleed

Per-request state (context, user, token, credential) stored on a singleton or global map and reused across concurrent requests

_Area: Web access control and IDOR. Seen in 3 disclosed reports; latest 2026-09-10. Updated 2026-10-30._

## How it works
A request's identity — user, token, tenant, credential — is stored somewhere that outlives the request: a singleton object's field, a driver-global map, or a shared injector. The code assumes "one request at a time" or "this field is mine for the duration," but concurrent requests interleave at await points and overwrite each other's state. A later request then reads the earlier request's identity, or a later login rebinds an existing session to another user's backend. The broken assumption is that per-request data can live in per-process storage.

## Where it shows up
- Singleton-scoped DI providers with injected request context (e.g. `@ExecutionContext`) stored on instance fields [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-53wg-r69p-v3r7.md)
- Driver-global maps keyed only by username holding credentials or auth state [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-c476-6w5q-jw77.md)
- Wrapper/plugin layers that re-implement a framework's request lifecycle and drop its async-context isolation [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-h3hw-29fv-2x75.md)
- Caches keyed by username alone where a sibling layer keys by username+credential+client [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-c476-6w5q-jw77.md)
- Any mutable field on a shared object written during request handling

## How to review
Trace every piece of request-scoped data (identity, token, tenant, credential, VFS/backend handle) to its storage. The invariant: request-scoped state must be reachable only through a per-request object or async-local context, never through a singleton, module-global, or username-keyed map. Check that wrappers/plugins preserve the framework's context mechanism rather than reimplementing execution. Confirm cache keys include every discriminator the sibling layer uses (credential, client, tenant). Test by interleaving two requests with distinct identities and a delay between read and use.

## Variants seen
- Singleton provider caching injected ExecutionContext on an instance field, mixing auth tokens [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-53wg-r69p-v3r7.md)
- Plugin bypassing async_hooks context isolation so parallel requests share ExecutionContext [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-h3hw-29fv-2x75.md)
- Auth-proxy driver storing passwords in a username-keyed global map, rebinding sessions across tenants [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-c476-6w5q-jw77.md)

## Why fixes fail
E2 shows a framework-level async_hooks fix being silently bypassed by a wrapper that re-implements the request path; the isolation existed but did not apply. Fixes at one layer do not cover alternate entry points.

## Impact and severity
Cross-tenant read/write/delete [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-c476-6w5q-jw77.md) and auth-token mixing between users [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-53wg-r69p-v3r7.md) — high severity. Worse when the leaked state is a credential or token, when the shared map is keyed by a guessable identifier like username, and when alternate integration paths skip the isolation fix.

## Evidence
- E1: https://bugbountylibrary.com/r/ghsa%3AGHSA-c476-6w5q-jw77.md
- E2: https://bugbountylibrary.com/r/ghsa%3AGHSA-h3hw-29fv-2x75.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-53wg-r69p-v3r7.md