GHSA-pg97-jvmf-qfvc: CSRF
Impact The SSE client→server POST endpoints are @csrfexempt and the SSE GET stream endpoint had no Origin check, so a cross-origin page could drive a victim-cookie-authenticated SSE session: force the victim's browser to GET the stream URL (which creates and mounts a LiveView as the victim) and POST to the message endpoint with credentials: include to fire state-changing event handlers as the victim. The URL sessionid is client-chosen (validated only for UUID format), so it is not a CSRF token, and a JSON body sent as text/plain is a CORS simple request with no preflight.
Patches Fixed in djust 1.0.7. All three SSE endpoints validate the request Origin against ALLOWEDHOSTS (mirroring the WebSocket CSWSH defense) and reject cross-origin requests with 403; the POST endpoints additionally require Content-Type: application/json (415 otherwise), closing the text/plain simple-request bypass.
Workarounds Disable the SSE transport, or front it with a proxy that enforces an Origin allowlist.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/djustto a version that resolves this vulnerability.Fixed in 1.0.7 - Upgrade
Upgrade
djustto a version that resolves this vulnerability.Fixed in 1.0.7 - Configuration
Disable the SSE transport to prevent cross-origin attempts.
SSE transport SSE enabled = false - Compensating control
Front the SSE with a proxy that enforces an Origin allowlist (rejects cross-origin requests) for the SSE endpoints.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the djust SSE transport are exposed if they rely on victim-cookie authentication. The affected flow includes the SSE stream endpoint and the client-to-server POST message endpoints.
What does an attacker need to exploit it?
An attacker needs to convince an authenticated victim to visit a cross-origin page. That page can cause the victim's browser to create and mount a LiveView through the stream URL and send state-changing messages using the victim's cookies.
Are client-chosen session IDs sufficient protection?
No. The session_id is client-chosen and validated only as a UUID format, so it does not function as a CSRF token.
What can be done before upgrading?
Disable the SSE transport, or place it behind a proxy that enforces an Origin allowlist. The fix is available in djust 1.0.7.
How does the patched behavior block the attack?
The patched SSE endpoints validate Origin against ALLOWED_HOSTS and reject cross-origin requests with HTTP 403. The POST endpoints also require Content-Type: application/json and return HTTP 415 for other content types, preventing the text/plain simple-request bypass.