GHSA-3492-cvg7-9mr2: High severity pip/djust vulnerability
Impact djust.tenants isolation was enforced only on the HTTP path. The current tenant was stored in threading.local() and set exclusively by the HTTP-only TenantMiddleware, so on the live (WebSocket/SSE) path getcurrenttenant() was always None during mount and every event handler — and the tenant-aware QuerySet manager failed OPEN (returned the unfiltered queryset, ignoring STRICTMODE), disclosing every tenant's rows to whoever held the socket. threading.local was additionally shared across connections on the synctoasync executor thread.
Patches Fixed in djust 1.0.7. Tenant storage moved to a contextvars.ContextVar (per async task); the resolved tenant is bound around WS/SSE mount and every dispatch; both managers scope the base queryset once and fail CLOSED (.none() under the default STRICTMODE); and system check S006 warns when STRICTMODE=False.
Workarounds No workaround on the live path short of upgrading.
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
Ensure djust.tenants isolation enforces fail CLOSED behavior: set STRICT_MODE=True (note: system check S006 warns when STRICT_MODE=False).
djust.tenants STRICT_MODE = true - Configuration
Apply the fix that moves tenant storage to contextvars.ContextVar per async task and scopes the base queryset once per WS/SSE mount and dispatch, failing CLOSED via .none() under default STRICT_MODE.
djust.tenants tenant isolation implementation = contextvars.ContextVar - Compensating control
As no live-path workaround exists short of upgrading, restrict live WebSocket/SSE access so only authorized tenants can connect until djust 1.0.7 is deployed.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using djust live paths, specifically WebSocket or SSE connections, are exposed. HTTP requests use TenantMiddleware and are not the affected path described here.
What does an attacker need to exploit it?
The attacker needs to hold a live WebSocket or SSE connection. On that path, tenant context was not set during mounting or event handling, causing tenant-aware querysets to return unfiltered rows.
Does enabling STRICT_MODE protect affected live connections?
No. On the affected live path, the tenant-aware QuerySet manager failed open and returned an unfiltered queryset even when STRICT_MODE was enabled.
What can be done if an upgrade cannot be applied immediately?
No workaround is available for the live path short of upgrading. Upgrade djust to 1.0.7, which binds tenant context for WebSocket/SSE processing and changes the managers to fail closed.