Clockwatching: Enumerating Directus Users via Timing Side-Channels

There is a special place in hell reserved for timing attacks. They are subtle, statistical, and often born from the very code intended to prevent them. CVE-2026-26185 is a classic example of this irony, affecting Directus, the popular headless CMS.

Directus developers, being security-conscious folks, knew that password reset forms are a goldmine for attackers. If you type in an email and the server says "Email sent!" versus "User not found," you've just handed the attacker a valid username. To combat this, they implemented a stall() function—a utility designed to force all requests to take a standardized amount of time (500ms), masking the database lookup speed.

But here's the catch: implementing a constant-time response is like trying to carry water in a sieve. You have to plug every hole. In this case, they missed one logic branch, turning their shield into a magnifying glass for attackers.

The vulnerability lies in the UsersService within the @directus/api package. Specifically, the requestPasswordReset method. The goal of this function is simple: look up a user by email and send them a reset link. If the user doesn't exist, the system waits out the stall timer and throws a generic error. If the user does exist, it proceeds to validate parameters.

The flaw was purely chronological. The code performed the expensive operation (database lookup) before validating the input reset_url.

Here is the logic flow in the vulnerable version:

1. Start Timer.
2. Database Lookup: Check if email exists.
3. If User Missing: Wait 500ms (Stall), then throw Forbidden.
4. If User Exists: Check if reset_url is in the allow-list. If not, throw InvalidPayload immediately.

Do you see the problem? If I provide a valid email but a garbage URL, the code skips the stall and errors out instantly. If I provide an invalid email and a garbage URL, the code enters the If User Missing block and sleeps for half a second. That 500ms delta is the sound of the server leaking data.

Let's look at the TypeScript source. This is the diff from commit e69aa7a5248c6e3e822cb1ac354dee295df90b2a. It perfectly illustrates how a simple swap of lines closes the side channel.

Vulnerable Code (Before):

// 1. Start the clock
const timeStart = performance.now();
 
// 2. Look for the user (The leakage source)
const user = await this.getUserByEmail(email);
 
// 3. If no user, STALL then throw
if (user?.status !== 'active') {
    await stall(STALL_TIME, timeStart);
    throw new ForbiddenError();
}
 
// 4. If user exists, check URL. 
// OOPS: This throws immediately, bypassing the stall logic above.
if (url && isUrlAllowed(url, ...) === false) {
    throw new InvalidPayloadError(...);
}

Fixed Code (After):

const timeStart = performance.now();
 
// 1. Check the URL FIRST. 
// If it's bad, fail fast for EVERYONE. 
if (url && isUrlAllowed(url, ...) === false) {
    throw new InvalidPayloadError(...);
}
 
// 2. Now look for the user
const user = await this.getUserByEmail(email);
 
// 3. Standardize timing
if (user?.status !== 'active') {
    await stall(STALL_TIME, timeStart);
    throw new ForbiddenError();
}

By moving the URL validation to the top, the application ensures that a bad reset_url results in a fast rejection regardless of whether the email is in the database. The side channel is closed because the response path is now identical for both valid and invalid users when the URL is malicious.

Exploiting this does not require complex memory corruption or packet injection. It requires a stopwatch. An attacker can write a simple Python script to enumerate users.

The Attack Chain:

1. Setup: Identify a Directus instance (e.g., via the Wappalyzer browser extension or looking for /admin endpoints).
2. Payload Construction: Create a POST request to /auth/password/request.
   • email: The target email you want to verify (e.g., admin@target.com).
   • reset_url: A known blocked URL or just http://evil.com (assuming the server enforces an allow-list).
3. Execution: Send the request and measure the time to first byte (TTFB).

The Heuristic:

• ~50ms Response (400 Bad Request): "Jackpot." The user exists. The code hit the database, found the user, hit the URL check, and bailed out early.
• ~500ms Response (403 Forbidden): "Miss." The user does not exist. The code hit the database, found nothing, and sat in the stall() penalty box for half a second.

This isn't theoretical. With a 500ms difference, you don't even need statistical averaging. A single request is often enough to confirm existence.

Is this going to bring down the banking system? No. But in the reconnaissance phase of an attack, user enumeration is incredibly valuable.

Knowing valid usernames allows an attacker to:

1. Launch Targeted Phishing: If I know j.doe@company.com is a valid admin, I can craft a specific spear-phishing email targeting them.
2. Credential Stuffing: Instead of spraying a million passwords at a million potential emails, I can spray 100 common passwords at the 50 emails I know exist. This drastically reduces the noise generated in logs and increases the success rate.
3. Bypass Lockouts: Attackers can specifically target valid accounts to trigger account lockouts (Denial of Service) without wasting requests on dead accounts.

For a platform like Directus, which often manages critical data for apps and websites, exposing the list of administrators is a significant breach of privacy.

The fix is straightforward: Update to Directus v11.14.1 or @directus/api v32.2.0.

If you cannot update immediately, you are in a tight spot. You could technically try to ensure your PASSWORD_RESET_URL_ALLOW_LIST is empty or extremely permissive to prevent the validation error from triggering, but that introduces other security risks (like Host Header injection or open redirects).

The only real cure is the patch. This vulnerability serves as a reminder for developers: Input validation should always happen before resource-intensive or sensitive operations. Validate your inputs at the door, not after you've already invited them into the living room.