CVE-2026-80349: TarsWeb through 3.0.14 Authentication Bypass via Spoofed X-Forwarded-For and uid Parameter
TarsWeb decides whether a request comes from a trusted local caller using a client-controlled header. app.js sets Koa's proxy option to true without naming which upstream proxies may be trusted and without limiting the number of forwarded hops, so the request address Koa reports is taken from the X-Forwarded-For header supplied by the caller. In midware/ssoMidware.js a single branch covers both the ignored-path list and the ignoreIps allowlist from config/loginConf.js, which contains the loopback address, and that branch assigns the effective account identity from the uid query parameter before falling through to the request without validating any ticket, cookie or password. A request carrying a forged X-Forwarded-For value naming the loopback address and a uid naming an existing account therefore reaches every route the console mounts as that account, including an administrator, with no credential of any kind. Those routes include user and role administration, service configuration, and package upload and deployment. Version 3.0.16 separates the two branches so that a match on the address allowlist assigns the configured default account rather than one named by the caller.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
TarsWebto a version that resolves this vulnerability.Fixed in 3.0.16Patch TarsWeb through 3.0.14 Authentication Bypass via Spoofed X-Forwarded-For and uid Parameter - Configuration
In app.js, do not set Koa's proxy option to true unless you explicitly configure which upstream proxies are trusted and limit the maximum forwarded hops; otherwise Koa will trust caller-supplied X-Forwarded-For.
Koa (app.js) proxy = true - Configuration
Ensure TarsWeb does not treat client-controlled X-Forwarded-For as proof of a trusted local caller; trust decisions must not be based on the caller-supplied header.
Console routes trust boundary X-Forwarded-For validation = server-validated
Event History
Frequently Asked Questions
Does exploitation require valid credentials or an authenticated session?
No. An unauthenticated remote attacker can spoof X-Forwarded-For as the loopback address and supply the uid of an existing account; no ticket, cookie, password, or other credential is validated on this path.
What level of access can an attacker obtain?
The attacker can impersonate any existing account named by uid, including an administrator. Accessible console functions include user and role administration, service configuration, and package upload and deployment.
What changed in version 3.0.16?
Version 3.0.16 separates handling of ignored paths from the IP allowlist. When the address allowlist matches, it assigns the configured default account instead of accepting an account identity supplied through uid.