TarsWeb uses a client‑controlled header to determine if a request comes from a trusted source. The application sets a proxy option that accepts any X‑Forwarded‑For header without validating the origin or limiting hops. The SSO middleware then assigns the account identity solely from the uid query parameter when the request is considered to have come from a trusted address or path. An attacker can forge the X‑Forwarded‑For header to the loopback address and supply a uid of an existing account, thereby bypassing all authentication checks. The result is that the attacker gains the privileges of that account, which may include administrator access, user and role management, service configuration, and package deployment.

Instances of TarsCloud TarsWeb version 3.0.14 and earlier configured with Koa’s proxy option enabled and no upstream proxy restrictions are affected. The default configuration allows any client to supply an X‑Forwarded‑For header, so all deployments that have not applied the v3.0.16 fix are vulnerable.

The flaw carries a CVSS score of 9.3, indicating critical severity. EPSS data is not available, and the vulnerability is not yet listed in the CISA KEV catalog, so widespread exploitation has not been reported. Nevertheless, the lack of a credential requirement means a remote attacker with access to the HTTP interface can trigger the bypass by sending a forged X‑Forwarded‑For value naming the loopback address and a uid that identifies an existing account. Once triggered, the attacker gains full control over all administrative routes, including user and role administration, service configuration, and package upload and deployment. The possibility of a single request granting administrator privileges makes this a high‑risk vulnerability for any exposed TarsWeb instance.