djust CVE-2026-61596

Requires an authenticated djust application user (PR:L) and a view that defines a custom get_object (object-scoped view) - views without a custom get_object are explicitly unaffected (no-op). Exploitation works only against djust < 1.0.7 where the object-scoped view is exposed through any of three specific render entry points: the initial HTTP GET render, SPA url_change navigation, or a {% live_render %} embedded child (eager or lazy). Limiting factors: the attacker must already hold a valid account, must know or enumerate the target object identifier, and the target view must implement per-object authorization via get_object/has_object_permission (ADR-017); the WebSocket mount and event paths were already protected and are not vectors. No non-default configuration is otherwise needed.

This is a genuine but moderate-priority authorization flaw. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, base 7.1) indicates network-reachable, low-complexity exploitation requiring only a low-privileged authenticated account and no user interaction - a realistic profile for a multi-tenant web app where any registered user can attempt IDOR. Confidentiality impact is High (viewing objects the user is not authorized for) with Low integrity impact (the advisory notes the user can 'on some paths act on' the object) and no availability impact. There is NO CISA KEV listing, NO public POC, and NO EPSS score in the provided data, so there is no evidence of active or imminent exploitation - this is a defensive/patch-hygiene priority, not an emergency. The primary risk driver is the low exploitation barrier (any authenticated user, default configuration, no special feature toggle), tempered by the low real-world footprint of the affected framework. The input tag 'Authentication Bypass' is a mislabel: CWE-639 and the advisory both describe broken object-level authorization (IDOR), not authentication bypass - the attacker must already be authenticated.

An authenticated low-privileged user of a djust-based application identifies an object-scoped view (e.g., /orders/1234) and directly loads a URL for an object ID belonging to another tenant/user via HTTP GET, SPA url_change navigation, or by composing it as a {% live_render %} embedded child - all three paths bypassed the get_object/has_object_permission checks that were enforced only on WebSocket mount/event. The unauthorized object renders, disclosing its data and on some paths permitting actions on it. No public POC is identified at time of analysis.