Account privacy includes response timing

A password-reset endpoint is meant to reveal nothing about whether an address has an account. Directus equalized the visible response and added a fixed delay so that existing and non-existing accounts would take the same time. The security property is that every path through the handler takes that delay before it returns.

The upstream advisory records a timing-based user-enumeration issue. The delay was real, but it did not cover one branch, so response time—rather than response text—distinguished account states.

The handler defined a fixed stall measured from the start of the request. A non-existent account stalled before its error, and a valid account with an accepted reset URL stalled before returning. A third branch did not: a valid account combined with a disallowed reset URL threw a payload-validation error between the two stall calls, returning in tens of milliseconds.

That ordering turned the handler into an oracle. Sending a reset request with a deliberately disallowed URL, an attacker observed a fast rejection for an existing account and the full delay for a non-existent one. The difference was large enough to read remotely without precise instrumentation.

The upstream change validates the reset URL before the account is fetched. Because the disallowed-URL rejection now happens before any account-dependent work, it no longer distinguishes an existing account from a non-existing one; the account-dependent branches continue to the shared delay.

The fix is small in the source—the same check, relocated—but it changes which branches the delay governs. The invariant that mattered was not the presence of a stall but its coverage of every exit that depends on account state.

The advisory rates the issue Moderate. It identifies affected ranges for both the application and the API package and their patched versions. The disclosed capability is distinguishing whether an address has an account through response timing; it is not by itself account access. Version fields on the summary page follow the reviewed advisory database.

A regression review sends reset requests for a known-existing and a known-absent address, each with a disallowed URL, and compares response times. A patched build should show no meaningful difference. Trace each throw and early return in the handler and confirm the delay covers it. The scenarios below are suggested review checks, not reported TraceMint test results.

For reviewers, a timing defense is a claim about every path, so read each exit and ask whether it reaches the delay. A stall written at the end of a function does not protect a branch that leaves before it. Input validation ordered ahead of state-dependent work is often the simplest way to keep early rejections uniform.

The public advisory credits the TraceMint account as reporter, and the maintainers supplied the remediation. This study analyzes the public advisory and immutable source revisions; it does not establish a private discovery sequence or access to any deployment.