CVE-2026-80349
CriticalCVSS 9.8Summary
TarsWeb trusts a client-controlled X-Forwarded-For header, allowing an attacker to impersonate a local caller. By forging a loopback address and providing a uid of an existing account, an attacker can access the console as any user, including administrator, without credentials. Version 3.0.16 fixes this.
Risk Assessment
Full compromise of TarsWeb, including user and role administration, service configuration, and package deployment, potentially leading to application takeover.
Recommendation
Update TarsWeb to version 3.0.16 or later, which separates the ignored-path list from the IP allowlist.
Original NVD description (English source)
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.