This CVE exposes an authorization bypass in Server-Sent Events (SSE) endpoints where the token_required decorator validates identity but never checks account confirmation state. The vulnerability exists because the SSE authentication path was implemented with a simpler mental model than the REST API—someone added a key check and considered the job done, while the REST API accumulated is_confirmed and is_active enforcement as policy requirements evolved. These two interface types serve the same protected resource class but enforce different authorization boundaries, and the SSE decorator was never revisited.
The exploit window is specific: during registration, an API key is provisioned before the account is confirmed. For REST endpoints, is_confirmed blocks access from unconfirmed accounts. For SSE, the decorator never reads that field, so the key grants immediate access. The attacker doesn't get one unauthorized data retrieval—they hold open a pipe to the entire future of the data stream from connection time until disconnect. SSE's persistent, real-time nature transforms what would be a discrete authorization failure in REST into continuous, compounding exposure.
The fix is trivial: add is_confirmed and is_active checks to the SSE decorator. But the deeper problem is architectural. Authentication was treated as a single binary gate ('is this a real user?') while authorization requires domain logic ('is this user in a state that permits this operation?'). This conflation—authorizers treated as authenticators—has a documented lineage across interface types: GraphQL resolvers bypassing REST authorization, WebSocket endpoints with weaker CSRF enforcement, mobile APIs exposing data that web UIs hide. Each gets a different CVE, but they're the same root failure.
For your own codebase: audit any SSE, WebSocket, GraphQL, or streaming endpoints for whether their authentication decorators include the same state checks your REST API enforces. Specifically check whether account confirmation or activation status is validated. If you have persistent connections, ask whether they would terminate if an account is deactivated mid-stream—most don't, because authorization is modeled as a one-time event rather than an ongoing condition. Document the requirement explicitly: any decorator authenticating against the same resource class must enforce identical state checks regardless of interface type.