HarnessRouter EUVD-2026-107496

Exploitable only when BOTH hold: (1) the HarnessRouter gateway runs the vulnerable pre-0.31.11 default identity mode 'observe' (HR_IDENTITY_MODE unset), where X-Harness-Org/X-Harness-Member headers are trusted even when the accompanying bearer token does not verify; and (2) a front-end console operating in non-self-hosted/multi-tenant mode attaches HARNESS_INTERNAL_KEY to every request carrying an Authorization header, allowing the forged identity headers to reach the gateway with the key. Self-hosted deployments are NOT affected because their entrypoint explicitly sets HR_IDENTITY_MODE=off and the console pins a single organization. Limiting factors: the attacker must be able to send requests through such a console and inject the X-Harness-Org/X-Harness-Member headers alongside any (even invalid) Authorization header; impact is confined to improper cross-tenant authorization with Low confidentiality/integrity/availability consequences.

Signals point to a genuine but moderate, condition-gated issue rather than a top-tier emergency. The vendor CVSS 4.0 base score is 6.3 (medium) with AV:N/AC:H/AT:N/PR:N/UI:N and uniformly Low impact (VC:L/VI:L/VA:L, no scope change), and the description independently states high attack complexity with exploitability 'difficult' - these agree. Exploitation status is 'no public exploit identified at time of analysis' (no CISA KEV entry and no POC in the provided data). No EPSS score and no SSVC decision data were supplied, so automatable/exploitation-maturity signals are UNKNOWN and cannot be weighed. The source diff confirms the real-world risk is narrow: only deployments pairing a non-self-hosted/multi-tenant console (which attaches the internal key to any request bearing an Authorization header) with the pre-patch default identity mode 'observe' are affected, while self-hosted installs ship with mode 'off' and are not. Net: a real, verifiable cross-tenant authorization flaw worth patching for multi-tenant operators, but the AC:H rating, limited Low impact, configuration dependency, and absence of exploitation evidence make it a routine-priority fix, not a drop-everything item. Caveat: PR:N (unauthenticated) is reported, yet exploitation depends on routing through a console in a specific mode - verify your deployment topology rather than treating it as trivially remote.

In a multi-tenant deployment, an attacker sends a request to the front-end console carrying a junk/unverifiable bearer token plus attacker-chosen X-Harness-Org and X-Harness-Member headers. The console (not in self-hosted mode) attaches the internal key, and the pre-0.31.11 gateway default of 'observe' trusts the asserted identity even though the bearer fails verification, letting the attacker act as any organization/member and read that tenant's harnesses. No public POC exists, though the patch's added test suite demonstrates the exact junk-bearer behavior.