https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-05T15:54:25.966807+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/euvd-2026-339142 EUVD-2026-339142 2026-10-05T15:54:26.011840+00:00 EUVD-2026-339142 https://cve.radiocsirt.org/vuln/fkie_cve-2026-61835 fkie_cve-2026-61835 2026-10-05T15:54:26.011881+00:00

Directus is a real-time API and App dashboard for managing SQL database content. Prior to 12.0.0, the SSRF protection on Directus's file-import-from-URL feature can be bypassed using the address 0.0.0.0 because api/src/request/is-denied-ip.ts treats 0.0.0.0 as a keyword for local interfaces but never blocks the literal address itself. On Linux and macOS, connecting to 0.0.0.0 reaches localhost, so an authenticated user with file-upload rights can make the server fetch internal services through the /files/import endpoint and retrieve the response as a downloadable file. This issue is fixed in version 12.0.0.

 https://cve.radiocsirt.org/vuln/ghsa-j5h6-vqc3-phqh GHSA-j5h6-vqc3-phqh — Directus: SSRF Protection Bypass via 0.0.0.0 in File Import 2026-10-05T15:54:26.011918+00:00

Affected: npm: directus

### Summary

The SSRF protection on Directus's file-import-from-URL feature can be bypassed using the address `0.0.0.0`. While `127.0.0.1` and other internal addresses are denied, `0.0.0.0` is not added to the blocklist. On Linux and macOS, connecting to `0.0.0.0` reaches localhost, so an authenticated user with file-upload rights can make the server fetch internal services and retrieve the response as a downloadable file (full-read SSRF).

### Affected Versions

- **Affected:** Directus `<= 12.0.0` (confirmed on `directus/directus:latest`, v11.17.3, with default configuration) - **Patched:** Directus `>= 12.0.0`

### Details

Directus uses a deny-list config, `IMPORT_IP_DENY_LIST`, whose default value is `['0.0.0.0', '169.254.169.254']`.

The issue is in how `api/src/request/is-denied-ip.ts` processes this list. When it encounters the entry `0.0.0.0`, it treats it as a special keyword meaning "block all local network interfaces," but it never blocks the literal address `0.0.0.0` itself. The handler sets the network-interface flag and skips to the next entry without adding `0.0.0.0` to the blocklist.

What actually gets blocked is the loopback subnet `127.0.0.0/8` (from the `lo` interface) plus whatever addresses are assigned to the machine's network interfaces. The address `0.0.0.0` is not inside `127.0.0.0/8`; it belongs to the separate `0.0.0.0/8` range. So a request to `http://0.0.0.0:8055/` passes the blocklist check as "allowed."

At the OS level, however, connecting t…