CVE-2026-61836: Directus Auth Bypass Vulnerability

CVE-2026-61836 Overview

CVE-2026-61836 is a cache key derivation flaw in Directus, a real-time API and app dashboard for managing SQL database content. Versions prior to 12.0.0 build cache keys from version, path, query, and accountability.user but omit authorization context including share, role, roles, admin, app, and policies. Because Directus share tokens and anonymous requests both reduce to a null user, different shares or anonymous clients requesting the same URL and query can receive a permission-filtered cached response without permission re-evaluation. The issue is fixed in version 12.0.0 and classified under [CWE-524: Use of Cache Containing Sensitive Information].

Critical Impact
Attackers using share links or anonymous requests can retrieve cached data intended for a different share scope, exposing records they were never authorized to view.

Affected Products

Directus versions prior to 12.0.0 with response caching enabled
Directus deployments issuing share tokens for restricted content
Directus APIs serving anonymous or share-based read requests

Discovery Timeline

2026-07-15 - CVE-2026-61836 published to NVD
2026-07-15 - Last updated in NVD database
Version 12.0.0 - Directus releases patched version addressing the cache key derivation

Technical Details for CVE-2026-61836

Vulnerability Analysis

The flaw resides in api/src/utils/get-cache-key.ts, which derives a deterministic cache key for each request. The derivation includes the request path, sanitized query, GraphQL variables, and accountability.user, but excludes the broader authorization surface. Directus enforces read permissions per role, policy, and share scope, so two requests with identical URLs but different authorization contexts should not resolve to the same cached document.

When response caching is enabled, the server returns a cached body for any subsequent request producing the same key. Because share tokens and unauthenticated visitors both resolve accountability.user to null, a request from share A and a request from share B for the same collection endpoint generate identical cache keys. The first response populates the cache with data filtered for that specific authorization context, and later requests receive it without re-evaluating permissions.

Root Cause

The cache key omits share, role, roles, admin, app, and policies. This violates the principle that any input influencing response contents must contribute to the cache key. The result is a permission-bypass condition where filtered data leaks across authorization boundaries.

Attack Vector

An attacker with any valid share link, or an anonymous client, issues a request to a cached endpoint immediately after a higher-privileged share user has queried it. The attacker receives the previously cached, permission-filtered payload belonging to the other scope. Exploitation requires no authentication and no user interaction over the network.

typescript

// Patch: api/src/utils/get-cache-key.ts (commit 7ba4efb)
// Add share to cache key (#27707)
		path,
		query: isGraphQl ? getGraphqlQueryAndVariables(req) : req.sanitizedQuery,
		...(flowTriggerQuery && { rawQuery: flowTriggerQuery }),
+		...(req.accountability?.share && { share: req.accountability.share }),
		...(includeIp && { ip: req.accountability!.ip }),
	};

Source: GitHub Commit 7ba4efb. The patch adds the share identifier into the cache key so that distinct shares no longer collide.

Detection Methods for CVE-2026-61836

Indicators of Compromise

Repeated successful anonymous or share-token requests to the same collection endpoints returning consistent payloads across distinct share identifiers.
Access log patterns showing multiple share tokens or unauthenticated clients hitting cached routes within short time windows.
User reports of unexpected records appearing in share-scoped views that exceed the share's configured filter.

Detection Strategies

Audit Directus deployments to identify instances running versions prior to 12.0.0 with the response cache enabled in CACHE_ENABLED.
Correlate share token identifiers with response body hashes in reverse-proxy logs to spot identical responses served across different share contexts.
Review application logs for cache-hit events on endpoints that should perform per-share permission filtering.

Monitoring Recommendations

Enable verbose access logging on the Directus API and forward it to a centralized analytics platform for query-pattern review.
Alert on high cache-hit ratios for endpoints scoped to share tokens, which may indicate cross-scope leakage.
Track anomalous growth in anonymous or share-token traffic to sensitive collections following deployment of new share links.

How to Mitigate CVE-2026-61836

Immediate Actions Required

Upgrade Directus to version 12.0.0 or later, which incorporates the fix from pull request #27707.
If upgrading is not immediately possible, disable response caching by setting CACHE_ENABLED=false until the patched release is deployed.
Rotate active share tokens after patching to invalidate any share links that may have been used to harvest cached data.

Patch Information

The fix is delivered in Directus v12.0.0. The patch in api/src/utils/get-cache-key.ts includes req.accountability.share in the cache key derivation, ensuring distinct share contexts produce distinct cache entries. Full context is available in the GitHub Security Advisory GHSA-c6w9-5g5j-jh2p.

Workarounds

Disable the response cache entirely for deployments that rely on share tokens or anonymous access to permission-filtered content.
Restrict share token issuance to non-sensitive collections until the upgrade to 12.0.0 is complete.
Place a permission-aware reverse proxy in front of Directus that varies its own cache by share identifier as an interim control.

bash

# Configuration example: disable response cache in Directus environment
CACHE_ENABLED=false
CACHE_AUTO_PURGE=true