Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Resolution SillyTavern 1.18.0 added a generic server-side request filter (Private Request Whitelisting). Since we expect users to use the application in a trusted environment, the filter is disabled by default, however it is strongly advised to be enabled and properly configured when an instance is being hosted over a network, as suggested by a console warning message and an officially published security checklist for administrators. Documentation: - https://docs.sillytavern.app/administration/config-yaml/#private-address-whitelisting - https://docs.sillytavern.app/administration/#security-checklist Note on future SSRF findings Since the request filter applies to the entire application, no SSRF vulnerabilities against individual endpoints will be accepted, unless it has been proven that a properly configured and enabled filter can be bypassed in an undocumented way. Only advisories disclosed before the 1.18.0 release will be posted if their concern is SSRF. Summary SillyTavern 1.17.0…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Resolution SillyTavern 1.18.0 added a generic server-side request filter (Private Request Whitelisting). Since we expect users to use the application in a trusted environment, the filter is disabled by default, however it is strongly advised to be enabled and properly configured when an instance is being hosted over a network, as suggested by a console warning message and an officially published security checklist for administrators. Documentation: - https://docs.sillytavern.app/administration/config-yaml/#private-address-whitelisting - https://docs.sillytavern.app/administration/#security-checklist Note on future SSRF findings Since the request filter applies to the entire application, no SSRF vulnerabilities against individual endpoints will be accepted, unless it has been proven that a properly configured and enabled filter can be bypassed in an undocumented way. Only advisories disclosed before the 1.18.0 release will be posted if their concern is SSRF. Overview - Vulnerability…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Resolution Fixed in SillyTavern 1.18.0: a user-provided URL is no longer reflected in the HTTP response body. Overview - Vulnerability Type: XSS - Affected Location: src/middleware/corsProxy.js:40 - Trigger Scenario: reflected XSS in CORS proxy error response Root Cause When fetch(url) throws, the code sends: res.status(500).send('Error occurred while trying to proxy to: ' + url + ' ' + error). The url value is attacker-controlled (req.params.url) and is not HTML-escaped before rendering. Source-to-Sink Chain 1. Source (user-controlled input) - Entry point: GET /proxy/:url() 2. Data flow - Code analysis shows concrete propagation into this sink: - vulnerability title: Reflected XSS in CORS proxy error response - sink location reached by attacker-controlled input: src/middleware/corsProxy.js:40 - The same sink behavior is confirmed by controlled execution observations. 3. Sink (dangerous operation) - Sink location: src/middleware/corsProxy.js:40 - Vulnerable behavior: reflected XSS in…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
POST /api/extensions/delete endpoint accepts extensionName: "." which bypasses sanitize-filename validation, causing the entire user extensions directory to be recursively deleted. No authentication is required in the default configuration. Affected File src/endpoints/extensions.js (last modified: commit 3ad9b05e2) Root Cause The validation check occurs before sanitization: sanitize-filename converts "." to "" (documented behavior). path.join(basePath, "") returns basePath itself. Result: the entire data\default-user\extensions\ directory is deleted. Proof of Concept Tested on: Windows 10, SillyTavern v1.17.0, commit 004f1336e Authentication: none (basicAuthMode: false, default configuration) Run in browser console (F12) while SillyTavern is open: Result: Before: [{ type: 'local', name: 'third-party/Extension-Notebook' }] Status: 200 Body: Extension has been deleted at data\default-user\extensions After: [] Impact - No authentication required (basicAuthMode: false by…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Resolution SillyTavern 1.18.0 now includes a configuration option to limit which IP addresses can authorize using SSO headers, limiting to just loopback addresses by default. A setting can be customized according to user's needs. Documentation: https://docs.sillytavern.app/administration/sso/ Summary SillyTavern accepts Remote-User (Authelia) and X-Authentik-Username (Authentik) HTTP headers to automatically log in users when SSO is configured. There is no validation that these headers originate from a trusted reverse proxy. Any network client that can reach the SillyTavern port directly can inject these headers and authenticate as any user, including administrators, without a password. This vulnerability is exploitable only when sso.autheliaAuth: true or sso.authentikAuth: true is set in config.yaml (both default to false). Detials SillyTavern implements header-based SSO for Authelia and Authentik. When enabled, the tryAutoLogin function (called on every request to /login) invokes…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Details Distinct from CVE-2025-59159 and CVE-2026-26286 (all fixed in v1.16.0). This endpoint is still unpatched. In src/endpoints/search.js line 419, the hostname is checked against /^\d+\.\d+\.\d+\.\d+$/. This only matches literal dotted-quad IPv4 (e.g. 127.0.0.1, 10.0.0.1). It does not catch: - localhost (hostname, not dotted-quad) - [::1] (IPv6 loopback) - DNS names resolving to internal addresses (e.g. localtest.me - 127.0.0.1) A separate port check (urlObj.port !== '') limits exploitation to services on default ports (80/443), making this lower severity than a fully unrestricted SSRF. PoC 1. Start SillyTavern v1.16.0 normally 2. Send requests to compare blocked vs bypassed (requires a valid session cookie or CSRF disabled): The 400 vs 500 difference confirms localhost and [::1] pass the IP check. The 500 is ECONNREFUSED (nothing listening on port 80), not a validation rejection. Impact Server-side request forgery with partial restrictions. An authenticated user can force the…
Recommended action: Upgrade to 1.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Path Traversal vulnerability in chat endpoints allows an authenticated attacker to read and delete arbitrary files under their user data root (for example secrets.json and settings.json) by supplying avatarurl="..". Details The input validator used by avatarurl blocks only / and NUL bytes, but does not block traversal segments like ... Evidence: - Weak validator regex (does not reject ..): <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/middleware/validateFileName.js#L24-L27 - Vulnerable delete path construction: <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L575-L577 - Vulnerable export path construction: <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L595-L598 - Endpoint auth context (authenticated user access):…
Recommended action: Upgrade to 1.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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): -…
Recommended action: Upgrade to 1.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability in /api/chats/import allows an authenticated attacker to write attacker-controlled files outside the intended chats directory by injecting traversal sequences into charactername. Details charactername is used unsafely as part of the destination filename and then passed into path.join(...) without sanitization. Evidence: - Import handler entrypoint: <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L680-L686 - Unsanitized charactername used in output filename: <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L719-L723 - Same write pattern in JSONL import branch: <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L759-L766 - Endpoint auth context (authenticated user access):…
Recommended action: Upgrade to 1.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The web UI for SillyTavern is susceptible to DNS rebinding, allowing attackers to perform actions like install malicious extensions, read chats, inject arbitrary HTML for phishing, etc. Details DNS rebinding is a method to bypass the CORS policies by tricking the browser into resolving something like 127.0.0.1 for a site's DNS address. This allows anybody to get remote access to anyone's SillyTavern instance without it being exposed, just by visiting a website. PoC 1. Host the PoC HTML file on a /rebind.html endpoint (or any other endpoint) on a web server on port 8000 2. Go to https://lock.cmpxchg8b.com/rebinder.html and input your IP address (A) to rebind to 127.0.0.1 (B) 3. Replace the URL in the HTML with the returned URL on the site 4. Go to http://[URL]:8000/rebind.html in firefox or on any mobile browser if you're using termux 5. Check the developer tools console. It should return all of the data Here is the PoC code: Impact Attackers can read user chats, inject HTML…
Recommended action: Upgrade to 1.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.