CVE-2026-80349 in TarsWeb
Summary
by MITRE • 08/26/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability in TarsWeb stems from an insecure trust boundary assumption regarding client-controlled HTTP headers, specifically leading to unauthorized access and privilege escalation. The application utilizes Koa as its web framework with the proxy option enabled but fails to configure a specific list of trusted upstream proxies or limit the number of forwarded hops allowed by the X-Forwarded-For header. Consequently, when a request is received, Koa determines the client's IP address based entirely on the value provided in this header rather than the actual network connection source. This design flaw allows an attacker to spoof their apparent origin by setting the X-Forwarded-For header to mimic internal or loopback addresses, effectively bypassing security checks that rely on IP-based trust assumptions.
The authentication logic within middleware/ssoMidware.js exacerbates this issue through a flawed control flow structure. The code contains a conditional branch designed to handle both ignored path lists and an ignoreIps allowlist from the configuration file loginConf.js. This allowlist includes loopback addresses such as 127.0.0.1, which are typically reserved for internal services that do not require standard authentication. However, instead of restricting access based on IP alone or requiring additional validation when these conditions are met, the code assigns the effective account identity directly from a user-supplied uid query parameter. Crucially, this assignment occurs before any verification of tickets, cookies, passwords, or other credentials takes place. The logic then falls through to process the request as that assigned user without further authentication checks.
This combination of header spoofing and flawed authentication logic results in a severe unauthorized access vulnerability. An attacker can craft a malicious HTTP request containing an X-Forwarded-For header set to 127.0.0.1 or another trusted loopback address, along with a uid query parameter corresponding to any existing account within the system. Because the middleware accepts this identity assignment without validation, the forged request is treated as if it originated from a local service and belongs to the specified user. This allows an unauthenticated external attacker to impersonate any valid user, including administrators, gaining full access to sensitive administrative functions such as user management, role configuration, service settings, and package deployment capabilities.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, specifically involving the misuse of trusted headers for identity assertion without proper validation. It also relates to CWE-918 Server-Side Request Forgery (SSRF) principles in terms of manipulating server-side trust decisions based on client input. In the context of MITRE ATT&CK, this behavior corresponds to T1078 Valid Accounts and potentially T1621 Multi-Factor Authentication Request Interception if multi-factor systems were present but bypassed due to the header spoofing. The impact is critical as it allows complete compromise of the application's integrity and confidentiality by enabling arbitrary account takeover without any prior credentials or exploits against other system components.
The issue was addressed in version 3.0.16 through a structural change to the middleware logic. The developers separated the handling of ignored paths from the IP allowlist checks, ensuring that matching an address on the ignoreIps list no longer results in direct assignment of a user-supplied uid. Instead, such requests are now assigned a configured default account identity rather than one derived from attacker-controlled input. This change enforces proper separation between trust boundaries and authentication flows, preventing the bypass of credential verification mechanisms. To mitigate similar risks in other systems, developers should avoid relying solely on X-Forwarded-For for IP validation unless strictly limited to known proxy IPs, implement strict allowlists for trusted proxies, and ensure that identity assignment always follows successful cryptographic or session-based authentication rather than preceding it.