CVE-2026-61589: djust: WebSocket/runtime reconstructed request omits the client Host, causing host/subdomain TenantResolvers to misresolve the tenant on the live path

Published Sep 16, 2026
·
Updated

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.

Other sources

djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, 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). This is 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. There is no known workaround on the live path short of upgrading. Users are most exposed when combined with STRICTMODE=False.

MITRE

Affected Software

2 affected componentsFixes available
djust<1.0.7
pip/djust<1.0.7
1.0.7

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/djust to a version that resolves this vulnerability.

    Fixed in 1.0.7
  2. Upgrade

    Upgrade djust to a version that resolves this vulnerability.

    Fixed in 1.0.7
  3. Configuration

    Set djust's STRICT_MODE to true, since issues are most exposed when combined with STRICT_MODE=False (cross-tenant disclosure / broken tenancy on the live path).

    djust STRICT_MODE = true

Event History

Sep 16, 2026
Advisory Published
via GitHub·10:07 PM
Data Sourced
via GitHub·10:07 PM
DescriptionSeverityWeaknessAffected Software
CVE Published
via MITRE·10:08 PM
Data Sourced
via MITRE·10:08 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to cross-tenant data disclosure?

Deployments using host, subdomain, or domain TenantResolvers on the WebSocket/live path are affected before djust 1.0.7. Exposure is greatest when STRICT_MODE=False, because tenant-scoped managers can return unscoped rows when live-path tenant resolution produces None.

2

Does the default configuration disclose data?

With the default strict mode, the live path returns an empty queryset rather than unscoped data, causing broken tenancy rather than the described cross-tenant disclosure. Setting STRICT_MODE=False changes that behavior to unscoped row access.

3

What does an attacker need to exploit the issue?

The issue affects requests that reach the WebSocket live path and rely on host-based tenant resolution. The reported vector requires network access, low privileges, and no user interaction.

4

What can be done if upgrading is not immediately possible?

No workaround is known for the live path short of upgrading to djust 1.0.7. The fixed version validates the handshake Host against ALLOWED_HOSTS and propagates it into the reconstructed request.

5

How can I determine whether my application is affected?

Check whether it uses djust before 1.0.7 together with a host, subdomain, or domain TenantResolver. Compare tenant resolution on a normal HTTP request and the equivalent WebSocket/live request; affected versions resolve the live request as None while HTTP resolves the expected tenant.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203