This CVE scores 9.8 because it enables complete account takeover, and that severity is warranted — but the underlying vulnerability isn't a novel zero-day, it's the same pattern that's appeared in dozens of OIDC implementations: matching identity on attacker-controllable claims instead of the IdP's stable sub identifier.
If you run usememos with SSO enabled, your immediate priority is verifying what claim your instance actually uses as the identity anchor. The vulnerable configuration binds authentication to something like email, displayName, or preferred_username — claims that an IdP administrator or, in some federation scenarios, the user themselves can influence. The secure configuration binds exclusively to the sub claim, which the IdP assigns and guarantees to be immutable for a given user within that identity namespace.
Audit your running instance now, not after patching. Query your user table or authentication logs to see what identifier usememos associates with SSO-bound accounts. If you see email addresses or human-readable names as the key rather than an opaque provider-assigned identifier, those accounts are vulnerable to takeover by anyone who can provision or influence claims in your IdP. The attack surface includes malicious IdP administrators, compromised IdP configurations, or federated identity scenarios where the claiming party isn't fully trusted.
The patch will switch to sub-based binding, but applying it creates a secondary problem: existing accounts won't automatically reconcile. You'll need a migration strategy that maps the old email-or-name-based accounts to their new sub-based identifiers, or accept that users will need to re-authenticate and may lose association with their historical data. This is the "identity mismatch penalty" — the security of binding to sub costs you human-readable usernames, easy account merging, and the ability to handle provider migrations without data disruption.
What makes this CVE dangerous beyond its CVSS score is the targeting profile. Users who deployed SSO for a self-hosted notes platform are precisely the users who thought they were raising their security posture — they're the ones with sensitive data worth protecting. The IdP becomes a single point of failure that the original deployment decision didn't account for. A compromise here doesn't just own an account; it owns a private thinking space.