Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T10:16:43.097Z",
  "pubdate": "2026-08-26T10:16:43.097Z",
  "executiveSummary": "TarsWeb versions prior to 3.0.16 are susceptible to a critical authentication bypass vulnerability stemming from improper validation of client-supplied request headers. The application incorrectly trusts the X-Forwarded-For header to determine the request's origin, enabling attackers to spoof IP addresses.\nBy manipulating this header to include loopback addresses, an attacker can bypass IP-based allowlists defined in config/loginConf.js. The vulnerability resides in midware/ssoMidware.js, where the application fails to distinguish between legitimate internal traffic and external requests. This flaw allows unauthorized actors to impersonate any user, including administrative accounts, without providing valid credentials.\nThe impact is severe, granting attackers full control over critical system functions, including service configuration, package deployment, and user administration. Exploitation requires no prior authentication, as the application assumes the request originates from a trusted local context. The vulnerability is effectively addressed in version 3.0.16, which enforces strict separation between trusted address verification and user identity assignment, ensuring that matched IP addresses only map to a preconfigured default identity rather than a user-supplied UID.",
  "technicalDetails": "The vulnerability originates from a misconfiguration in app.js where the Koa framework's proxy trust option is enabled globally. By setting proxy: true, the application automatically trusts the X-Forwarded-For header to determine the remote IP address of incoming requests. Crucially, the configuration lacks both a defined list of trusted upstream proxies and a restriction on the number of forwarded hops. This allows a client to control the X-Forwarded-For header value, effectively spoofing the source IP address.\nIn midware/ssoMidware.js, the logic responsible for authentication bypass erroneously merges two distinct validation paths: the ignore-path list and the ignoreIps allowlist. When a request matches the IP allowlist—which includes loopback addresses (127.0.0.1)—the middleware triggers a code path that trusts the uid query parameter provided by the client. Because this check precedes any ticket, cookie, or password validation, the system assumes the identity specified by the uid parameter is legitimate.\nThe exploitation flow is as follows: 1) The attacker crafts an HTTP request containing a forged X-Forwarded-For header set to 127.0.0.1. 2) The attacker includes a uid parameter in the query string set to an administrator's username. 3) Koa processes the forged header, reporting the request origin as the loopback address. 4) midware/ssoMidware.js evaluates the request against config/loginConf.js, matches the spoofed IP against the allowlist, and enters the bypass branch. 5) The middleware implicitly trusts the provided uid and assigns the session identity as the administrator. 6) The request is passed to downstream routes, allowing the attacker to execute administrative functions including service management, package uploads, and configuration changes.\nThis vulnerability effectively renders the application's entire security model moot for any endpoint configured to ignore authentication for trusted IPs. As version 3.0.16 addresses this by decoupling the IP check from the identity assignment, it is critical that deployments transition to this or later versions to prevent arbitrary account impersonation."
}