CVE-2026-31871: 
JavaScript vulnerability analysis and mitigation

CVE-2026-31871 is a critical SQL injection vulnerability in Parse Server's PostgreSQL storage adapter, titled "SQL Injection via dot-notation sub-key name in Increment operation on PostgreSQL." It affects Parse Server (npm) versions before 8.6.31 and versions 9.0.0 through before 9.6.0-alpha.5 running on PostgreSQL backends. The vulnerability was published on March 10, 2026, by maintainer mtrezza, with NVD publication on March 11, 2026. It carries a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory, Github Advisory).

The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). When Parse Server processes an Increment operation on a nested object field using dot notation (e.g., stats.counter), the sub-key name component is interpolated directly into SQL string literals without sanitization or escaping. An attacker can craft a sub-key name containing single quotes to break out of the SQL string literal context and inject arbitrary SQL commands. No authentication, special privileges, or user interaction is required — any party able to send write requests to the Parse Server REST API can trigger the vulnerability. Only PostgreSQL deployments are affected; MongoDB-backed deployments are not impacted (GitHub Advisory).

Successful exploitation allows an unauthenticated attacker to execute arbitrary SQL commands against the underlying PostgreSQL database, with full confidentiality, integrity, and availability impact. Attackers can read sensitive data from the database, modify or delete records, and potentially execute operating system commands via database features (e.g., COPY TO/FROM, extensions), effectively bypassing all Parse Server Class-Level Permissions (CLPs) and Access Control Lists (ACLs). This could lead to complete data exfiltration, unauthorized data manipulation, and potential lateral movement to other systems accessible from the database host (GitHub Advisory, Github Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.042% (13th percentile), indicating a currently low probability of exploitation within 30 days (Github Advisory). However, the zero-authentication requirement and network accessibility make this vulnerability highly attractive for future exploitation once details become more widely known.

1. Reconnaissance: Identify internet-facing Parse Server instances configured with a PostgreSQL backend using tools like Shodan or Censys, or by probing the REST API endpoint for version indicators.
2. Identify a writable class: Determine a Parse Server class (table) that allows write access via the REST API — this may be an open class with permissive CLPs, or any class if the attacker has any level of API access.
3. Craft a malicious Increment payload: Construct a REST API write request (e.g., PUT or POST) targeting an object with a nested field using dot notation. Embed a SQL injection payload in the sub-key name, for example: {"stats.counter'--": {"__op": "Increment", "amount": 1}} or a more complex payload using single quotes to break out of the SQL string literal.
4. Send the request: Submit the crafted HTTP request to the Parse Server REST API endpoint (e.g., PUT /1/classes/MyClass/<objectId>) with the malicious sub-key name in the JSON body.
5. Execute arbitrary SQL: The unescaped sub-key is interpolated into the PostgreSQL query, allowing the injected SQL to execute — enabling data exfiltration (SELECT), data modification (UPDATE/DELETE), or potentially command execution via PostgreSQL extensions.
6. Exfiltrate or manipulate data: Use error-based, union-based, or time-based blind SQL injection techniques to extract sensitive data or modify database contents, bypassing all CLP and ACL controls (GitHub Advisory).

• Network: Unexpected or anomalous HTTP PUT/POST requests to Parse Server REST API endpoints (e.g., /1/classes/<ClassName>/<objectId>) containing unusual characters such as single quotes ('), SQL keywords (SELECT, UNION, DROP, INSERT, --), or encoded variants in field/key names.
• Logs: Parse Server application logs showing malformed or unexpected field names in Increment operations; PostgreSQL query logs (pg_log) containing SQL syntax errors or unusual query structures originating from Parse Server's database user, particularly in UPDATE statements involving JSONB or nested field paths.
• Database: Unexpected data modifications, new database objects (tables, functions, extensions), or evidence of data exfiltration queries in PostgreSQL audit logs; unusual use of PostgreSQL functions like pg_read_file, COPY, or dblink by the Parse Server database role.
• Process: Unexpected child processes spawned from the PostgreSQL server process (if OS command execution via database extensions is achieved).

Parse Server has released patched versions addressing this vulnerability: 8.6.31 for the 8.x branch and 9.6.0-alpha.5 for the 9.x branch. The fix escapes single quotes in the sub-key name before interpolating it into the SQL query, preventing SQL string literal breakout. There is no known configuration-based workaround — upgrading is the only remediation. As an interim measure, restricting network access to the Parse Server REST API to trusted sources only and monitoring PostgreSQL query logs for suspicious patterns is recommended (GitHub Advisory, Parse Server 8.6.31, Parse Server 9.6.0-alpha.5).

The vulnerability was reported and coordinated by Parse Server maintainer mtrezza, who also published the security advisory on March 10, 2026. The advisory received standard community attention via automated CVE tracking feeds and vulnerability aggregators such as CIRCL and GCVE. No significant independent researcher commentary or major media coverage has been identified beyond routine CVE publication and tracking (Github Advisory).