Directus CVE-2026-61836

Exploitation requires response caching to be enabled in Directus (not enabled by default), and requires that a cacheable response for the exact same path and query string was already cached by a principal with different effective permissions - specifically a Directus share token or an authenticated user whose accountability.user resolves differently from the attacker. The attacker (an anonymous client or a different share-token holder) must request the identical URL and query while that cache entry is live. Limiting factors: the flaw is inert if caching is off, if URLs/queries differ between principals, or if no higher-privileged request has populated the cache; disclosure is bounded to whatever data the caching principal was permitted to see, not the entire database.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, base 8.6) reflects a network-reachable, unauthenticated confidentiality breach with a scope change, which matches a cache that leaks one principal's authorized data to another. Real-world risk is meaningfully gated by two preconditions the base score under-weights: response caching must be explicitly enabled (it is not on by default), and a cacheable response for the exact path and query must have been populated by a principal whose permissions differ from the attacker's. No EPSS score, KEV listing, or POC was provided, so this is a real but not urgent priority: no evidence of active exploitation, and impact is limited to disclosure of data already exposed to some share or role, not full database compromise. I assess AC as higher than the NVD's AC:L because exploitation depends on cache state seeded by another principal; on a busy instance this happens through normal traffic, so defenders running caching with shares should treat it as a genuine data-segregation failure rather than a theoretical one.

On a Directus instance with response caching enabled, a share link (or an authenticated user) first requests a filtered collection endpoint, populating the cache with a permission-filtered response. An anonymous visitor or a holder of a different share token then requests the identical URL and query and is served that cached response without permission re-evaluation, disclosing records they should not see. No public POC is identified, but the technique requires only normal HTTP requests to matching URLs.