CVE-2026-35412: Directus Auth Bypass Vulnerability

CVE-2026-35412 Overview

CVE-2026-35412 is a high-severity authorization bypass vulnerability affecting Directus, a real-time API and App dashboard for managing SQL database content. Prior to version 11.16.1, the TUS resumable upload endpoint (/files/tus) allows any authenticated user with basic file upload permissions to overwrite arbitrary existing files by UUID. This occurs because the TUS controller performs only collection-level authorization checks, verifying the user has some permission on directus_files, but never validates item-level access to the specific file being replaced.

Critical Impact

Authenticated users can bypass row-level permission rules to overwrite any file in the system, potentially leading to data integrity compromise, unauthorized content replacement, and disruption of application functionality.

Affected Products

• Directus versions prior to 11.16.1

Discovery Timeline

• 2026-04-06 - CVE CVE-2026-35412 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-35412

Vulnerability Analysis

This vulnerability is classified under CWE-863 (Incorrect Authorization). The core issue stems from an inconsistency in how authorization is enforced across different file upload paths within Directus. While the standard REST upload path correctly enforces row-level permission rules such as "users can only update their own files," the TUS resumable upload endpoint at /files/tus bypasses these granular controls entirely.

The TUS protocol implementation in Directus only performs collection-level authorization, checking whether a user has generic permissions on the directus_files collection. This means any authenticated user with basic file upload capabilities can exploit this endpoint to overwrite files belonging to other users or system files by simply knowing or guessing the target file's UUID.

Root Cause

The root cause is an incomplete authorization implementation in the TUS controller. The controller verifies that the requesting user has some level of access to the directus_files collection but fails to perform item-level permission validation. This architectural oversight allows the TUS endpoint to operate outside the standard access control framework that protects individual file resources.

Attack Vector

An attacker with valid credentials and basic file upload permissions can exploit this vulnerability by sending a TUS upload request targeting an arbitrary file UUID. The attack is network-accessible with low complexity and requires no user interaction. The attacker crafts a TUS PATCH request to /files/tus/{target-file-uuid} with replacement file content. Since the TUS controller does not verify ownership or item-level permissions, the target file is overwritten regardless of the original owner or configured access restrictions.

The exploitation flow involves:

1. Obtaining valid authentication credentials with basic file upload permissions
2. Identifying or enumerating target file UUIDs (potentially through other API endpoints or information disclosure)
3. Sending a TUS upload request to replace the target file with attacker-controlled content
4. The malicious content overwrites the original file, bypassing all row-level permission rules

For technical details and proof-of-concept information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-35412

Indicators of Compromise

• Unusual TUS upload activity targeting file UUIDs not owned by the requesting user
• Unexpected modifications to files in the directus_files collection
• Audit log entries showing file overwrites via /files/tus endpoint by users who should not have access to those files
• Multiple TUS PATCH requests targeting different file UUIDs from a single authenticated session

Detection Strategies

• Monitor API access logs for abnormal patterns of TUS endpoint usage, particularly requests targeting files owned by different users
• Implement file integrity monitoring on critical Directus-managed files to detect unauthorized modifications
• Audit user permissions and compare against actual file modification activity to identify authorization bypass attempts
• Enable verbose logging on the /files/tus endpoint to capture detailed request information for forensic analysis

Monitoring Recommendations

• Configure alerting for TUS upload requests where the requesting user does not match the file owner
• Implement anomaly detection for sudden increases in file modification activity through the TUS endpoint
• Review Directus audit logs regularly for signs of unauthorized file access patterns
• Deploy network-level monitoring to track traffic patterns to the /files/tus endpoint

How to Mitigate CVE-2026-35412

Immediate Actions Required

• Upgrade Directus to version 11.16.1 or later immediately
• Review recent file modifications to identify any unauthorized changes that may have occurred prior to patching
• Audit user permissions and remove unnecessary file upload capabilities from accounts that do not require them
• Consider temporarily disabling the TUS endpoint if immediate patching is not possible

Patch Information

This vulnerability is fixed in Directus version 11.16.1. The patch implements proper item-level authorization checks in the TUS controller, ensuring that row-level permission rules are enforced consistently across all upload paths. Organizations should upgrade to 11.16.1 or later to remediate this vulnerability. For detailed information, see the GitHub Security Advisory.

Workarounds

• Restrict access to the /files/tus endpoint at the reverse proxy or web application firewall level until patching is complete
• Implement additional network segmentation to limit which users can reach the TUS endpoint
• Review and tighten user permissions to minimize the number of accounts with file upload capabilities
• Consider implementing additional application-level logging to track all TUS endpoint activity for post-incident analysis

# Example: Block TUS endpoint at nginx reverse proxy level (temporary workaround)
location /files/tus {
    deny all;
    return 403;
}