CVE-2026-61595: Multi-Tenancy Isolation Bypass on WebSocket and SSE Paths in djust

The djust framework provides high-performance, reactive rendering mechanisms modeled after Phoenix LiveView within Django. To maintain data boundaries in multi-tenant installations, the djust.tenants module filters database QuerySet results using a tenant identifier established during initial requests.

Traditional HTTP requests pass through standard WSGI/ASGI middleware (TenantMiddleware), which resolves and binds the tenant identifier to the current thread. However, live channels such as WebSockets and Server-Sent Events (SSE) operate outside this synchronous request-response flow. This design exposes a significant gap in state initialization for persistent, asynchronous event-driven loops.

On these asynchronous execution paths, the database queries triggered by user-driven live updates do not evaluate against the authorized tenant ID. Instead, the query manager encounters an uninitialized context and defaults to executing unrestricted, global queries. This exposes a direct path to cross-tenant data disclosure.

The root cause of this vulnerability lies in the combination of thread-local context storage and a fail-open query model under asynchronous execution models.

First, djust relied on threading.local() to isolate tenant data per execution thread. In modern ASGI applications, incoming connections are managed inside an asynchronous event loop, with synchronous operations offloaded to a thread pool via Django's sync_to_async wrapper. Because threads in this pool are recycled and shared dynamically across distinct async tasks, the thread-local storage is either entirely empty or polluted with context remnants from completely unrelated execution threads.

Second, the system designed the database manager to fail open when the resolved tenant context was null. Instead of raising an exception or returning an empty set when get_current_tenant() returned None, the QuerySet manager allowed the database query to proceed without filtering. This implementation design meant that any query executing within a thread lacking a tenant context bypassed all isolation constraints, as depicted in the execution flow below:

The vulnerable query management logic in the djust.tenants manager was structured to fallback to an unfiltered parent query when the thread context returned None:

# Insecure implementation prior to v1.0.7
from django.db import models
from threading import local
 
_thread_locals = local()
 
def get_current_tenant():
    return getattr(_thread_locals, 'tenant_id', None)
 
class TenantManager(models.Manager):
    def get_queryset(self):
        tenant_id = get_current_tenant()
        if tenant_id is None:
            # Fails open: returns all rows across all tenants
            return super().get_queryset()
        return super().get_queryset().filter(tenant_id=tenant_id)

The fix implemented in djust version 1.0.7 migrated context tracking to contextvars.ContextVar, which natively tracks state across asynchronous tasks and coroutines. It also redesigned the manager to fail closed when STRICT_MODE is enabled:

# Remediated implementation in v1.0.7
import contextvars
from django.db import models
from django.core.exceptions import PermissionDenied
from django.conf import settings
 
# ContextVar safely tracks tenant across asynchronous coroutines
current_tenant_id = contextvars.ContextVar('tenant_id', default=None)
 
class TenantManager(models.Manager):
    def get_queryset(self):
        tenant_id = current_tenant_id.get()
        if tenant_id is None:
            # Fails closed when STRICT_MODE is True
            if getattr(settings, 'DJUST_STRICT_MODE', True):
                return super().get_queryset().none()
            # Log warning if strict mode is disabled
            return super().get_queryset()
        return super().get_queryset().filter(tenant_id=tenant_id)

Exploitation of this vulnerability requires an attacker to possess valid credentials for any single, low-privileged tenant account within the platform. The attacker does not need high-level administrative access or advanced permissions.

First, the attacker authenticates normally through the standard login interface. This populates their session cookie and associated authentication tokens.

Second, the attacker establishes a WebSocket connection or opens an SSE stream to the reactive djust routing endpoint. Because the connection handshake succeeds, the ASGI worker handles subsequent data-fetch events.

Third, when the attacker triggers state synchronizations or parameters updates via WebSocket payloads, the server processes these updates in a thread pool execution task. The worker executes the underlying database queries without establishing the tenant identifier in the local context. The database queries return complete, unfiltered tables. These tables are then serialized and transmitted back through the WebSocket frame to the attacker, exposing cross-tenant records.

The impact of CVE-2026-61595 is severe. In a multi-tenant software-as-a-service application, the absolute isolation of tenant data is a fundamental security contract. A failure in this boundary compromises the confidentiality of all customer records stored in the shared database.

The CVSS v3.1 base score of 7.7 represents a high-severity flaw. The Attack Vector is Network (AV:N), meaning the vulnerability can be reached remotely. Attack Complexity is Low (AC:L) as it is reproducible over standard WebSockets. Privileges Required is Low (PR:L) since any tenant authentication suffices.

The scope is marked as Changed (S:C) because the exploitation of a bug in the reactive rendering layer directly breaks isolation in the logical database access layer. The confidentiality impact is High (C:H) as all tenant tables configured with the flawed manager are readable. Because it is a read-only data disclosure bug on this specific execution path, integrity and availability scores remain None (I:N / A:N).

The recommended remediation is to upgrade djust to version 1.0.7 or later, which shifts state storage to ContextVar and enforces fail-closed query behavior on WebSocket routes.

For systems that cannot be immediately updated, administrators must enforce STRICT_MODE in their Django settings. This forces the database manager to return an empty queryset (.none()) if the tenant context cannot be resolved, converting a data exposure into a service limitation.

Furthermore, developers should run the Django system check framework (python manage.py check) post-upgrade to detect any insecure configurations. This execution validates that STRICT_MODE remains active and that no critical paths bypass context verification.