CVE-2026-26286: SillyTavern SSRF Vulnerability

CVE-2026-26286 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in SillyTavern, a locally installed user interface that enables users to interact with text generation large language models, image generation engines, and text-to-speech voice models. In versions prior to 1.16.0, the asset download endpoint allows authenticated users to make arbitrary HTTP requests from the server and read the full response body, enabling access to internal services, cloud metadata, and private network resources.

Critical Impact

Authenticated attackers can leverage this SSRF vulnerability to access internal network resources, cloud metadata endpoints (such as AWS/GCP/Azure instance metadata), and other services not intended to be publicly accessible, potentially leading to credential theft and lateral movement within the infrastructure.

Affected Products

• SillyTavern versions prior to 1.16.0
• Self-hosted SillyTavern instances with network access to internal resources
• Cloud-deployed SillyTavern installations with access to metadata services

Discovery Timeline

• 2026-02-19 - CVE-2026-26286 published to NVD
• 2026-02-19 - Last updated in NVD database

Technical Details for CVE-2026-26286

Vulnerability Analysis

This vulnerability exists in SillyTavern's asset download endpoint, which failed to properly validate the destination of HTTP requests initiated by the server. The SSRF flaw (CWE-918) allows authenticated users to craft malicious requests that cause the server to make outbound HTTP connections to arbitrary destinations. Because the full response body is returned to the attacker, this creates a powerful information disclosure vector.

The attack requires authentication, meaning an attacker must have valid credentials to the SillyTavern instance. However, once authenticated, the attacker can leverage the server as a proxy to reach internal network segments, cloud provider metadata services (such as http://169.254.169.254/ on AWS), or other backend services that trust requests originating from the SillyTavern server's IP address.

Root Cause

The root cause of this vulnerability is the absence of domain or URL validation in the asset download functionality. Prior to version 1.16.0, the application accepted user-supplied URLs without verifying that the target domain was on an approved whitelist. This allowed attackers to specify arbitrary URLs, including those pointing to internal network resources, localhost services, or cloud metadata endpoints.

Attack Vector

The vulnerability is exploited via the network attack vector with low complexity. An authenticated attacker can manipulate the asset download endpoint by supplying a crafted URL that points to an internal resource. The server processes this request, fetches the content from the specified URL, and returns the full response body to the attacker. This enables reconnaissance of internal networks, access to sensitive cloud metadata (including IAM credentials), and potential pivoting to other internal services.

A typical attack scenario involves the attacker submitting a request to the asset download endpoint with a URL targeting the cloud metadata service. The server, having network access to this endpoint, retrieves the metadata (potentially including temporary security credentials) and returns it to the attacker through the normal response mechanism.

Detection Methods for CVE-2026-26286

Indicators of Compromise

• Unusual outbound HTTP requests from the SillyTavern server to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• HTTP requests to cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal
• Anomalous asset download requests containing URLs pointing to localhost (127.0.0.1) or internal hostnames
• Access logs showing repeated requests to the asset download endpoint with varying internal target URLs

Detection Strategies

• Implement network monitoring to detect outbound connections from the SillyTavern server to unexpected internal destinations
• Configure web application firewalls (WAF) to flag and block requests containing internal IP addresses or metadata service URLs
• Enable detailed logging on the asset download endpoint to capture all URL parameters and source authentication details
• Deploy intrusion detection rules to alert on SSRF patterns such as requests to RFC 1918 addresses from web application servers

Monitoring Recommendations

• Monitor SillyTavern server egress traffic for connections to internal network segments and cloud metadata services
• Implement alerting on high-frequency asset download requests from single authenticated users
• Review application logs regularly for failed or unusual asset download attempts
• Configure cloud provider security tools to detect and alert on metadata endpoint access patterns

How to Mitigate CVE-2026-26286

Immediate Actions Required

• Upgrade SillyTavern to version 1.16.0 or later immediately to apply the security patch
• Review access logs for any evidence of exploitation prior to patching
• Rotate any credentials that may have been exposed through cloud metadata access
• Implement network segmentation to limit the SillyTavern server's access to internal resources

Patch Information

The vulnerability has been patched in SillyTavern version 1.16.0. The fix introduces a whitelist domain check for asset download requests, preventing arbitrary URL fetching. The whitelist can be reviewed and customized by editing the whitelistImportDomains array in the config.yaml file. For detailed information about the security fix, refer to the GitHub Security Advisory.

Workarounds

• If immediate upgrade is not possible, implement network-level controls to block outbound requests from the SillyTavern server to internal IP ranges and metadata endpoints
• Configure a reverse proxy or WAF in front of SillyTavern to filter requests to the asset download endpoint
• Restrict network access from the SillyTavern host using firewall rules to only allow necessary outbound connections
• Review and limit user authentication to trusted individuals while the vulnerability remains unpatched

# Example: Configure whitelist domains in config.yaml
# Add trusted domains to the whitelistImportDomains array
# Example configuration after upgrading to 1.16.0+
whitelistImportDomains:
  - "example.com"
  - "trusted-cdn.example.org"
  - "assets.yourdomain.com"