CVE-2021-47714: 
Hasura vulnerability analysis and mitigation

CVE-2021-47714 is a local file read vulnerability in Hasura GraphQL Engine version 1.3.3 that allows attackers to access arbitrary system files through SQL injection at the query endpoint. The vulnerability was assigned by VulnCheck and published on December 22, 2025. It affects only Hasura GraphQL Engine version 1.3.3. It carries a CVSS v3.1 base score of 5.5 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (Red Hat Advisory, VulnCheck Advisory).

The root cause is improper neutralization of special elements used in SQL commands (CWE-89 — SQL Injection). Attackers exploit the PostgreSQL pg_read_file() function by injecting malicious SQL into the Hasura GraphQL query endpoint, bypassing input validation to read arbitrary files from the server's filesystem. The attack vector is local (requiring local access or authenticated API access), with low attack complexity and no user interaction required. A proof-of-concept exploit is publicly available on Exploit-DB (Exploit-DB PoC, VulnCheck Advisory).

Successful exploitation allows an attacker to read arbitrary files on the server hosting Hasura GraphQL Engine, potentially exposing sensitive configuration files, credentials, private keys, and other confidential system data. The confidentiality impact is rated High, while integrity and availability are unaffected. Exposed credentials or configuration data could facilitate lateral movement or privilege escalation within the broader environment (VulnCheck Advisory, Red Hat Advisory).

A public proof-of-concept exploit is available on Exploit-DB (EDB-49790), and VulnCheck has published an advisory for this vulnerability. There is no confirmed evidence of active in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.019% (very low probability of exploitation in the near term), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Exploit-DB PoC, VulnCheck Advisory).

1. Reconnaissance: Identify instances of Hasura GraphQL Engine version 1.3.3 exposed via network or locally accessible endpoints, using tools like Shodan, Censys, or direct API probing.
2. Access the query endpoint: Connect to the Hasura GraphQL query endpoint (typically /v1/graphql or /v1/query) with appropriate credentials or API keys if required.
3. Craft malicious SQL payload: Construct a GraphQL query that passes a raw SQL statement leveraging the PostgreSQL pg_read_file() function, e.g., targeting sensitive files such as /etc/passwd or application configuration files.
4. Inject and execute: Submit the crafted query to the endpoint; the insufficient input validation allows the SQL to execute against the underlying PostgreSQL database.
5. Retrieve file contents: The response from the server returns the contents of the targeted file, exposing credentials, configuration data, or other sensitive information (Exploit-DB PoC, VulnCheck Advisory).

• Network: Unusual or repeated GraphQL POST requests to /v1/graphql or /v1/query endpoints containing SQL keywords such as pg_read_file, SELECT, or file path strings (e.g., /etc/passwd, /etc/shadow).
• Logs: Hasura server logs or PostgreSQL query logs showing invocations of pg_read_file() with arbitrary file paths; unexpected SQL queries originating from the GraphQL layer.
• Database: PostgreSQL audit logs recording pg_read_file() calls with file paths outside normal application scope.
• Application: Anomalous API responses containing file content (e.g., Unix password file format, configuration key-value pairs) returned to clients.

The primary remediation is to upgrade Hasura GraphQL Engine from version 1.3.3 to a later patched release; no specific fixed version number is cited in available advisories, so users should upgrade to the latest stable version available on the Hasura GitHub repository. As interim mitigations: implement strict input validation for all SQL queries, use parameterized queries to prevent injection, restrict database user permissions to limit pg_read_file() access, enable database-level access controls, and regularly audit database query logs for anomalous activity (VulnCheck Advisory, Red Hat Advisory).