blueprintUE self-hosted edition EUVD-2026-116593

The attacker must possess a valid, previously-issued confirmation token for a specific account that is still unconfirmed (confirmed_at IS NULL), obtained out-of-band - a compromised mailbox, old email backup, forwarded mail, or server logs - since the attacker cannot generate tokens themselves. The vulnerable path is the unauthenticated /confirm-account/ endpoint in blueprintUE self-hosted edition <=4.3.3, where findUserIDWithConfirmedToken never evaluates confirmed_sent_at, so any age of token is accepted. Limiting factors: exploitation is entirely gated on leaking a stale token (no token = no attack), it yields only account activation and purge-evasion rather than password access or takeover, and the fix in 4.3.4 is the only complete remedy (tokens are given a 1-hour validity window and regenerated on resend).

The supplied CVSS 4.0 base score is 6.3 (medium) with vector AV:N/AC:L/AT:P/PR:N/UI:N and impact limited to VI:L (VC:N, VA:N) - i.e. a low integrity impact only, no confidentiality or availability effect. The AT:P (attack requirements present) metric reflects that exploitation depends on the attacker first obtaining a stale, previously-issued confirmation token, a precondition outside the attacker's control; they cannot mint tokens themselves. No CISA KEV listing is present and no EPSS score was provided, and there is no evidence of active exploitation, so exploitation status is: no public exploit identified as active, though a step-by-step PoC reference exists in the GHSA advisory (not verified as working exploit code). The vuln.today decision label is this_month, consistent with routine (not emergency) prioritization. Net real-world risk is modest and bounded: the flaw lets an attacker activate an account that was never confirmed and lets that account evade the optional 30-day cleanup cron, but per the vendor it does not disclose the password and is not account takeover by itself. This is a genuine-but-low-urgency issue rather than a high-impact priority; the main signal to weigh is that AV:N looks alarming but the AT:P prerequisite (leaked old email/token) substantially limits practical exploitability.

An attacker who recovers an old blueprintUE registration email from a compromised mailbox, email backup, forwarded message, or server logs extracts the never-expiring confirmed_token and requests /confirm-account/?confirmed_token=<token>. Because UserModel::findUserIDWithConfirmedToken only checks the token and that confirmed_at IS NULL - ignoring confirmed_sent_at - a months-old token still validates and activates the unconfirmed account, also keeping it from the unconfirmed-user purge job. A proof-of-concept with exact SQL and steps is published in the GHSA advisory, but it is a reference PoC, not verified as packaged working exploit code.