CVE-2026-122139 in Self-Hosted Edition
Summary
by MITRE • 11/04/2026
blueprintUE Self-Hosted Edition before 4.3.3 contains an account enumeration vulnerability in ForgotPasswordMiddleware.php that allows unauthenticated attackers to identify registered email addresses. Attackers can compare password reset redirect targets for submitted emails, and failed lookups are never rate-limited, enabling unlimited enumeration attempts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/04/2026
The blueprintUE Self-Hosted Edition prior to version 4.3.3 suffers from a critical account enumeration vulnerability located within the ForgotPasswordMiddleware.php component of its web application architecture. This flaw stems from an implementation error in how the system handles password reset requests for non-existent or unregistered email addresses. In secure authentication systems, responses to such requests should be uniform and indistinguishable whether the provided email corresponds to a valid user account or not, thereby preventing attackers from determining which accounts exist within the database. However, in this specific version of blueprintUE, the middleware fails to implement consistent response behavior across all input scenarios.
The technical mechanism exploited by an attacker involves submitting various email addresses through the password reset interface and analyzing the HTTP redirect targets returned by the server. When a valid registered email is submitted, the application likely initiates a standard password reset flow that results in a specific redirection or success message. Conversely, when an unregistered email is provided, the system behaves differently, potentially returning a distinct error page, a different redirect URL, or varying HTTP status codes due to improper handling of null user lookups. This discrepancy creates a side-channel through which an attacker can definitively determine whether a given email address is associated with an active account on the platform.
A significant aggravating factor in this vulnerability is the complete absence of rate limiting mechanisms for failed password reset attempts or general lookup operations. Without constraints on the frequency of requests, an unauthenticated actor can automate the enumeration process using scripts to iterate through large lists of potential email addresses at high speed. This lack of throttling transforms a theoretically slow manual attack into a highly efficient automated data harvesting operation, allowing adversaries to map out valid user accounts with minimal effort and negligible risk of detection or account lockout.
The operational impact of this vulnerability is substantial, as it facilitates the initial phase of many advanced cyber attacks. By successfully enumerating registered email addresses, attackers can build accurate target lists for subsequent phishing campaigns, such as spear-phishing or credential stuffing attempts tailored to specific individuals. Furthermore, knowing which accounts exist allows adversaries to prioritize their efforts on high-value targets and reduces the noise associated with guessing invalid usernames, thereby increasing the success rate of brute-force attacks against known valid credentials. This vulnerability aligns closely with CWE-204, which describes observable response discrepancy for an input that causes a different internal state change than expected, and is also categorized under ATT&CK technique T1589.001, specifically Gather Victim Email Addresses through Enumeration.
To mitigate this risk, the development team must ensure that all password reset endpoints return identical responses regardless of whether the email address exists in the database. This can be achieved by implementing a consistent success message for both valid and invalid emails, such as "If an account with that email exists, you will receive a password reset link," without revealing any additional information about the existence of the account. Additionally, robust rate limiting must be applied to all authentication-related endpoints to prevent automated enumeration attacks. This includes restricting the number of requests per IP address or user identity over a defined time window and implementing CAPTCHA challenges after a small threshold of failed attempts. Regular security audits and penetration testing should also be conducted to verify that such discrepancies do not exist in other parts of the application logic.