| Package | Affected versions | Patched versions |
|---|---|---|
| directus | < 12.0.0 | 12.0.0 |
| directus | < 12.0.0 | 12.0.0 |
When response caching is enabled (CACHE_ENABLED=true), the cache-key derivation in api/src/utils/get-cache-key.ts includes only version, path, query, and accountability.user (plus a conditional ip). Authorization context beyond user (share, role, roles, admin, app, policies) is not part of the key.
For share tokens this is load-bearing. Directus's share-authentication flow (api/src/services/shares.ts:100-105) issues a JWT without an id claim, so api/src/utils/get-accountability-for-token.ts never assigns accountability.user, leaving it null (the default from create-default-accountability.ts). Every share token, and every anonymous request, therefore reduces to user: null in the cache-key input. Two different shares (or an anonymous request and a share token) requesting the same URL with the same query produce identical cache keys. The first request populates the bucket with a permission-filtered response; subsequent hits from unrelated shares or anonymous clients receive that payload without any permission re-evaluation.
This is the web-cache pattern "authorization-dependent response cached under an unsegmented key" (cache key collision / missing authorization context in cache key, CWE-524 and CWE-639). Two adjacent read populations collide:
Share A populates the cache, Share B reads Share A's scoped response.CACHE_ENABLED=true (any store: memory, redis, memcached) plus at least one active directus_shares row. This is not a default-on bug: CACHE_ENABLED ships as false. The cache is documented as a production performance setting, so operators who enable it are the ones affected.Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeuser=null. An anonymous client hitting /items/articles?fields=* after a share request has populated the cache receives the share's scoped payload with zero authentication.shares.login (JWT issuance). Once any share has populated the cache for a URL, an anonymous or alternate-share request to that URL retrieves the cached payload without exchanging the share password. This is the same cache-key collision surfacing as a password-protection bypass symptom, not a distinct mechanism.CACHE_TTL window (commonly 5 to 30 minutes). CACHE_AUTO_PURGE clears on mutating writes to cached collections but does not purge per-user or per-share. With CACHE_STORE=redis (common in production) the poisoned bucket survives server restarts.Scope of the leak depends on the share's permission surface. A share with no backing role (directus_shares.role = null, the default) collapses visibility to the primary key, so the cache leaks only PKs. A share backed by a role with broader field access (the intended production setup for distributing useful content) leaks the full content that role can see on the scoped item.