SillyTavern Header-Based SSO Authentication Bypass – Untrusted Proxy Trust Model
SillyTavern trusts HTTP headers (`Remote-User`, `X-Authentik-Username`) from any network client without validating origination from a trusted reverse proxy, allowing unauthenticated attackers to impersonate any user including administrators. This is a foundational architectural flaw in SSO integration.
CVE References
Affected
Vulnerability Description
SillyTavern implements header-based Single Sign-On (SSO) authentication for Authelia and Authentik integrations. When SSO is enabled via sso.autheliaAuth or sso.authentikAuth configuration flags, the application automatically creates authenticated sessions based on HTTP headers (Remote-User or X-Authentik-Username) without validating that these headers originate from a trusted reverse proxy. This violates the implicit security contract of header-based SSO: only a trusted upstream proxy should set authentication headers. The root cause is a missing source IP validation check in the headerUserLogin function (src/users.js:779–801), which reads headers directly from client requests without verifying origination from a configured trusted proxy address.
Proof-of-Concept Significance
The disclosed vulnerability demonstrates that any network client with direct connectivity to the SillyTavern port can craft HTTP requests containing spoofed SSO headers to bypass authentication entirely. The PoC proves the application blindly trusts these headers without origin verification, allowing attackers to assume the identity of any user (including administrators) without passwords. Preconditions are minimal: SSO must be enabled in configuration (both default to false), and the attacker must have network access to the SillyTavern port—a likely condition in shared hosting, container orchestration, or internal network scenarios where the application is accessible beyond the reverse proxy boundary.
Detection Guidance
Log Indicators:
- Successful authentication events (session creation) lacking corresponding reverse-proxy authentication logs
headerUserLoginfunction invocations with header values originating from unexpected source IPs- Session creation for privileged accounts without prior password authentication attempts
- HTTP requests to
/loginendpoint withRemote-UserorX-Authentik-Usernameheaders from non-proxy IP ranges
Signatures:
- Monitor for HTTP requests containing
Remote-UserorX-Authentik-Usernameheaders from IPs outside the configured SSO proxy whitelist - Alert on session creation when SSO is enabled but headers originate from non-loopback/non-trusted addresses
- YARA-style: detect
GET /login+ presence of SSO headers + source IP ∉ trusted set
Mitigation Steps
Immediate:
- Upgrade to SillyTavern 1.18.0 or later, which introduces IP-based validation for SSO header origins
- Temporarily disable SSO authentication (
sso.autheliaAuth: false,sso.authentikAuth: false) if upgrade cannot be applied - Restrict network access to SillyTavern port to only the upstream reverse proxy IP (firewall rules, network segmentation)
Configuration:
- After upgrading, configure the SSO IP allowlist to restrict header acceptance to loopback (default:
127.0.0.1,::1) or specific proxy IPs as documented in https://docs.sillytavern.app/administration/sso/ - Ensure the reverse proxy is the sole network path to SillyTavern; disable direct public access
Defense-in-Depth:
- Implement WAF rules to reject requests with SSO headers from untrusted sources
- Monitor authentication logs for anomalies (e.g., admin account logins from unexpected contexts)
- Enforce strong administrator passwords as a secondary control
Risk Assessment
Likelihood of Exploitation: High. The vulnerability requires only basic HTTP client capability (curl, browser) and is trivial to exploit. Organizations using SillyTavern with SSO enabled and direct network access to the application are at immediate risk. Threat actors can achieve full account takeover and privilege escalation without brute-forcing credentials.
Threat Actor Interest: High. This is an unauthenticated remote code execution vector when combined with administrator impersonation. Red teams and adversaries actively seek header injection vulnerabilities as a primary attack path in proxy/SSO architectures. The vulnerability is likely already known to security-conscious threat actors given its simplicity and high impact.
Exploitation in the Wild: Moderate-to-High probability. Misconfigurations exposing SillyTavern directly to untrusted networks (compromised internal networks, cloud misconfiguration) create low-friction exploitation opportunities.
Sources