Two independent bypasses in the same release reveal a single architectural flaw: security policy was implemented as frontend presentation logic rather than enforced at the data layer. The first bypass is straightforward—ALLOW_REGISTER controls whether the registration form renders, but the signup endpoint processes any valid request regardless. A user with direct API access can register even when the UI hides the option. The second bypass is subtler: process_auth_header treats account activation status as optional, allowing authenticated sessions from unactivated accounts. Both stem from the same root cause—the backend handlers predate the security constraints and were never audited when those constraints were introduced.
The CVSS of 6.9 is misleading. This bypass explicitly supplies the low-privilege account required by related authorization vulnerabilities—it functions as infrastructure for an attack chain, not a standalone flaw. A trivial bypass with high downstream reach is more dangerous than a complex one with narrow access.
Audit your codebase for this pattern: any security flag, feature flag, or state constraint introduced after an endpoint was written creates invisible debt if no backward trace through existing handlers occurred. Check whether account state (activation, suspension, approval status) is treated as a UX concern anywhere in authentication-adjacent code—the same implicit assumption that produced the process_auth_header gap likely exists elsewhere. The fix in 3.42.0 closes the documented path, but the architectural gap that allowed the bypass persists wherever security semantics aren't explicitly documented in acceptance criteria.