BlueprintUE's password reset leaks which email addresses have accounts
BlueprintUE's password reset leaks which email addresses have accounts BlueprintUE Self-Hosted Edition 4.3.2 has an account-enumeration flaw in its password-reset flow. GHSA-fwgq-c3c6-p67j describes the issue and gives
BlueprintUE's password reset leaks which email addresses have accounts
BlueprintUE Self-Hosted Edition 4.3.2 has an account-enumeration flaw in its password-reset flow. GHSA-fwgq-c3c6-p67j describes the issue and gives it a CVSS 3.1 score of 5.3. A request for a registered address redirects to /reset-password/. A request for an unregistered address redirects to /#popin-forgot_password.
The difference is visible to an unauthenticated caller. An attacker can submit a list of email addresses and inspect the Location header. The response does not prove that the account is active or that the address belongs to the person making the request, but it identifies accounts that are eligible for the reset process.
The advisory also describes an incomplete rate limit. The IP-level and global counters were saved only after a reset email was delivered. Failed account lookups therefore did not consume the configured allowance. An attacker could repeat enumeration without reaching the intended threshold. Version 4.3.3 makes the response identical for existing and nonexistent accounts, applies the rate limit when the form is submitted, and rolls back the transaction when the address is missing or delivery fails.
Treat the reset endpoint as an authentication boundary
A password-reset form performs a user lookup before the caller is authenticated. That makes it an attractive place to ask questions about account existence. The response should avoid revealing whether the address is registered, disabled, externally managed, or temporarily locked.
Rate limits should count attempts before the lookup and before any email delivery. A system that consumes quota only after a successful send gives an attacker a free test channel. The counter also needs an owner, a monitoring signal, and a retention period. A limit that exists in configuration but does not trigger requires periodic testing.
Email delivery can introduce side channels beyond the HTTP response. Response time, duplicate-send behavior, bounce handling, and support workflows may still differ. The safest design makes the public response uniform and moves account-state details into an authenticated channel.
Patch and review the surrounding flow
Upgrade self-hosted instances to 4.3.3 or later. Then test with registered, unregistered, disabled, and rate-limited addresses. Compare status codes, headers, body text, and observed timing. Use a controlled test account and avoid sending messages to real users.
Review reverse-proxy and application logs for repeated reset attempts that vary the email address but keep the session, client fingerprint, or source address stable. Correlate the attempts with subsequent login failures or successful authentication from a new location. The reset flow may be the reconnaissance stage rather than the compromise itself.
Rate limiting should be layered with alerting. A single address can hide behind multiple clients, and a single client can rotate addresses. Use account, client, and network signals according to the privacy and abuse policies of the service.
The completion check should show the fixed version, identical public responses, counters that increment on unsuccessful lookups, an alert path for concentrated attempts, and a tested rollback path when mail delivery fails. BlueprintUE is a small self-hosted collaboration service, but its reset form controls access to blueprints and user accounts. The same rules apply.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.