CVE-2026-84203

Executive Summary

CVE-2026-84203 is a session management flaw in Memos versions 0.26.0 through 0.30.0, a self-hosted open-source note-taking and memo application. The vulnerability stems from the application's failure to revoke refresh tokens when a user changes their password, meaning that any previously issued refresh token remains valid even after a credential rotation event.

This flaw enables an attacker who has obtained a stolen refresh token to maintain persistent account access indefinitely. By calling the RefreshToken RPC (Remote Procedure Call), the attacker can continuously obtain new access tokens and rotate the refresh token itself, effectively bypassing the security measure that password changes are intended to provide. With a CVSS score of 8.1 (High), the vulnerability exposes affected instances to confidentiality and integrity compromise, though no availability impact is scored. As of the time of this report, no patch is available from any tracked source, leaving all affected versions actively exposed.

Technical Analysis

Memos is a self-hosted memo hub application that employs a token-based authentication system consisting of access tokens (short-lived) and refresh tokens (long-lived). Refresh tokens are designed to allow clients to obtain new access tokens without requiring re-authentication, a common pattern in OAuth 2.0 and JWT-based authentication architectures.

The vulnerability class is CWE-613 — Insufficient Session Expiration. The security flaw exists because Memos versions 0.26.0 through 0.30.0 fail to invalidate issued refresh tokens when a user changes their password. In a properly implemented session management system, any credential change should immediately invalidate all outstanding refresh tokens associated with that user account, since the password change may indicate a compromise or a security-conscious user action. The application should treat password changes as a high-priority session invalidation event.

The specific technical mechanism described in the NVD data names the RefreshToken RPC as the endpoint used by the attacker. When invoked, this RPC accepts a valid refresh token and issues a new access token plus a rotated refresh token. The flaw is that the server does not check whether the refresh token's issuance predates the password change, nor does it maintain an invalidation list (denylist) of tokens that should no longer be accepted after credential rotation.

Attack surface considerations:

• Network exposure: Memos is commonly deployed as a self-hosted web service, often exposed to the internet for personal or small-team use. This makes the RefreshToken RPC reachable from the network.
• Authentication state: The attacker requires a valid refresh token (or must have previously acquired one). The vulnerability therefore requires a prior token theft event (e.g., via a compromised device, an API log leak, a man-in-the-middle attack on a non-TLS connection, or a separate application vulnerability).
• Privilege level: The CVSS vector indicates PR:L (Low Privilege Required), meaning the attacker must already possess some level of access, consistent with having a valid refresh token rather than no authentication material at all.

No code-level details of the application's token handling are available beyond the NVD description. Insufficient technical detail is available regarding the internal session storage mechanism, token expiry parameters, or the implementation of the RefreshToken RPC itself. The report's analysis is therefore constrained to the vulnerability class and the described behavior. It is highly likely, however, that the server-side session store does not perform a token-issuance timestamp comparison against the password change timestamp, or maintains no per-user token generation counter that is incremented upon password changes.

Exploitation Scenarios

No public PoC exists for CVE-2026-84203; the attack chain below is inferred from the vulnerability class and the NVD description. Specific endpoint names, payload structures, and function names beyond RefreshToken are not available and are not fabricated here.

Reconnaissance / Target Identification: An attacker first identifies Memos instances exposed on the internet. Memos has a distinctive web interface and is commonly deployed via Docker on ports 5230 (default). Shodan searches for http.title:"Memos" or http.html:"memos" will return public instances. Once a target is identified, the attacker assesses whether the instance runs a version within 0.26.0–0.30.0 (e.g., via version disclosure in page source, API responses, or changelog artifacts).

Acquisition of a Refresh Token (Precondition): The attacker must obtain a valid refresh token. This could be achieved through:

• A separate vulnerability in the same application (e.g., an XSS, SSRF, or insecure direct object reference) revealing token material.
• Physical or digital access to a victim's browser storage where tokens are persisted.
• An insecure network path (HTTP rather than HTTPS) allowing token interception via man-in-the-middle.
• A compromised client device with an active session.

