https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-05T21:58:31.967923+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/euvd-2026-338078 EUVD-2026-338078 2026-10-05T21:58:32.017223+00:00 EUVD-2026-338078 https://cve.radiocsirt.org/vuln/fkie_cve-2026-61836 fkie_cve-2026-61836 2026-10-05T21:58:32.017272+00:00

Directus is a real-time API and App dashboard for managing SQL database content. Prior to 12.0.0, when response caching is enabled, the cache-key derivation in api/src/utils/get-cache-key.ts includes version, path, query, and accountability.user but omits authorization context such as share, role, roles, admin, app, and policies. Directus share tokens and anonymous requests can both reduce to user null, so different shares or anonymous clients requesting the same URL and query can receive a permission-filtered cached response without permission re-evaluation. This issue is fixed in version 12.0.0.

 https://cve.radiocsirt.org/vuln/ghsa-c6w9-5g5j-jh2p GHSA-c6w9-5g5j-jh2p — Directus: Authorization-dependent response served from unsegmented cache key 2026-10-05T21:58:32.017312+00:00

Affected: npm: directus

## Summary

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 to share:** `Share A` populates the cache, `Share B` reads `Share A`'s scoped response. - **Share to anonymous** (and the reverse): any unauthenticated client hitting the…