CVE-2026-84203: Memos Auth Bypass Vulnerability

CVE-2026-84203 Overview

CVE-2026-84203 affects Memos, an open-source note-taking application, in versions 0.26.0 through 0.30.0. The application fails to revoke refresh tokens when a user changes their password. Attackers who have obtained a valid refresh token retain persistent access to the account even after the legitimate user rotates credentials. The stolen refresh token can be used against the RefreshToken RPC endpoint to mint new access tokens and rotate refresh tokens indefinitely. This weakness maps to CWE-613: Insufficient Session Expiration.

Critical Impact
A password change does not terminate existing sessions, allowing attackers with a stolen refresh token to maintain indefinite account access and bypass the primary user remediation for credential compromise.

Affected Products

Memos version 0.26.0
Memos versions 0.27.x through 0.29.x
Memos version 0.30.0

Discovery Timeline

2026-09-01 - CVE-2026-84203 published to the National Vulnerability Database
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-84203

Vulnerability Analysis

Memos issues JSON Web Tokens (JWTs) for authentication, including short-lived access tokens and longer-lived refresh tokens. When a user changes their password, the application updates the stored credential but does not invalidate previously issued refresh tokens. The RefreshToken RPC continues to accept these tokens as valid session material.

An attacker holding a stolen refresh token can call RefreshToken at any interval to obtain fresh access tokens. Because the endpoint also returns a new refresh token, the attacker rotates the credential continuously and never triggers expiration. The legitimate user has no server-side control to sever these sessions short of a full account deletion or backend intervention.

The issue is a session lifecycle flaw rather than a cryptographic weakness. Token signatures remain valid, but the server does not maintain a revocation list or version counter tied to the user's password hash. Relevant logic resides in server/auth/authenticator.go and server/router/api/v1/user_service.go.

Root Cause

The password-change handler in user_service.go updates the user record without incrementing a token version, clearing a session store, or adding issued tokens to a denylist. The authenticator validates refresh tokens purely on signature and expiry.

Attack Vector

An attacker first obtains a refresh token through phishing, cross-site scripting, malware on the user's device, or a compromised backup. The attacker then repeatedly submits the refresh token to the Memos RefreshToken RPC over the network. Each call returns a fresh access token and a new refresh token, preserving access even after the victim changes their password and believes the account is secured.

See the VulnCheck advisory for Memos for additional technical context.

Detection Methods for CVE-2026-84203

Indicators of Compromise

Successful RefreshToken RPC calls from IP addresses or user agents that differ from the account owner's normal client fingerprint
Continued API activity on an account within minutes or hours after a password change event
Refresh token usage from geolocations that do not match recent interactive logins
Multiple concurrent active sessions for a single user after a credential rotation

Detection Strategies

Correlate password-change audit events with subsequent RefreshToken RPC calls and flag any refresh activity that continues after the change
Baseline each user's normal client and network fingerprint, then alert on refresh token use from new fingerprints
Inspect application logs for the same refresh token lineage being rotated repeatedly across long time windows

Monitoring Recommendations

Forward Memos authentication and RPC logs to a centralized logging or SIEM platform for retention and correlation
Alert on anomalous ratios of RefreshToken calls to interactive logins per account
Track token issuance and rotation counts per user to identify accounts with unusually persistent sessions

How to Mitigate CVE-2026-84203

Immediate Actions Required

Inventory all Memos deployments and identify instances running versions 0.26.0 through 0.30.0
Upgrade to a fixed release once published by the Memos maintainers; monitor the Memos GitHub repository for release notes
Force administrative invalidation of existing refresh tokens for any account suspected of credential compromise, including recent password changes
Review authentication logs for signs of refresh token abuse over the retention window

Patch Information

At the time of publication, the enriched CVE record does not list a fixed version. Administrators should track the Memos repository for a release that addresses CWE-613 by invalidating refresh tokens on password change. Refer to the VulnCheck advisory for updates.

Workarounds

Restrict network exposure of Memos instances to trusted networks or place them behind an authenticating reverse proxy that can enforce independent session revocation
Reduce refresh token lifetime through configuration or reverse-proxy enforcement to shorten the window of unauthorized access
Rebuild affected accounts (delete and recreate) when a credential compromise is confirmed, since password change alone does not revoke tokens
Require re-authentication at the proxy layer after any password change event

bash

# Example reverse-proxy control: block direct access to the RefreshToken RPC
# and require re-authentication after sensitive account changes.
# Consult your proxy documentation and adapt to your environment.
location /memos.api.v1.AuthService/RefreshToken {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://memos_backend;
}