This step is outside the scope of CVE-2026-84203 itself, but it is the prerequisite that makes the vulnerability exploitable.

Triggering the Flaw: The attack proceeds as follows:

1. The victim user changes their password, believing this invalidates any prior session material. Under the flawed implementation, the server does not revoke refresh tokens issued before the password change.
2. The attacker, holding the previously stolen refresh token, invokes the RefreshToken RPC against the Memos instance (e.g., via the application's HTTP API endpoint, the specifics of which are not disclosed in available data).
3. The server validates the token, determines it is still valid (incorrectly), and returns a new access token along with a new refresh token. This new refresh token supersedes the old one (rotation), but the attacker now possesses it.
4. The attacker can repeat step 3 indefinitely, obtaining fresh access tokens each time the current token approaches expiry. Each call returns a new refresh token, allowing the cycle to continue.

Post-Exploitation Impact: With continuous valid access tokens, the attacker retains the victim's privilege level (e.g., standard user or workspace admin if the victim is an administrator). The attacker can:

• Read, create, modify, or delete all memos and notes in the victim's workspace.
• Access any shared resources, tags, or attachments associated with the account.
• If the compromised account has administrative privileges, the attacker could manage users, change workspace settings, or extract data from other users' memos.
• Maintain persistence even if the victim changes their password again, since the token was obtained after the first change and the victim has no practical way to invalidate it (except possibly via a full account deletion or server-side token store reset — both outside the described fix scope).

The severity of this exploitation is reflected in the CVSS vector's High confidentiality and High integrity impacts (C:H/I:H). The attacker's access is network-based (AV:N) and requires no user interaction (UI:N), only the possession of a refresh token, which aligns with the Low privilege requirement.

Impact Assessment

Business Impact: Memos is used by individuals, security researchers, and small-to-medium teams as a self-hosted knowledge base and note-taking platform. The impact of CVE-2026-84203 is twofold:

1. Credential rotation is rendered ineffective. Users who change their passwords following a suspected compromise receive a false sense of security. An attacker holding a refresh token can continue operating under the account indefinitely, bypassing the very measure designed to revoke their access.
2. Persistent unauthorized access. The ability to rotate refresh tokens indefinitely means the compromise is permanent until a server-side intervention (e.g., invalidating all sessions via application configuration changes, database manipulation, or full application restart with token-store reset) is performed. This creates a significant forensic challenge and data exposure risk.

Affected Systems: All Memos deployments running versions 0.26.0 through 0.30.0 are affected. The issue applies to any deployment where a user account has had its refresh tokens compromised and whose password is subsequently changed. Both online (cloud-hosted) and on-premises Docker deployments are in scope.

Blast Radius: The CVSS subscores are:

• Attack Vector: Network (AV:N) — exploitable remotely.
• Attack Complexity: Low (AC:L) — no special conditions beyond possession of a valid token.
• Privileges Required: Low (PR:L) — token possession implies low-level account access.
• User Interaction: None (UI:N).
• Confidentiality Impact: High (C:H) — full read access to the victim's memos and associated data.
• Integrity Impact: High (I:H) — full write/modify/delete capability on the victim's data.
• Availability Impact: None (A:N) — the attack does not cause denial of service.

The blast radius across a multi-user Memos instance scales with the privilege of the compromised account. An admin account compromise — if the admin's refresh token is stolen — could expose all users' data, alter system settings, and potentially be leveraged to pivot to the underlying host server (e.g., via stored XSS, SSRF, or file write capabilities within the memo import/export feature, which are not further specified here and therefore not detailed).

The lack of patch availability (patch confidence 0/4) means all affected instances remain exposed as of this writing. Any incident response team detecting a compromised Memos account must treat password changes as insufficient — full session revocation and possibly token-store resets are required.

Detection Guidance

Detection of this vulnerability is challenging because the attack leverages a legitimate application feature (refresh token rotation). The exploitation does not produce malformed requests or unusual payloads — it simply calls a valid API endpoint with a valid token. Detection therefore depends on behavioral signals, such as refresh-token usage patterns, token rotations following password changes, or excessive token refresh activity.

The following detection artifacts are provided as baseline guidance and must be tuned to the specific Memos deployment's logging and network configuration.

Sigma Rule

title: Suspicious Refresh Token Activity Following Password Change in Memos
id: 5f4b8c7e-3a2b-4c9d-8e1f-6a0b2c3d4e5f
status: experimental
description: Detects refresh token usage after a password change in Memos, which may indicate CVE-2026-84203 exploitation where tokens are not revoked on credential change.
author: Valtersit Threat Intelligence
date: 2026/04/01
logsource:
  category: application
  product: memos
  service: auth
detection:
  selection_password_change:
    EventName: "UserPasswordChanged"
  selection_refresh_token:
    EventName: "RefreshTokenIssued"
  selection_rotation_window:
    # Timeframe: refresh token activity within 24 hours after password change
    timeframe: 24h
  condition: selection_password_change followed by selection_refresh_token within selection_rotation_window
falsepositives:
  - Legitimate token refresh after a user changes password and is re-authenticating on a new device
level: high
tags:
  - attack.t1190
  - cve.2026.84203
  - cwe.613

YARA Rule

rule CVE_2026_84203_Memos_RefreshToken_Abuse {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects log patterns or artifacts associated with refresh token abuse in Memos after password change"
        date = "2026-04-01"
        reference = "CVE-2026-84203"
        score = 70
    strings:
        $token_rpc = "RefreshToken" ascii nocase
        $pass_change = "password" ascii nocase
        $token_rotate = "refresh_token" ascii nocase
        $session_event = "session" ascii nocase
        $auth_fail = "authentication" ascii nocase
    condition:
        uint16(0) == 0x0A0D  // CRLF line ending (log file)
        and any of ($token_rpc, $token_rotate)
        and any of ($pass_change, $session_event)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-84203 - Memos Refresh Token Abuse Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"RefreshToken"; nocase; http.request_body; content:"refresh_token"; nocase; threshold: type both, track by_dst, count 5, seconds 300; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-84203; reference:cve,2026-84203; classtype:attempted-user; sid:202684203; rev:1;)

Note: The HTTP URI pattern RefreshToken is a placeholder — the actual API endpoint used by Memos for this RPC is not disclosed in the available NVD data. Analysts must confirm the real endpoint (typically an RPC-style path such as /api/auth/token/refresh or a gRPC endpoint) and adjust the content match accordingly.

Elastic Detection

// Detect repeated refresh token issuance events that may indicate abuse of CVE-2026-84203
sequence by user.name with maxspan=1h
  [ authentication where event.action == "password_change" ]
  [ audit where host.name == "*memos*" and process.name == "memos" and event.action matches "*refresh*"
      and event.outcome == "success" ]
  [ authentication where host.name == "*memos*" and event.action == "token_refresh"
      and event.outcome == "success" ]
  // Alerts when 3+ successful token refreshes occur within 1h of a password change
  | where timeseries >= 3

Splunk SPL Query

index=* sourcetype=memos* 
| rex field=_raw "(?<event_type>RefreshToken|password_change|token_rotation)"
| where event_type IN ("RefreshToken", "password_change", "token_rotation")
| transaction user maxspan=1h
  | stats count(eval(event_type=="RefreshToken")) as refresh_count
          count(eval(event_type=="password_change")) as pass_change_count
          values(_raw) as details by user
| where refresh_count > 3 AND pass_change_count >= 1
| eval severity = "high"
| table _time, user, refresh_count, pass_change_count, details

Wazuh OSSEC Rule

<group name="memos,">
  <rule id="100842" level="12">
    <decoded_as>json</decoded_as>
    <field name="app">^memos$</field>
    <field name="event">^RefreshTokenIssued$</field>
    <description>CVE-2026-84203: Refresh token issued after password change in Memos - possible token abuse</description>
    <group>authentication_failures,cve_2026_84203,</group>
    <options>no_full_log</options>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <rule id="100843" level="15">
    <if_sid>100842</if_sid>
    <field name="user">.+</field>
    <description>Multiple refresh tokens issued for same user - potential persistent access via CVE-2026-84203</description>
    <group>cve_2026_84203,</group>
    <frequency>5</frequency>
    <timeframe>300</timeframe>
    <same_field>user</same_field>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source. The vendor has not released a fixed version as of the publication of this report. Affected versions: 0.26.0 through 0.30.0.

Immediate Mitigations (until a patch is released):

1. Manual token invalidation after every password change. If a user's password is changed, an administrator should manually invalidate all active sessions. This may require restarting the Memos service (which may clear in-memory session stores) or explicitly clearing the token/session table in the underlying database. Verify whether the Memos deployment persists tokens in an external database; if so, delete all rows associated with the affected user.
2. Multi-factor authentication (MFA) enablement. While MFA does not fix the token revocation flaw, it adds an additional verification layer that a token-only attacker cannot pass at the access-token validation stage, depending on the application's enforcement policies.
3. Network segmentation and access control. Restrict access to Memos instances — place them behind a VPN, reverse proxy with IP allowlists, or require SSO (if supported) rather than exposing the service directly to the internet. This reduces the attack surface for initial token theft.
4. Session duration limitation. If configurable, reduce the refresh token lifetime to the minimum acceptable value. This limits the window in which a stolen token is usable before the user changes their password again.
5. Post-change credential verification. Immediately after a password change, verify the user's sessions via the application's user-management interface. If the application shows no way to revoke specific sessions, assume outstanding tokens remain valid and restart the service.

Patch / Upgrade Steps: As of publication, there is no patched version. Monitor the Memos official GitHub repository and release notes for a version that addresses CVE-2026-84203 (likely 0.31.0 or later). When a fix is available:

1. Back up the entire Memos data directory (including the SQLite database or external database, and any uploaded attachment files).
2. Test the upgrade in a staging environment.
3. Upgrade the Docker container or binary to the patched version.
4. After upgrade, force a full user re-authentication by clearing all tokens to ensure no stale refresh tokens persist — the patched version should handle this automatically, but a manual token sweep is prudent.

Long-Term Hardening:

1. Regular token hygiene audits. Schedule periodic reviews of active sessions and tokens. Revoke any sessions that appear stale or suspicious.
2. Adopt a centralized identity provider (IdP). If Memos supports OIDC/SAML integration, use an external IdP (e.g., Keycloak, Authentik, Okta) that enforces proper session revocation on credential changes. This shifts session management to a more rigorously hardened system.
3. Implement anomaly detection on authentication events. Deploy the detection rules above to monitor for unusual token refresh patterns, especially after password changes.
4. Vendor communication. Subscribe to the Memos project's security advisories and GitHub watch list to receive immediate notifications of patch releases.
5. Consider alternative session management. If the Memos deployment is mission-critical and the unpatched state is unacceptable, evaluate moving to a different self-hosted note/knowledge-base platform that has a mature security maintenance track record.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-84203 — Official NVD listing with CVSS vector and description.
2. CWE-613 Reference: https://cwe.mitre.org/data/definitions/613.html — Insufficient Session Expiration, the weakness class for this CVE.
3. Memos Official Site/Repository: https://github.com/usememos/memos — The project's GitHub repository; monitor for security patches and 0.31.0+ release announcements.
4. Memos Documentation: https://www.usememos.com/docs — For deployment, configuration, and session/token management documentation (used to verify default ports and application characteristics).
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-84203 is NOT listed in the KEV catalog as of this writing; no in-the-wild exploitation evidence is documented by CISA.

Threat Actor / Wild Exploitation Status: No public threat actor campaigns or exploit-in-the-wild evidence are documented for CVE-2026-84203 at the time of this report. No PoC, Nuclei template, or exploit code exists in public repositories. The vulnerability's exploitability is straightforward (a valid token is sufficient), so we assess a HIGH likelihood of opportunistic exploitation once threat actors obtain a stolen refresh token through other means. Protect refresh tokens as you would passwords — they are, in effect, long-lived credentials under the currently unpatched state.