SillyTavern SSO Header Spoofing Authentication Bypass
Unvalidated Remote-User/X-Authentik-Username headers let any network client impersonate any user, including admins, when Authelia/Authentik SSO is enabled
SillyTavern, a self-hosted web UI for local LLM, image-generation, and TTS models, contains a critical authentication bypass in versions prior to 1.18.0. When an admin enables SSO integration with Authelia or Authentik (sso.autheliaAuth/sso.authentikAuth), the app blindly trusts the Remote-User or X-Authentik-Username HTTP headers to auto-login users, with no check that a real reverse proxy set them. Any client that can reach the SillyTavern port directly can forge these headers and log in as any user, including administrators, without a password — full account and data takeover. Fixed in 1.18.0, which adds an IP allowlist for SSO header trust.
Technical Breakdown
SillyTavern SSO Header Spoofing Authentication Bypass
headerUserLogin() — the handler backing SSO auto-login — reads the Remote-User and X-Authentik-Username HTTP headers directly via Express's request.get() and trusts whatever value is present to establish an authenticated session, with no check that the header was actually set by a trusted reverse proxy versus supplied verbatim by the connecting client. Because HTTP headers are fully attacker-controlled unless a proxy is guaranteed to strip/overwrite them, any client that can reach the app's TCP port can set Remote-User: admin and be logged in as that user with zero credentials. A secondary issue — the /api/users/list endpoint being registered before auth middleware — makes valid usernames trivially enumerable to feed into this attack.
Front SillyTavern with a reverse proxy that strips/overwrites Remote-User and X-Authentik-Username, and firewall the app port to the proxy only
Root Cause
headerUserLogin() reads Remote-User and X-Authentik-Username straight off the incoming request and treats their presence as proof of upstream SSO authentication. There is no source-IP check, no shared secret, and no verification that a trusted reverse proxy — rather than the connecting client itself — set the header.
Vulnerable Pattern
Trusting a proxy-injected header without a corresponding trust boundary is a textbook CWE-290/CWE-346 pattern. HTTP headers set by an upstream proxy are indistinguishable, on the wire, from the same header set directly by a malicious client — unless the app enforces that traffic can only arrive from that proxy's address.
Why AI Services Are High-Value
Self-hosted LLM UIs like SillyTavern routinely store live provider API keys, chat history, and character/persona data in the compromised account's settings. A single forged header yields an authenticated admin session with no rate limit, no lockout, and no password to crack — the entire credential-stuffing defensive playbook is irrelevant because the bypass skips authentication entirely.
The Fix
1.18.0 adds a sso.trustedProxies allowlist (default ['::1', '127.0.0.1'], supports CIDR/wildcards) restricting which source IPs are permitted to authenticate a request via SSO headers at all — closing the gap between "header present" and "header trustworthy."
Attack Chain
Recon — Discover an exposed SillyTavern instance
Attacker scans for or stumbles on a SillyTavern instance reachable on the network (self-hosted instances are frequently port-forwarded, exposed via Tailscale/reverse proxy misconfig, or left open on a home/office LAN).
Defensive note: Never expose the raw SillyTavern port to the internet or an untrusted network segment; monitor for unexpected inbound connections on the configured port (default 8000) from outside the trusted proxy IP.
Enumerate valid usernames
/api/users/list is registered before authentication middleware and is publicly reachable pre-auth, returning handles, display names, avatars, and admin flags — attacker picks an admin account to target.
Defensive note: Check server logs/WAF for anonymous requests to /api/users/list; treat any hit from a non-proxy IP as a reconnaissance indicator.
Forge the SSO trust header
Attacker sends a request with Remote-User: <admin-handle> (or X-Authentik-Username) directly to the app, bypassing the reverse proxy entirely since the header is accepted from any source.
Defensive note: Grep access/proxy logs for Remote-User or X-Authentik-Username header values arriving from anything other than the trusted proxy's loopback/internal IP — the single clearest IOC for this CVE.
Session establishment
The app's headerUserLogin() logic matches the spoofed header to the real account and issues a valid, authenticated session cookie with no password or MFA challenge.
Defensive note: Alert on new authenticated sessions created without a corresponding login-form POST or credential exchange in the logs — anomalous "silent" logins are a signature of this bypass.
Impact — Full account takeover and data access
With an authenticated admin session, the attacker reads/exfiltrates chat logs, character cards, API keys/model credentials stored in settings, and can modify server config or create/delete accounts.
Defensive note: Rotate any API keys stored in SillyTavern settings if compromise is suspected; review admin panel audit trails (if any) for config or user changes from unfamiliar sessions.
Impact
Auth-bypass vulnerabilities are especially damaging in self-hosted AI tools because a single forged request replaces the entire authentication story — no password to crack, no MFA to defeat, and no rate limit to slow an attacker down, while the compromised account often holds live LLM provider credentials worth far more than the app itself.
Credential & Secret Exposure
- SillyTavern commonly stores LLM provider API keys (OpenAI, Anthropic, etc.) and image/TTS service credentials in user settings, all exposed by a hijacked session
- Any connected proxy/backend credentials become reachable
- Stolen API keys can be used for unrelated, costly abuse billed to the victim
- No password reset flow interrupts an attacker already holding a valid session
Data Confidentiality (Chat/Character Data)
- Full access to a victim's chat histories, character cards, and personas, often sensitive personal or creative content
- Enables silent, persistent snooping if the attacker retains access (e.g. by also creating a new account)
- No password reset or MFA blocks this path since authentication is bypassed entirely, not cracked
- Exposure extends to any content generated or stored during the session window
Account & System Integrity
- Attacker can act with full admin privileges: modify server config, delete/create user accounts, alter extension/plugin settings
- Because this is a pre-auth bypass, standard password-based defenses (rate limiting, lockouts, complexity rules) provide zero protection
- Compromise can enable pivoting to adjacent self-hosted inference services on the same host/network
- Admin-level changes may persist undetected without dedicated audit logging
Defensive Tutorial
Patch to 1.18.0+
ImmediateUpgrade immediately if sso.autheliaAuth: true or sso.authentikAuth: true is set anywhere in config.yaml. The only complete fix.
Check SSO flag status
ImmediateRun grep -A2 "autheliaAuth\|authentikAuth" config.yaml on every deployment to confirm whether the vulnerable code path is even active; if both are false, exposure is limited to the (still real, lower-severity) unauthenticated /api/users/list enumeration.
Log review for spoofed headers
ImmediateGrep proxy/app access logs for Remote-User: or X-Authentik-Username: header values originating from any IP other than the trusted reverse proxy's loopback/internal address.
Rotate exposed secrets
ImmediateIf SSO was enabled and the instance was network-reachable prior to patching, rotate all API keys stored in SillyTavern user settings, and force-invalidate existing sessions after upgrade.
Set sso.trustedProxies explicitly after upgrading
ImportantAfter upgrading to 1.18.0+, configure sso.trustedProxies to the exact IP(s)/CIDR of your reverse proxy only (default is ['::1', '127.0.0.1']); never leave it as ['*'] in any internet- or LAN-exposed deployment.
Network-isolate the app port
ImportantFirewall the SillyTavern listening port (default 8000) so it's reachable only from the reverse proxy host, not directly from the LAN or internet.
Reverse proxy header hygiene
ImportantConfirm the fronting proxy (nginx/Caddy/Traefik) explicitly strips or overwrites Remote-User and X-Authentik-Username on the client-facing side before setting them itself on the upstream leg.
SBOM/dependency tracking for self-hosted AI tools
ImportantAdd SillyTavern (and other locally-installed LLM UIs) to asset/SBOM inventory with automated CVE monitoring, since these tools are frequently deployed outside normal patch-management pipelines.
Zero-trust header policy for all SSO integrations
ImportantStandardize an org-wide rule that any app trusting proxy-injected auth headers must implement a source-IP or mTLS trust boundary check by default, and require this as a checklist item in any future self-hosted tool onboarding review.
References
- NVD Entry CVE-2026-44649 — National Vulnerability Database entry with CVSS vector and affected version range.
- GitHub Security Advisory GHSA-gxx6-h3g6-vwjh — Vendor advisory with patch details and disclosure timeline.
- CWE Reference CWE-290 — Authentication Bypass by Spoofing
- CWE Reference CWE-306 — Missing Authentication for Critical Function
- CWE Reference CWE-346 — Origin Validation Error
- CWE Reference CWE-807 — Reliance on Untrusted Inputs in a Security Decision