GHSA-WMM3-H9QJ-P5V6

Vulnerability from github – Published: 2026-05-12 22:23 – Updated: 2026-06-09 10:32
VLAI
Summary
SillyTavern: Existing sessions are not invalidated after password change, allowing session reuse and account takeover
Details

Summary

Changing a user’s password does not invalidate existing sessions, allowing an attacker with a stolen cookie to retain access even after the victim resets their password.

Details

SillyTavern relies on cookie-session for authentication, storing all session data (user handle, permissions) in a signed cookie. The endpoints POST /api/users/change-password and POST /api/users/recover-step2 only update the password hash in the database but do not expire current sessions. Because the session is stateless and stored entirely in the client cookie, there is no server-side mechanism to revoke a token once issued.

PoC

1.Log into the same SillyTavern account from two different browsers (e.g., Chrome and Firefox private mode). 2.In Chrome, change the account password under User Settings → Change Password. 3.In Firefox, refresh the page or perform a protected action (e.g., view API keys). 4.Expected: Firefox session should be invalidated and ask for login. 5.Actual: Firefox remains fully authenticated, able to perform all actions as the targeted user.

Impact

An attacker who obtains a valid session cookie (via XSS, MITM, physical access, etc.) can continue using it indefinitely, even after the legitimate user changes their password. This nullifies the most common recovery measure against session theft. The default cookie lifespan is 400 days, giving an attacker a very long exploitation window.

Resolution

A fix was released in the version 1.18.0, invalidating a session cookie on account password change.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "sillytavern"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-12T22:23:20Z",
    "nvd_published_at": "2026-05-29T19:16:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nChanging a user\u2019s password does not invalidate existing sessions, allowing an attacker with a stolen cookie to retain access even after the victim resets their password.\n\n### Details\nSillyTavern relies on cookie-session for authentication, storing all session data (user handle, permissions) in a signed cookie. The endpoints POST /api/users/change-password and POST /api/users/recover-step2 only update the password hash in the database but do not expire current sessions. Because the session is stateless and stored entirely in the client cookie, there is no server-side mechanism to revoke a token once issued.\n\n### PoC\n1.Log into the same SillyTavern account from two different browsers (e.g., Chrome and Firefox private mode).\n2.In Chrome, change the account password under User Settings \u2192 Change Password.\n3.In Firefox, refresh the page or perform a protected action (e.g., view API keys).\n4.Expected: Firefox session should be invalidated and ask for login.\n5.Actual: Firefox remains fully authenticated, able to perform all actions as the targeted user.\n\n### Impact\nAn attacker who obtains a valid session cookie (via XSS, MITM, physical access, etc.) can continue using it indefinitely, even after the legitimate user changes their password.\nThis nullifies the most common recovery measure against session theft.\nThe default cookie lifespan is 400 days, giving an attacker a very long exploitation window.\n\n### Resolution\nA fix was released in the version 1.18.0, invalidating a session cookie on account password change.",
  "id": "GHSA-wmm3-h9qj-p5v6",
  "modified": "2026-06-09T10:32:03Z",
  "published": "2026-05-12T22:23:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SillyTavern/SillyTavern/security/advisories/GHSA-wmm3-h9qj-p5v6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44648"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SillyTavern/SillyTavern"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SillyTavern/SillyTavern/releases/tag/1.18.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SillyTavern: Existing sessions are not invalidated after password change, allowing session reuse and account takeover"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…