ghsa-mr34-8733-grr2
Vulnerability from github
Published
2025-11-14 22:09
Modified
2025-11-14 22:09
Severity ?
7.1 (High) - CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Summary
Memos' Access Tokens Stay Valid after User Password Change
Details

Summary

Access Tokens are used to authenticate application access. When a user changes their password, the existing list of Access Tokens stay valid instead of expiring. If a user finds that their account has been compromised, they can update their password.

The bad actor though will still have access to their account because the bad actor's Access Token stays on the list as a valid token. The user will have to manually delete the bad actor's Access Token to secure their account. The list of Access Tokens has a generic Description which makes it hard to pinpoint a bad actor in a list of Access Tokens.

Details

To improve Memos security, all Access Tokens will need to be revoked when a user changes their password. This removes the session for all the user's devices and prompts the user to log in again. You can treat the old Access Tokens as "invalid" because those Access Tokens were created with the older password.

PoC

  1. Have 2 devices on hand
  2. Log onto your Memos account on both devices. Notice how Access Tokens are created for each.
  3. On one device, successfully change the password. Refresh the page on the 2nd device and notice how it doesn't log out the user.
  4. On the 2nd device, change the password again. Refresh the page on the 1st device and notice how it doesn't log out the user.

Impact

A bad actor will still have access to the user's account because the Access Token does not expire on a password update. Having multi-factor authentication will vastly improve account security in Account Takeover cases instead of just relying on a password.

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/usememos/memos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.18.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-14T22:09:54Z",
    "nvd_published_at": "2025-11-14T15:15:48Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAccess Tokens are used to authenticate application access. When a user changes their password, the existing list of Access Tokens stay valid instead of expiring. If a user finds that their account has been compromised, they can update their password. \n\nThe bad actor though will still have access to their account because the bad actor\u0027s Access Token stays on the list as a valid token. The user will have to manually delete the bad actor\u0027s Access Token to secure their account. The list of Access Tokens has a generic Description which makes it hard to pinpoint a bad actor in a list of Access Tokens. \n\n### Details\n\nTo improve Memos security, all Access Tokens will need to be revoked when a user changes their password. This removes the session for all the user\u0027s devices and prompts the user to log in again. You can treat the old Access Tokens as \"invalid\" because those Access Tokens were created with the older password.\n\n### PoC\n\n1. Have 2 devices on hand\n2. Log onto your Memos account on both devices. Notice how Access Tokens are created for each.\n3. On one device, successfully change the password. Refresh the page on the 2nd device and notice how it doesn\u0027t log out the user.\n4. On the 2nd device, change the password again. Refresh the page on the 1st device and notice how it doesn\u0027t log out the user.\n\n### Impact\n\nA bad actor will still have access to the user\u0027s account because the Access Token does not expire on a password update. Having multi-factor authentication will vastly improve account security in Account Takeover cases instead of just relying on a password.",
  "id": "GHSA-mr34-8733-grr2",
  "modified": "2025-11-14T22:09:54Z",
  "published": "2025-11-14T22:09:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/usememos/memos/security/advisories/GHSA-mr34-8733-grr2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21635"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/usememos/memos"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/Top10/A04_2021-Insecure_Design"
    },
    {
      "type": "WEB",
      "url": "http://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Memos\u0027 Access Tokens Stay Valid after User Password Change"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.