CVE-2026-61588: djust's Django model serialization has no sensitive-field denylist: password hashes, privilege flags, and PII on a public view attribute are sent to the client
Impact When a Django Model instance is assigned to a public view attribute, djust serialized it to the client with no sensitive-field denylist — sending fields such as password (the hash), privilege flags (e.g. isstaff / issuperuser), tokens, and other PII to the browser. Because exposing model objects to templates is a normal djust pattern, this could leak credentials/PII without the developer realizing the full object crossed the wire.
Patches Fixed in djust 1.0.7. Model serialization applies a secure-by-default sensitive-field denylist (password/hash/token/secret-style fields and known privilege flags are withheld) with an identity-subset fallback.
Workarounds Keep Model instances on private attributes and expose only the specific fields needed, until patched.
Other sources
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, when a Django Model instance is assigned to a public view attribute, djust serialized it to the client with no sensitive-field denylist — sending fields such as password (the hash), privilege flags (e.g. isstaff / issuperuser), tokens, and other PII to the browser. Because exposing model objects to templates is a normal djust pattern, this could leak credentials/PII without the developer realizing the full object crossed the wire. This is fixed in djust 1.0.7. Model serialization applies a secure-by-default sensitive-field denylist (password/hash/token/secret-style fields and known privilege flags are withheld) with an identity-subset fallback. As a workaround, keep Model instances on private attributes and expose only the specific fields needed, until patched.
— MITRE
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 - Configuration
As a workaround until patched, keep Django `Model` instances on `_private` attributes and expose only the specific fields needed; do not assign `Model` instances to public view attributes (which, prior to djust 1.0.7, are serialized to the client with no sensitive-field denylist, leaking fields such as `password` hashes, privilege flags like `is_staff`/`is_superuser`, tokens, and other PII).
djust (Django Model exposure to templates/views) Use of public view attributes for Django Model instances = Keep Model instances on _private attributes
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using djust before version 1.0.7 are exposed when they assign Django Model instances to public view attributes. This is a normal djust usage pattern, so affected applications may expose data even if developers did not intend to send the complete model to the browser.
What information could an attacker obtain?
A client receiving the serialized model may obtain password hashes, privilege flags such as is_staff or is_superuser, tokens, secrets, and other personally identifiable information stored in model fields. The issue affects confidentiality; no integrity or availability impact is stated.
Does exploitation require authentication or user interaction?
The vulnerability is network-accessible, requires low privileges, and does not require user interaction according to the supplied vector. An attacker needs access to a view that exposes a Model instance through a public djust view attribute.
What can be done before upgrading?
Keep Django Model instances on _private attributes and expose only the specific fields required by the client. This avoids serializing the complete model through a public view attribute until djust can be upgraded.
How does version 1.0.7 change the behavior?
Version 1.0.7 adds a secure-by-default denylist that withholds password, hash, token, secret-style, and known privilege fields during model serialization. It also uses an identity-subset fallback.