CVE-2026-61591 in djust
Summary
by MITRE • 09/17/2026
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, for views that opt into state snapshots, the snapshot `state_json` embedded in the client page was restored on reconnect as trusted view state with no integrity check. A client could edit the unsigned `state_json` in their page and return it in the reconnect mount frame to inject arbitrary view attributes — e.g. flip `is_admin` to `True`, or change `account_id` / `balance` — escalating privilege or tampering with business state held in public view attributes (the normal djust pattern). This issue is fixed in djust 1.0.7. State snapshots are signed; unsigned or forged snapshots are rejected on the back-navigation restore path. As a workaround, do not enable state snapshots; do not hold authorization/ownership state in public view attributes.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of the djust library prior to 1.0.7 represents a critical failure in server-side integrity verification for reactive web applications built with Django and Rust. This issue specifically affects views that utilize state snapshots, a feature designed to optimize performance by preserving client-side view state across network interruptions or page navigations. In this architecture, the current application state is serialized into JSON format and embedded within the HTML sent to the browser. When a user reconnects after a disconnection, the frontend framework restores this snapshot as the trusted source of truth for the view's internal state without performing any cryptographic validation or integrity checks on the data payload. This design assumption that the client-side storage remains unmodified is fundamentally flawed in adversarial environments where users have full control over their local execution context and network traffic.
From a technical perspective, this flaw constitutes an insecure direct object reference combined with improper input validation, aligning closely with CWE-20 Improper Input Validation and CWE-641 Improper Restriction of Names for Files and Directories when considering the manipulation of internal state identifiers. The absence of digital signatures or message authentication codes on the serialized state_json allows attackers to manipulate critical variables such as is_admin flags, account IDs, or financial balances directly within their browser's developer tools or by intercepting and modifying HTTP requests during the reconnect mount phase. Because the server blindly trusts this restored state, an attacker can escalate privileges from a standard user to an administrator role or alter business logic parameters that dictate resource ownership and access rights. This mechanism bypasses traditional authentication checks because the authorization decisions are often derived directly from these manipulated view attributes rather than being re-verified against a secure session store or database on every request.
The operational impact of this vulnerability is severe, enabling remote attackers to achieve unauthorized privilege escalation and data tampering with minimal effort. By simply editing the unsigned JSON object in their local environment and triggering a reconnect event, an attacker can inject arbitrary view attributes that propagate directly into the server-side processing logic. This leads to potential full account takeover if administrative flags are flipped or financial fraud if balance fields are modified. The vulnerability exploits the trust model inherent in single-page application frameworks where state persistence is convenient but often implemented without sufficient security controls for sensitive data. It effectively neutralizes any client-side access control measures, as the server accepts the manipulated state as legitimate context for subsequent operations.
This incident maps directly to several techniques within the MITRE ATT&CK framework, particularly T1078 Valid Accounts and T1249 Enforce Privilege Constraints via Logic Flaws or Misconfiguration. The attacker leverages valid credentials but manipulates the underlying state representation to bypass intended restrictions, which is characteristic of privilege escalation through application logic errors rather than traditional exploitation of buffer overflows or injection flaws. The lack of server-side re-validation for critical security attributes during state restoration highlights a gap in defense-in-depth strategies where client-provided data should never be trusted without rigorous verification against authoritative sources like databases or secure session stores.
To mitigate this vulnerability, organizations must upgrade to djust version 1.0.7 or later immediately, as the patch introduces cryptographic signing for all state snapshots and rejects any unsigned or forged payloads during the back-navigation restore process. This ensures that only server-generated, tamper-proof state data is accepted by the backend logic. For environments where upgrading is not immediately feasible, a recommended workaround involves disabling state snapshots entirely to eliminate the attack vector associated with client-side persistence of sensitive data. Additionally developers should adhere to strict security principles by never storing authorization status, ownership identifiers, or financial values in public view attributes that are exposed to the client side. Instead, such critical information must be retrieved dynamically from secure server-side storage during each request cycle, ensuring that access control decisions are always based on verified, up-to-date data rather than potentially manipulated local state representations.