GHSA-525J-2HRJ-M8FP

Vulnerability from github – Published: 2026-04-01 21:40 – Updated: 2026-04-01 21:40
VLAI?
Summary
SillyTavern: Path Traversal allows file existence oracle
Details

Summary

A path traversal vulnerability in the static file route handler allows any unauthenticated user to determine whether files exist anywhere on the server's filesystem. By sending percent-encoded ../ sequences (%2E%2E%2F) in requests to static file routes, an attacker can check for the existence of files (404 if it doesn't exist, 403 means it exists).

Details

The vulnerability is in createRouteHandler (src/users.js:947–963), which backs all user-data static file routes:

function createRouteHandler(directoryFn) {
    return async (req, res) => {
        const directory = directoryFn(req);
        const filePath = decodeURIComponent(req.params[0]);
        const exists = fs.existsSync(path.join(directory, filePath)); // no boundary check here
        if (!exists) {
            return res.sendStatus(404);
        }
        return res.sendFile(filePath, { root: directory });
    };
}

req.params[0] contains the raw (percent-encoded) wildcard from the URL. After decodeURIComponent, a request path like /characters/%2E%2E%2F%2E%2E%2FUsers/kirakira decodes to ../../Users/kirakira, and path.join resolves it outside the intended directory. res.sendFile correctly blocks the file from being served (the send module's root check returns 403), but fs.existsSync had already run, and the 403/404 distinction reveals the result.

Affected routes (they all use the same handler, so they're all affected):

  • /characters/*
  • /user/files/*
  • /assets/*
  • /user/images/*
  • /backgrounds/*
  • /User%20Avatars/*

PoC

curl -o /dev/null -s -w "%{http_code}\n" "http://localhost:8000/characters/%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2FUsers/kirakira/something"

Impact

While file contents cannot be read (the send module blocks actual delivery), anyone who can reach the SillyTavern HTTP port can check the existence of files on the host filesystem.

Resolution

The issue was addressed in version 1.17.0.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.16.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "sillytavern"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T21:40:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA path traversal vulnerability in the static file route handler allows any unauthenticated user to determine whether files exist anywhere on the server\u0027s filesystem. By sending percent-encoded `../` sequences (`%2E%2E%2F`) in requests to static file routes, an attacker can check for the existence of files (404 if it doesn\u0027t exist, 403 means it exists).\n\n### Details\n\nThe vulnerability is in `createRouteHandler` (`src/users.js:947\u2013963`), which backs all user-data static file routes:\n\n```javascript\nfunction createRouteHandler(directoryFn) {\n    return async (req, res) =\u003e {\n        const directory = directoryFn(req);\n        const filePath = decodeURIComponent(req.params[0]);\n        const exists = fs.existsSync(path.join(directory, filePath)); // no boundary check here\n        if (!exists) {\n            return res.sendStatus(404);\n        }\n        return res.sendFile(filePath, { root: directory });\n    };\n}\n```\n\n`req.params[0]` contains the raw (percent-encoded) wildcard from the URL. After `decodeURIComponent`, a request path like `/characters/%2E%2E%2F%2E%2E%2FUsers/kirakira` decodes to `../../Users/kirakira`, and `path.join` resolves it outside the intended directory. `res.sendFile` correctly blocks the file from being served (the `send` module\u0027s root check returns 403), but `fs.existsSync` had already run, and the 403/404 distinction reveals the result.\n\nAffected routes (they all use the same handler, so they\u0027re all affected):\n\n- `/characters/*`\n- `/user/files/*`\n- `/assets/*`\n- `/user/images/*`\n- `/backgrounds/*`\n- `/User%20Avatars/*`\n\n### PoC\n\n```bash\ncurl -o /dev/null -s -w \"%{http_code}\\n\" \"http://localhost:8000/characters/%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2FUsers/kirakira/something\"\n```\n\n### Impact\n\nWhile file contents cannot be read (the `send` module blocks actual delivery), anyone who can reach the SillyTavern HTTP port can check the existence of files on the host filesystem.\n\n### Resolution\n\nThe issue was addressed in version 1.17.0.",
  "id": "GHSA-525j-2hrj-m8fp",
  "modified": "2026-04-01T21:40:22Z",
  "published": "2026-04-01T21:40:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SillyTavern/SillyTavern/security/advisories/GHSA-525j-2hrj-m8fp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SillyTavern/SillyTavern"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SillyTavern: Path Traversal allows file existence oracle"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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…