TarsWeb EUVD-2026-66388

Exploitation requires that the attacker can send HTTP requests to a TarsWeb console (through 3.0.14) and that the loopback address is present in the config/loginConf.js ignoreIps allowlist, which is the default. The attacker must supply a forged X-Forwarded-For header naming that allowlisted address and a uid query parameter naming an existing account (e.g., an administrator). Limiting factors: the deployment must not sit behind a proxy that sanitizes or overwrites X-Forwarded-For (Koa proxy=true is set without naming trusted proxies, so unsanitized headers are trusted); the attacker needs network reachability to the console, which is frequently internal-only; and the named uid must match a real account. No authentication, cookie, ticket, password, or user interaction is required.

This is a genuine high priority, not a paper-tiger high-CVSS finding. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) matches the description: exploitation is remote, requires no privileges, no user interaction, and yields full confidentiality, integrity, and availability impact by granting administrator-equivalent access to every console route - user/role administration, service configuration, and package upload and deployment, the last effectively enabling remote code execution via malicious deployment. No EPSS score was provided, so probabilistic exploitation likelihood cannot be quantified; the CVE is not listed in CISA KEV and no POC is referenced, so it is not confirmed as actively exploited. The primary real-world limiter is exposure: TarsWeb consoles are typically internal infrastructure tooling and may not be internet-facing, narrowing the attacker set to those with network reach. The description and CVSS vector are internally consistent - both agree on unauthenticated network access.

An attacker who can reach the TarsWeb console over the network sends an HTTP request with the header 'X-Forwarded-For: 127.0.0.1' and a query parameter such as 'uid=admin' naming an existing administrator. The SSO middleware matches the spoofed loopback address against ignoreIps and adopts the attacker-chosen identity with no credential check, granting full admin access to upload and deploy a malicious service package. No POC is referenced, but the request is trivial to craft with any HTTP client.