{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/directus-less-than-12.0.0/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[{"cvss":8.6,"id":"CVE-2026-61836"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Directus (less than 12.0.0)"],"_cs_severities":["high"],"_cs_tags":["authorization-bypass","cache-poisoning","cve","web-application"],"_cs_type":"advisory","_cs_vendors":["Directus"],"content_html":"\u003cp\u003eA critical vulnerability, CVE-2026-61836, has been identified in Directus versions prior to 12.0.0. This flaw, classified under CWE-524 and CWE-639, allows for an authorization bypass affecting instances where response caching (\u003ccode\u003eCACHE_ENABLED=true\u003c/code\u003e) is active. The issue stems from an incomplete cache-key derivation process in \u003ccode\u003eapi/src/utils/get-cache-key.ts\u003c/code\u003e, which fails to incorporate all necessary authorization contexts beyond the basic \u003ccode\u003euser\u003c/code\u003e identifier. Specifically, for share tokens and anonymous requests, the \u003ccode\u003euser\u003c/code\u003e attribute defaults to \u003ccode\u003enull\u003c/code\u003e, causing different share tokens or anonymous clients requesting the same URL and query to generate identical cache keys. This cache collision leads to unauthorized access; once a share populates the cache with its permission-filtered response, subsequent requests from other shares or anonymous users for the same resource retrieve the cached, potentially sensitive, payload without re-evaluating their specific permissions. The vulnerability is present in Directus deployments utilizing its caching feature, which is commonly enabled in production for performance benefits, and poses a significant risk of data exposure.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003ePrecondition\u003c/strong\u003e: A Directus instance is configured with \u003ccode\u003eCACHE_ENABLED=true\u003c/code\u003e and has at least one active \u003ccode\u003edirectus_shares\u003c/code\u003e configured, providing scoped read access to sensitive items (e.g., \u003ccode\u003e/items/articles\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eShare Configuration\u003c/strong\u003e: A legitimate administrator creates a share token (e.g., \u003ccode\u003eShare A\u003c/code\u003e) to grant specific, limited read access to particular data items within Directus.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Request\u003c/strong\u003e: A user possessing \u003ccode\u003eShare Token A\u003c/code\u003e makes an authenticated request to access shared, sensitive data (e.g., \u003ccode\u003eGET /items/articles/123\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCache Population\u003c/strong\u003e: Directus processes the request, applies the specific authorization rules associated with \u003ccode\u003eShare Token A\u003c/code\u003e, retrieves the appropriate permission-filtered data, and stores this response in the configured cache.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCache Key Derivation Flaw\u003c/strong\u003e: The cache key is generated using an incomplete set of authorization contexts (e.g., \u003ccode\u003eversion\u003c/code\u003e, \u003ccode\u003epath\u003c/code\u003e, \u003ccode\u003equery\u003c/code\u003e, and \u003ccode\u003eaccountability.user\u003c/code\u003e), with \u003ccode\u003eaccountability.user\u003c/code\u003e being \u003ccode\u003enull\u003c/code\u003e for share tokens and anonymous requests.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSubsequent Request\u003c/strong\u003e: A different user, either holding \u003ccode\u003eShare Token B\u003c/code\u003e (distinct from \u003ccode\u003eShare A\u003c/code\u003e) or making an anonymous request, attempts to access the \u003cem\u003eexact same URL\u003c/em\u003e (\u003ccode\u003eGET /items/articles/123\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCache Hit \u0026amp; Bypass\u003c/strong\u003e: Due to the identical cache key derived from the previous request, Directus retrieves and serves the already cached response without performing a fresh authorization check against \u003ccode\u003eShare Token B\u003c/code\u003e's or the anonymous user's specific permissions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Data Access\u003c/strong\u003e: The second user (with \u003ccode\u003eShare Token B\u003c/code\u003e or anonymous) gains unauthorized access to the sensitive data originally filtered and intended only for \u003ccode\u003eShare Token A\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability can lead to severe cross-share confidentiality breaches. Any permission-filtered response populated in the cache by one share token can be served to any other share token holder or an anonymous request that subsequently hits the same URL and query, bypassing intended authorization. For instance, an anonymous client could retrieve sensitive, share-scoped data without any authentication. While password protection on shares exists at the JWT issuance stage, a cached response bypasses this once populated. The data leak persists for the duration of the \u003ccode\u003eCACHE_TTL\u003c/code\u003e window (typically 5-30 minutes) and can survive server restarts if \u003ccode\u003eCACHE_STORE=redis\u003c/code\u003e is used. The scope of the leaked data depends on the original share's permissions, ranging from primary keys to full content for shares backed by roles with broader field access. The bypass is read-only, meaning no write operations are affected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePatch CVE-2026-61836\u003c/strong\u003e: Upgrade all Directus instances to version 12.0.0 or newer immediately to mitigate the vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReview \u003ccode\u003eCACHE_ENABLED\u003c/code\u003e Configuration\u003c/strong\u003e: For instances that cannot be immediately patched, consider disabling \u003ccode\u003eCACHE_ENABLED\u003c/code\u003e by setting it to \u003ccode\u003efalse\u003c/code\u003e in your Directus configuration, especially if \u003ccode\u003edirectus_shares\u003c/code\u003e are in use and sensitive data is involved.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAudit Share Configurations\u003c/strong\u003e: Review all \u003ccode\u003edirectus_shares\u003c/code\u003e to ensure they adhere to the principle of least privilege, minimizing the amount of sensitive data exposed even in the event of a bypass.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-20T21:49:23Z","date_published":"2026-07-20T21:49:23Z","id":"https://feed.craftedsignal.io/briefs/2026-07-directus-cache-key-auth-bypass/","summary":"A vulnerability in Directus allows for an authorization bypass when response caching is enabled, leading to cross-share confidentiality breaches where sensitive data scoped for one share can be accessed by another share token holder or anonymous users due to an unsegmented cache key.","title":"Directus Authorization Bypass via Cache Key Collision (CVE-2026-61836)","url":"https://feed.craftedsignal.io/briefs/2026-07-directus-cache-key-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Directus (Less Than 12.0.0)","version":"https://jsonfeed.org/version/1.1"}