CVE-2026-80349: TarsWeb Authentication Bypass Vulnerability

CVE-2026-80349 Overview

TarsWeb through version 3.0.14 contains an authentication bypass vulnerability that allows unauthenticated network attackers to impersonate any account, including administrators. The console determines whether a request originates from a trusted local caller using the X-Forwarded-For header, which is fully controlled by the client. When a request spoofs the loopback address and supplies a uid query parameter naming an existing account, the single-sign-on middleware assigns that identity without validating any ticket, cookie, or password. This grants attackers full access to user administration, role administration, service configuration, and package upload and deployment routes.

Critical Impact
Remote unauthenticated attackers can assume administrator identity on TarsWeb consoles and deploy arbitrary service packages by forging a single HTTP header and query parameter.

Affected Products

TarsCloud TarsWeb through version 3.0.14
TarsWeb app.js with Koa proxy option set to true
TarsWeb midware/ssoMidware.js in vulnerable releases

Discovery Timeline

2026-08-26 - CVE-2026-80349 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-80349

Vulnerability Analysis

The flaw is an authentication bypass by spoofing [CWE-290]. TarsWeb's app.js enables Koa's proxy option without specifying trusted upstream proxies or capping the number of forwarded hops. As a result, ctx.request.ip is derived directly from whatever the caller places in the X-Forwarded-For header.

In midware/ssoMidware.js, one branch handles both the ignored-path list and the ignoreIps allowlist defined in config/loginConf.js. That allowlist includes the loopback address. When a match occurs on either condition, the middleware assigns the effective account identity from the uid query parameter and falls through without verifying credentials.

An attacker can therefore reach every route the console mounts, including user and role administration, service configuration, and package upload and deployment endpoints. Because deployment routes accept package uploads, this bypass extends into remote code execution on managed services.

Root Cause

Two separate defects combine into a single exploitable path. First, app.js trusts client-supplied forwarding headers with no proxy allowlist. Second, ssoMidware.js conflates path-based bypass with IP-based bypass and accepts a caller-named uid in the shared branch. Version 3.0.16 splits the branches so that an allowlisted address maps to a configured default account rather than one named by the request.

Attack Vector

Exploitation requires only network reachability to the TarsWeb console. The attacker issues an HTTP request containing an X-Forwarded-For header value naming 127.0.0.1 and a uid query parameter referencing a valid account such as an administrator. No ticket, cookie, session, or password is required. See the VulnCheck Security Advisory and the TarsWeb Issue Tracker for technical details.

Detection Methods for CVE-2026-80349

Indicators of Compromise

HTTP requests to TarsWeb endpoints containing X-Forwarded-For values naming loopback addresses such as 127.0.0.1 or ::1 from external sources.
Requests to administrative routes carrying a uid query parameter but no accompanying session cookie or SSO ticket.
Unexpected package uploads or service deployments through TarsWeb without a preceding authenticated login event.
New or modified user and role assignments performed by accounts that did not authenticate through the SSO flow.

Detection Strategies

Inspect reverse-proxy and web-server logs for inbound X-Forwarded-For headers containing loopback addresses, which should never legitimately arrive from outside the trust boundary.
Correlate TarsWeb access logs against SSO authentication logs to identify privileged actions taken without a matching ticket validation event.
Alert on any TarsWeb administrative route access where the source IP recorded by Koa differs from the true network peer address.

Monitoring Recommendations

Continuously monitor deployment and package-upload endpoints on TarsWeb consoles for anomalous frequency or off-hours activity.
Baseline typical uid values seen in query strings and flag deviations, especially those referencing administrator accounts.
Forward TarsWeb, reverse-proxy, and host telemetry to a centralized analytics platform for cross-source correlation.

How to Mitigate CVE-2026-80349

Immediate Actions Required

Upgrade TarsWeb to version 3.0.16 or later, which separates the path and IP allowlist branches and assigns a configured default account for address matches.
Place TarsWeb behind an authenticating reverse proxy that strips or overwrites the inbound X-Forwarded-For header before it reaches the application.
Restrict network reachability to the TarsWeb console using firewall rules, VPN gating, or zero-trust network access controls.
Audit user, role, service configuration, and deployment history for unauthorized changes made prior to patching.

Patch Information

Upgrade to TarsWeb 3.0.16 or later. The fix in midware/ssoMidware.js separates the ignored-path branch from the ignoreIps allowlist branch, so an address match resolves to a configured default account rather than a uid supplied by the caller. Source code and release history are available in the TarsWeb Repository.

Workarounds

Disable Koa's proxy option in app.js if the TarsWeb console is not deployed behind a trusted reverse proxy.
Remove or tighten the ignoreIps entries in config/loginConf.js so the loopback address is not treated as an authenticated caller.
Configure the upstream proxy to unconditionally overwrite X-Forwarded-For with the true client address rather than appending to it.
Enforce authentication at the reverse-proxy layer so that unauthenticated requests never reach the TarsWeb SSO middleware.

bash

# Example: strip client-supplied X-Forwarded-For at an nginx reverse proxy
# Place this in the location block fronting TarsWeb
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
# Do not use: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# because that preserves attacker-supplied values.