Don't pair wildcard CORS origin with credentials
fix(api): don't pair wildcard CORS origin with credentials
Don't pair wildcard CORS origin with credentials09567a-fix-don-t-pair-wildcard-cors-origin-cve-2026-61736fixdon pair wildcard cors origin credentials
Committed by claude
commit message
fix(api): don't pair wildcard CORS origin with credentials
The CORS middleware hardcoded allow_credentials=True while CORS_ORIGINS
defaults to "*". Per the Fetch spec these are mutually exclusive, and the
combination makes Starlette reflect any cookie-bearing origin with
Access-Control-Allow-Credentials: true.
LightRAG authenticates via the Authorization (Bearer) and X-API-Key request
headers, never via cookies or other ambient credentials, so credentials are
only meaningful for an explicit origin allowlist. Disable credentials when
origins are wildcarded, keeping the configuration spec-compliant and removing
the latent permissive-CORS risk for deployments that front the server with
cookie/Basic auth.
Add regression tests pinning both behaviors and document CORS_ORIGINS in the
env templates.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_017ZwddG56G4QwLcbEsYLxmdEditor assessment
This commit patches CVE-2026-61736. The subject is a crisp imperative that explains the fix itself: never pair a wildcard CORS origin with credentials. The body justifies it technically, noting that allow_credentials was hardcoded true while CORS_ORIGINS defaults to a wildcard, that the Fetch spec forbids the combination, and that Starlette would reflect any cookie-bearing origin with the credentials header. It then reasons from the app's authentication model, Bearer and X-API-Key headers rather than cookies, to show credentials only matter for an explicit allowlist. Regression tests and env-template documentation are mentioned. Excellent rationale.