GHSA-v9rj-xjfv-xj9r: Medium severity pip/djust vulnerability
Impact The WebSocket handlemount and ViewRuntime.buildrequest rebuild an HttpRequest via RequestFactory().get(...) with no HTTPHOST, so request.gethost() defaulted to "testserver" on the live path. Host/subdomain/domain TenantResolvers then misresolved the tenant — None on the live path while the HTTP path resolved correctly. With STRICTMODE=False the tenant-scoped managers returned unscoped rows (cross-tenant disclosure); with the default they returned an empty queryset (broken tenancy).
Patches Fixed in djust 1.0.7. The handshake Host is extracted from the ASGI scope, validated against ALLOWEDHOSTS (the same logic as the CSWSH Origin gate, parsed with Django's splitdomainport so malformed Hosts are rejected at the boundary), and propagated — with the TLS scheme — into the reconstructed request, so live-path tenant resolution matches HTTP exactly.
Workarounds No workaround on the live path short of upgrading. Most exposed when combined with STRICTMODE=False.
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
Event History
Frequently Asked Questions
Which deployments are most exposed to cross-tenant data disclosure?
Deployments using WebSocket live paths with host, subdomain, or domain-based TenantResolvers are affected by the tenant misresolution. Exposure is greatest when STRICT_MODE=False, because tenant-scoped managers can return unscoped rows.
Does the default STRICT_MODE setting expose tenant data?
With the default strict mode, the affected live path returns an empty queryset rather than unscoped tenant data. This causes broken tenancy, while STRICT_MODE=False can result in cross-tenant disclosure.
What does an attacker need to exploit the issue?
The supplied severity vector indicates network access, low privileges, no user interaction, and high confidentiality impact. Exploitation applies to the affected WebSocket live path where tenant resolution depends on the request host.
What can be done if an upgrade cannot be applied immediately?
There is no workaround for the live path short of upgrading. The issue is fixed in djust 1.0.7; deployments using STRICT_MODE=False should be prioritized.