Detect wildcard CORS origin by membership, not exact match
fix(api): detect wildcard CORS origin by membership, not exact match
Detect wildcard CORS origin by membership, not exact matchdf68d7-fix-detect-wildcard-cors-origin-by-membership-cve-2026-61736fixdetect wildcard cors origin membership exact
Committed by claude
commit message
fix(api): detect wildcard CORS origin by membership, not exact match
A mixed config such as CORS_ORIGINS="*,https://app.example.com" (or an
accidental trailing comma "*,") produced a list that contained "*" but was not
exactly ["*"], so the previous equality check re-enabled credentials. Starlette
treats any allow_origins list containing "*" as allow-all, so those configs
reintroduced the arbitrary-origin credentialed CORS behavior this fix prevents.
Test "*" membership instead of list equality, and drop empty origin entries in
get_cors_origins() (falling back to ["*"] if nothing remains). Add regression
tests for the mixed-wildcard and trailing-comma cases.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_017ZwddG56G4QwLcbEsYLxmdEditor assessment
This commit patches CVE-2026-61736. It continues the CORS hardening with a focused subject: detect wildcard origin by membership, not exact match. The body explains the concrete gap, a mixed list containing a wildcard plus https://app.example.com, or a trailing comma, contained the wildcard but failed an equality check, so credentials were re-enabled and Starlette treated the list as allow-all. The fix tests membership and drops empty entries, with regression tests for both malformed configurations. It is precise and self-contained, though it assumes the reader saw the preceding commit and never restates why wildcard credentials are dangerous.