Contact Details
No response
📦 Package Version
latest
🎞️ Framework Version
latest
🔎 Describe the Bug
[Security] Hardcoded fallback signing key for authentication session cookies
Summary
When AUTH_COOKIE_SECRET is unset, authentication uses the hardcoded _DEV_AUTH_COOKIE_SECRET fallback. This value signs session JWT cookies, allowing anyone who obtains the fallback to create tokens that pass signature verification.
Affected Version
Affected version: commit f8e907b92dabe47232978023fdcb01e2a7d4b752 on branch main.
Technical Details and Root Cause
AUTH_COOKIE_SECRET is configured with a hardcoded fallback in environment.py#L7. The fallback is used by the authentication flow, where the secret is passed to jwt.encode to sign a session cookie at views.py#L147, and the cookie is subsequently verified using the same authentication flow at views.py#L157.
The literal fallback value is not present in the referenced records. A server-side session cache is also involved in resolving the token’s session_id through session.py#L45-L62 and middleware.py#L40-L49, which may constrain the identity associated with a forged token.
Impact
An attacker who obtains the committed fallback and can reach the session-cookie authentication flow may forge JWT session cookies that pass signature verification. The affected identity and authorization scope depend on the server-side session lookup and deployment configuration, and require maintainer confirmation.
Reproduction Conditions
Use a deployment of the affected commit with AUTH_COOKIE_SECRET unset, so the code-defined fallback is selected. Trace the existing session-cookie issuance and verification flow to confirm that both signing and verification use the fallback-derived AUTH_COOKIE_SECRET.
Recommended Fix
Remove the committed fallback and require a unique, high-entropy secret for every deployment, supplied through a server-side secret manager. Rotate any deployments that may have used the fallback. Keep authentication credentials limited to necessary claims, and ensure signing keys are never derived from passwords or other predictable values.
This observation was identified during our ongoing research on authentication token security. We would be happy to provide additional technical details or assistance with preparing a patch. Please feel free to contact us if any clarification is needed.
🤝 Contribution
Contact Details
No response
📦 Package Version
latest
🎞️ Framework Version
latest
🔎 Describe the Bug
[Security] Hardcoded fallback signing key for authentication session cookies
Summary
When
AUTH_COOKIE_SECRETis unset, authentication uses the hardcoded_DEV_AUTH_COOKIE_SECRETfallback. This value signs session JWT cookies, allowing anyone who obtains the fallback to create tokens that pass signature verification.Affected Version
Affected version: commit
f8e907b92dabe47232978023fdcb01e2a7d4b752on branchmain.Technical Details and Root Cause
AUTH_COOKIE_SECRETis configured with a hardcoded fallback inenvironment.py#L7. The fallback is used by the authentication flow, where the secret is passed tojwt.encodeto sign a session cookie atviews.py#L147, and the cookie is subsequently verified using the same authentication flow atviews.py#L157.The literal fallback value is not present in the referenced records. A server-side session cache is also involved in resolving the token’s
session_idthroughsession.py#L45-L62andmiddleware.py#L40-L49, which may constrain the identity associated with a forged token.Impact
An attacker who obtains the committed fallback and can reach the session-cookie authentication flow may forge JWT session cookies that pass signature verification. The affected identity and authorization scope depend on the server-side session lookup and deployment configuration, and require maintainer confirmation.
Reproduction Conditions
Use a deployment of the affected commit with
AUTH_COOKIE_SECRETunset, so the code-defined fallback is selected. Trace the existing session-cookie issuance and verification flow to confirm that both signing and verification use the fallback-derivedAUTH_COOKIE_SECRET.Recommended Fix
Remove the committed fallback and require a unique, high-entropy secret for every deployment, supplied through a server-side secret manager. Rotate any deployments that may have used the fallback. Keep authentication credentials limited to necessary claims, and ensure signing keys are never derived from passwords or other predictable values.
This observation was identified during our ongoing research on authentication token security. We would be happy to provide additional technical details or assistance with preparing a patch. Please feel free to contact us if any clarification is needed.
🤝 Contribution