CVE-2026-81033 in Automatisch
Summary
by MITRE • 08/26/2026
Automatisch reveals whether an address is registered through the response to its forgot-password request. The controller at packages/backend/src/controllers/internal/api/v1/users/forgot-password.js looks the address up and chains a not-found throw onto the query, so an address with no account raises an error that the global handler renders as a not-found status, while a registered address proceeds to send the reset message and returns no-content. The route is mounted without authentication. Submitting candidate addresses and comparing the two status codes therefore establishes which addresses hold accounts, with no credential and no rate limiting in the path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified involves an information disclosure flaw within the forgot-password functionality of the application backend, specifically located at packages/backend/src/controllers/internal/api/v1/users/forgot-password.js. This component is designed to handle password reset requests by verifying if a provided email address corresponds to an existing user account. The implementation logic relies on distinct HTTP response codes to signal the outcome of this verification process without explicitly stating whether the account exists or not, which constitutes a classic timing and status code-based enumeration vulnerability.
The technical flaw stems from how the controller handles database queries for non-existent versus existing email addresses. When an unregistered address is submitted, the query fails to find a match, triggering a not-found exception that is caught by a global error handler. This results in the server returning a 404 Not Found status code. Conversely, when a registered address is provided, the system proceeds with sending the password reset email and returns a 204 No Content status code indicating successful processing of the request without body content. Because this route is mounted without requiring any form of authentication or prior session validation, an unauthenticated attacker can interact directly with this endpoint to probe for valid user accounts.
This behavior allows attackers to perform user enumeration by submitting candidate email addresses and analyzing the HTTP response codes. By comparing a 404 status against a 204 status, an adversary can definitively determine whether a specific email address is associated with an active account on the platform. This capability effectively bypasses any intended privacy controls regarding user registration data. The absence of rate limiting in this path exacerbates the risk, enabling high-volume automated attacks where thousands of addresses can be tested rapidly to build a comprehensive list of valid users within the system.
The operational impact of this vulnerability is significant as it facilitates targeted phishing campaigns and credential stuffing attacks. With a verified list of active user accounts, attackers can craft more convincing spear-phishing messages or focus brute-force efforts on known usernames rather than guessing random ones. This reduces the noise in attack traffic and increases the success rate of subsequent compromise attempts. Furthermore, this enumeration capability may violate privacy regulations such as GDPR if personal data is exposed through indirect means, even without direct access to user credentials.
From a standards perspective, this vulnerability aligns with CWE-203: Observable Discrepancy, where different responses are given for similar actions based on internal state that should remain hidden. It also maps to ATT&CK technique T1589.001: Gather Victim Identity Information - Email Addresses, which describes the collection of email addresses as a reconnaissance step in cyber attacks. The lack of authentication and rate limiting further relates to CWE-307: Improper Restriction of Excessive Authentication Attempts, allowing for efficient automated enumeration.
Mitigation strategies should focus on standardizing responses regardless of whether an account exists or not. The most effective approach is to always return a 204 No Content status code when the forgot-password endpoint is accessed successfully, even if no email was sent because the address does not exist. This ensures that an attacker cannot distinguish between valid and invalid emails based on HTTP status codes alone. Additionally, implementing strict rate limiting per IP address or user identifier is critical to prevent high-speed enumeration attempts. Adding CAPTCHA challenges for repeated requests can further deter automated tools from exploiting this logic flaw effectively.