Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-61835

CVE-2026-61835: Directus SSRF Vulnerability

CVE-2026-61835 is an SSRF vulnerability in Directus that allows authenticated users to bypass protection and access internal services via 0.0.0.0. This article covers technical details, affected versions, and mitigations.

Published:

CVE-2026-61835 Overview

CVE-2026-61835 is a Server-Side Request Forgery (SSRF) vulnerability in Directus, a real-time API and application dashboard for managing SQL database content. The flaw exists in the file-import-from-URL feature and allows authenticated users with file-upload permissions to bypass SSRF protections by supplying the address 0.0.0.0. The blocklist logic in api/src/request/is-denied-ip.ts treats 0.0.0.0 as a keyword for local interfaces but does not block the literal address. On Linux and macOS, connections to 0.0.0.0 reach localhost, letting attackers reach internal services through the /files/import endpoint. The issue is fixed in Directus 12.0.0.

Critical Impact

Authenticated attackers with file-upload rights can force the Directus server to fetch internal-only HTTP services and retrieve their responses as downloadable files, exposing internal metadata endpoints, admin interfaces, and cloud instance credentials.

Affected Products

  • Directus versions prior to 12.0.0
  • Directus deployments on Linux hosts (where 0.0.0.0 routes to loopback)
  • Directus deployments on macOS hosts (where 0.0.0.0 routes to loopback)

Discovery Timeline

  • 2026-07-15 - CVE-2026-61835 published to NVD
  • 2026-07-15 - Last updated in NVD database
  • Directus 12.0.0 - Patch released via GitHub Release v12.0.0

Technical Details for CVE-2026-61835

Vulnerability Analysis

The vulnerability is classified as Server-Side Request Forgery [CWE-918]. Directus exposes a /files/import endpoint that accepts a remote URL and downloads its contents into the storage backend. To prevent access to internal resources, the API applies an IP blocklist implemented in api/src/request/is-denied-ip.ts.

The blocklist recognizes the string 0.0.0.0 as an instruction to block all local network interfaces but never adds the literal 0.0.0.0 address or the 0.0.0.0/8 subnet to the deny list. On Linux and macOS, sending traffic to 0.0.0.0 is equivalent to targeting 127.0.0.1, so requests bypass the SSRF filter and reach loopback services.

An attacker holding a low-privilege account with file-upload rights can enumerate internal HTTP services, cloud instance metadata endpoints, and administrative dashboards bound to localhost. The response body is written into a Directus asset and can then be downloaded through the standard file API.

Root Cause

The root cause is incomplete blocklist parsing. The handler treats 0.0.0.0 as a symbolic keyword and enables blockNetworkInterfaces, but it fails to also register the literal address and the 0.0.0.0/8 range as denied. The unspecified IPv6 address :: was likewise absent from the blocklist.

Attack Vector

The attack requires network access to the Directus API and a valid authenticated session with permission to import files from a URL. The attacker submits a request to /files/import with a URL such as http://0.0.0.0:PORT/path, where PORT targets an internal service. The Directus server issues the outbound request, stores the response, and exposes it as a downloadable file. This enables reads against internal admin panels, metrics endpoints, and cloud metadata services (for example, AWS IMDS on 169.254.169.254 when combined with related bypasses).

typescript
// Security patch in api/src/request/is-denied-ip.ts
// Update ip blocklist (#27606)

if (blockNetwork === '0.0.0.0') {
    blockNetworkInterfaces = true;
    blockList.parseSubnet('0.0.0.0/8');
    blockList.parseAddress('::');
    continue;
}

Source: GitHub Commit f75b25f

The patch adds 0.0.0.0/8 as a denied subnet and blocks the IPv6 unspecified address ::, closing the bypass on both address families.

Detection Methods for CVE-2026-61835

Indicators of Compromise

  • Requests to /files/import containing 0.0.0.0, 0.0.0.0/8 ranges, or the IPv6 :: address in the URL parameter
  • Newly created Directus file assets whose original source URL points to loopback or link-local ranges
  • Outbound HTTP requests from the Directus process directed at 127.0.0.0/8, 169.254.169.254, or internal RFC1918 hosts shortly after an import call

Detection Strategies

  • Inspect Directus application logs and reverse-proxy access logs for POST or GET requests to /files/import with URL parameters referencing 0.0.0.0, 0, or hexadecimal or octal encodings of loopback addresses
  • Correlate authenticated user sessions using the file-upload permission with anomalous outbound egress from the Directus host to internal-only endpoints
  • Alert on file assets that were imported from non-public URL schemes or non-routable addresses

Monitoring Recommendations

  • Enable audit logging on the Directus files collection to capture the storage, filename_download, and originating user for each import event
  • Monitor egress traffic from the Directus service account and flag connections to loopback, link-local, or metadata service IP ranges
  • Track HTTP responses returned to /files/import that contain content-types associated with internal admin UIs or cloud metadata JSON

How to Mitigate CVE-2026-61835

Immediate Actions Required

  • Upgrade Directus to version 12.0.0 or later, which registers 0.0.0.0/8 and :: in the SSRF blocklist
  • Audit user roles and remove file-upload or file-import permissions from accounts that do not require them
  • Review recent /files/import activity for URLs targeting loopback, link-local, or private address ranges

Patch Information

The fix is shipped in Directus 12.0.0. The relevant change in api/src/request/is-denied-ip.ts adds blockList.parseSubnet('0.0.0.0/8') and blockList.parseAddress('::') when 0.0.0.0 is present in the block configuration. Full details are available in the GitHub Security Advisory GHSA-j5h6-vqc3-phqh and Pull Request #27606.

Workarounds

  • Place Directus behind an egress firewall that denies outbound traffic from the application to loopback, link-local (169.254.0.0/16), and internal management subnets
  • Restrict the Directus role permissions so that only trusted administrators can invoke the /files/import endpoint
  • Terminate the Directus API behind a proxy that rejects import requests containing 0.0.0.0, ::, or numeric address encodings until the upgrade is applied
bash
# Example egress restriction using iptables to block loopback and metadata targets
# from the Directus service user (uid 1500)
iptables -A OUTPUT -m owner --uid-owner 1500 -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 0.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 10.0.0.0/8 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.