This vulnerability represents a fundamental inversion of the trust model that Hasura's proxy architecture is designed to enforce. When a service accepts session_variables from the client-supplied JSON body rather than relying solely on Hasura-validated JWT claims, it breaks the core security contract: Hasura validates identity and forwards trusted session variables; downstream services consume them without re-validation. This server does the opposite — it actively prefers attacker-controlled input when available.
The word 'prefers' in the CVE description matters more than it first appears. This isn't a passive failure to check JWT claims — the code explicitly selects untrusted body data as authoritative over authenticated credentials. That pattern almost always emerges from accumulated convenience: a development shortcut for local testing, a webhook integration that couldn't speak Hasura's native auth, an integration test that needed to bypass the full auth flow. Each decision was reasonable in isolation. The aggregate is a back door.
What should concern you most is the absence of any origin verification. Proper Hasura integration typically involves shared secrets, IP allowlisting, or explicit headers to confirm requests passed through the proxy layer. This system has none of that — it was built without a threat model for the proxy layer entirely. That means reaching this server directly (through misconfigured development environments, staging deployments, or internal service-to-service calls) is enough to exploit it, even if your Hasura production endpoint is locked down.
The CVSS 9.8 is technically accurate but masks an important nuance: the EPSS of 0.00336 suggests this specific configuration rarely survives in production Hasura deployments. This vulnerability likely lives in development paths, test endpoints, or internal services that were never properly hardened. Check your non-production environments first — the odds of active exploitation are low, but the exposed surface is probably larger than you think.
Audit any service that accepts session_variables from request bodies or headers and forward them downstream. Remove that capability unless you can implement cryptographic verification that the variables originated from Hasura. The secure path must become the default — if proper integration remains friction-heavy, the next team will find the next convenient shortcut.