CVE-2026-61589: Host Header Propagation Failure in djust WebSocket Live Path Reconstructor

The djust library is a high-performance framework designed to bring Phoenix LiveView-style reactive, server-side rendering to Django applications through a Rust-powered backend. During standard operations, clients maintain a persistent WebSocket connection known as the live path to receive and render real-time UI updates. To process views and template logic within this persistent lifecycle, the library must dynamically reconstruct standard Django HttpRequest objects from the underlying ASGI WebSocket scope.

Prior to version 1.0.7, a critical design flaw existed in how djust executed this reconstruction mechanism. When handling a WebSocket connection, the library did not preserve the client's handshake HTTP Host header. This architectural omission meant that downstream routing, middleware, and database managers received a simulated HTTP request with incomplete state.

The omission directly exposed multi-tenant environments utilizing host-based resolution to severe authentication and isolation failures. If an application relied on custom resolvers mapping hostnames to database schemas or tenants, the unresolved host resulted in default values. Depending on the global application configuration, this behavior either exposed sensitive data belonging to arbitrary tenants or broke application functionality completely.

The root cause of the vulnerability lies in the implementation of the request builder mechanism inside djust. When instantiating simulated Django HttpRequest objects, djust relied on Django's testing utility, specifically RequestFactory().get(...). This utility is designed for unit testing environments and defaults the HTTP Host configuration parameter to "testserver" if no explicit HTTP_HOST is supplied.

When a client initiated a WebSocket handshake, the library parsed the path and query parameters from the ASGI scope but completely omitted the extraction of connection headers. Consequently, the invocation of RequestFactory().get(scope['path']) was executed without a defined host. Any subsequent call to request.get_host() inside Django views or tenant-resolver middleware resolved statically to "testserver".

The failure to propagate authentic headers bypassed the application's verification boundaries. Multi-tenant Django architectures typically resolve tenants by inspecting request.get_host() to extract the subdomain or domain name mapping. Because the live path request returned "testserver", the tenant resolver failed to map the incoming request to any active tenant, returning None instead of a valid database isolation key.

To understand the precise technical breakdown, we must analyze the dynamic request reconstruction phase before and after the release of version 1.0.7. The vulnerable path relied on direct RequestFactory calls without inspecting the headers key inside the ASGI connection dictionary. This allowed default settings to override critical client-provided parameters.

# Vulnerable Implementation in djust (< 1.0.7)
# The library dynamically instantiates RequestFactory without reading ASGI headers.
 
from django.test import RequestFactory
 
class ViewRuntime:
    def _build_request(self, scope):
        factory = RequestFactory()
        # The HTTP_HOST parameter is missing from the constructor argument list
        request = factory.get(scope['path'])
        # request.get_host() resolves to the hardcoded test framework default: "testserver"
        return request

# Patched Implementation in djust (>= 1.0.7)
# The library securely parses the ASGI headers, extracts Host, and validates it.
 
from django.test import RequestFactory
from django.utils.http import split_domain_port
from django.core.exceptions import DisallowedHost
 
class ViewRuntime:
    def _build_request(self, scope):
        # Extract raw headers list from ASGI scope
        headers = dict(scope.get('headers', []))
        
        # Safely retrieve the host header, defaulting to empty bytes
        host_bytes = headers.get(b'host', b'')
        host = host_bytes.decode('utf-8', errors='ignore') if host_bytes else "testserver"
        
        # Validate host against ALLOWED_HOSTS configuration
        try:
            domain, port = split_domain_port(host)
            # Perform standard Django ALLOWED_HOSTS validation here
        except ValueError:
            raise DisallowedHost("Malformed Host header received")
        
        factory = RequestFactory()
        # Explicitly propagate HTTP_HOST and server scheme parameters
        request = factory.get(
            scope['path'],
            HTTP_HOST=host,
            SECURE_PROXY_SSL_HEADER=scope.get('scheme', 'http')
        )
        return request

The implementation in version 1.0.7 successfully resolves the underlying flaw by extracting the host parameter from the ASGI scope's binary header list. The patch parses the host domain and port safely to prevent injection vectors, verifying the parameter against Django's allowed domain lists before constructing the request object. This guarantees that host-based resolution logic behaves identically under WebSocket contexts and standard synchronous HTTP cycles.

Exploitation of this vulnerability requires a specific set of target environment configurations and user privileges. An attacker must first authenticate as a legitimate user under a specific sub-tenant domain (e.g., tenant-a.example.com). The application must utilize the djust rendering engine on a WebSocket connection to fetch tenant-scoped records.

Once authenticated, the attacker establishes a WebSocket session on the live path to load or refresh a reactive page. The server processes the websocket payload and invokes ViewRuntime._build_request to build the template context. Because the Host header is omitted during this assembly, the internal system state sets the host identity to "testserver".

The tenant resolver is unable to map "testserver" to any tenant profile, which sets the tenant variable to None. In environments configured with STRICT_MODE=False, the application fallback logic assumes a global querying state. The database router then executes standard SQL queries without appending the isolation constraints, returning rows belonging to all active tenants back to the attacker's browser interface.

The security impact of CVE-2026-61589 varies directly with the isolation configuration of the host application. In multi-tenant environments where STRICT_MODE=False is enabled, the flaw allows low-privileged attackers to query cross-tenant datasets. This unauthorized data exposure violates core confidentiality requirements by exposing financial, personal, or administrative data across tenant boundaries.

Alternatively, in environments that enforce STRICT_MODE=True as a defensive default, the database manager restricts the query results to empty datasets when tenant resolution fails. While this prevents data leaks, it results in complete application functional denial-of-service on the live path. The WebSocket connection fails to populate the user interface with any valid records, leading to a broken tenant session.

The vulnerability has received a CVSS v3.1 score of 6.3 with a base vector string of CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. The network attack vector is combined with high attack complexity due to the requirement for specific host-based database isolation implementations. The scope parameter is marked as changed because the compromise of host resolution within the rendering component directly impacts isolation guarantees at the underlying database access layer.

The primary remediation path is to upgrade the djust package to version 1.0.7 or later, which contains the complete patch for Host header parsing. If upgrading cannot be accomplished immediately, operators must configure strict database isolation modes. This converts potential information disclosure vectors into deterministic application failures, mitigating confidentiality risks.

Organizations utilizing custom tenant resolvers must verify that fallback configurations reject unresolvable hosts rather than returning global records. Under no circumstances should database queries on multi-tenant backends execute without explicit schema or client filters when the resolver yields a None result.

Security engineers can monitor logs for anomalies indicative of this bypass. Specifically, tracing database logs for queries executing on the production database using the default hostname "testserver" provides high-fidelity detection of vulnerable pathways or active exploitation attempts.