The vulnerability arises because the GraphQL engine allows a "where" clause on a computed field that returns related table rows to act as a side‑channel. An attacker can craft queries that, while not retrieving the actual row data, force the engine to evaluate predicates that reveal whether a particular row satisfies the predicate under the current role’s row‑level security filters. This effectively turns the computed field into an oracle that can be brute‑forced to learn which rows a role is authorized to see, thereby leaking confidential information that should otherwise be hidden. The issue is a logical fault related to access control (CWE-863) and is considered moderate in severity, with an EPSS score of <1% indicating a low probability of exploitation at this time.

All installations of Hasura GraphQL Engine earlier than release 2.49.2 and 2.45.5 are affected. The flaw impacts every role that has permission to read the vulnerable computed field, regardless of the underlying table’s own permissions. The issue is specific to computed fields returning a set of rows from another table.

The CVSS score of 6 classifies the logical fault as medium severity, and the EPSS score of less than 1% indicates a very low probability that an attacker will exploit the flaw in the near term. Because it is not listed in the CISA KEV catalog, this vulnerability is not currently tied to known active exploits. Attackers would use the public GraphQL endpoint to send specially crafted queries that include a where clause against a computed field, turning it into a side‑channel that reveals which rows satisfy the row‑level security policy. The technique requires only network access to the exposed GraphQL API and an understanding of the schema, making it potentially feasible in environments where the API is reachable from the internet or from untrusted networks.