[Vulnerability] parse-community/parse-server: SQL Injection

[github-actions]

Potential Security Vulnerability Detected

Repository: parse-community/parse-server
Commit: 169d692
Author: Manuel
Date: 2026-03-10T00:59:42Z

Commit Message

fix: SQL Injection via dot-notation sub-key name in `Increment` operation on PostgreSQL ([GHSA-gqpp-xgvh-9h7h](https://github.com/parse-community/parse-server/security/advisories/GHSA-gqpp-xgvh-9h7h)) (#10165)

Pull Request

PR: #10165 - fix: SQL Injection via dot-notation sub-key name in Increment operation on PostgreSQL (GHSA-gqpp-xgvh-9h7h)
Labels: state:released-alpha

Description:

Pull Request

• Report security issues [confidentially](https://github.com/parse-community/parse-server/security/policy).
• Any contribution is under this [license](https://github.com/parse-community/parse-server/blob/alpha/LICENSE).

Issue

SQL Injection via dot-notation sub-key name in Increment operation on PostgreSQL ([GHSA-gqpp-xgvh-9h7h](GHSA-gqpp-xgvh-9h7h))

Tasks

<!-- Check completed tasks and delet...

Analysis

Vulnerability Type: SQL Injection
Severity: High

Description

The patch fixes a SQL Injection vulnerability in the PostgreSQL adapter triggered via the dot-notation sub-key name used in Increment operations. Before the fix, attacker-controlled sub-keys were interpolated directly into SQL strings without proper escaping, allowing injection of malicious SQL code (e.g., pg_sleep) that could lead to denial of service or more severe exploits. The patch properly escapes single quotes in sub-key names, preventing arbitrary SQL execution.

Affected Code

return `CONCAT('{"${c}":', COALESCE($${index}:name->>'${c}','0')::int + $${amountIndex}, '}')::jsonb`;

Proof of Concept

HTTP PUT request to update object with body:
{
  "stats.x' || (SELECT pg_sleep(3))::text || '": { "__op": "Increment", "amount": 1 }
}

Expected behavior before patch: the query would sleep for 3 seconds indicating successful SQL injection and arbitrary SQL execution.
After patch: the payload is safely escaped and treated as a literal key; no delay occurs and no SQL is injected.

---

This issue was automatically created by Vulnerability Spoiler Alert.
Detected at: 2026-03-10T06:01:16.319Z