Parse Server users: patch immediately. An authenticated attacker with basic find class-level permissions can bypass protectedFields restrictions on LiveQuery subscriptions. This flaw turns real-time updates into a side-channel oracle for leaking sensitive data one bit at a time.
The vulnerability hits LiveQuery, Parse Server’s real-time query subscription system. LiveQuery lets clients subscribe to database changes matching a query, firing events when data matches. Developers use protectedFields class-level permissions to block queries on sensitive columns like user emails, payment info, or internal IDs—even if the user has find access to the class overall.
Attackers exploit this by crafting subscriptions where $or, $and, or $nor operators use “array-like” objects instead of proper arrays. A normal $or looks like {"$or": [{"field": "value1"}, {"field": "value2"}]}. The bypass swaps that for {"$or": {0: {"protectedField": "test"}, 1: {"otherField": "dummy"}, length: 2}}. This plain object mimics an array due to its numeric keys and length property.
Parse Server’s protected-field guard fails to validate the operator value as a true array. It processes the query anyway, evaluating the protected field. If the subscription triggers an event, the attacker knows the test passed. No event? It failed. Repeat with binary search or targeted guesses, and you exfiltrate the full value. Think password hashes, API keys, or PII—anything hidden behind protectedFields.
Scope and Severity
This requires authentication and find permission on the class. No anonymous access. CVSS rates it Medium, likely around 5-6, because it demands privileges but undermines a key security control. Parse Server powers thousands of apps—mobile backends, PWAs, IoT—via Node.js and MongoDB (or Postgres, etc.). LiveQuery appeals to devs wanting Firebase-like realtime without vendor lock-in.
Why it matters: protectedFields exists to enforce data silos. Bypass it, and your access controls crumble. An insider or compromised low-priv account turns into a data dumper. In finance or health apps, this leaks regulated data. Even non-critical apps risk GDPR/CCPA fines if PII escapes. Side-channel leaks scale: automate queries, parallelize, and extract fields fast.
Parse Server’s GitHub advisories (this is one) show a pattern—query parser bugs recur because MongoDB’s query language is flexible and tricky to sandbox. Past vulns include NoSQL injection and RCE; this fits the theme. Users on self-hosted setups (common for privacy-focused Njalla clients) must audit configs—many default to lax class permissions during dev.
Fix and Mitigation
Upgrade to Parse Server 6.5.3 or later (check your version; 6.x is current stable). The patch enforces array validation in three spots: LiveQuery subscription handler, query depth checker, and protected-field guard. Bonus: the query evaluator now rejects non-arrays for these operators, adding defense-in-depth.
npm update parse-server
# Or pin: npm install parse-server@latest
Restart your server. Test LiveQuery subs post-patch to confirm. No workarounds exist—don’t rely on client-side checks. If you’re on managed Parse (like Back4App), they push patches; verify via their dashboard.
Broad lesson: Validate query inputs rigorously. Array-likes fool loose checks everywhere—JavaScript’s duck-typing bites again. Use schema validators like Joi or Zod on queries. Limit LiveQuery to trusted clients via ACLs or IP whitelists. Monitor subscription volumes; spikes signal abuse.
Bottom line: If you use Parse Server with LiveQuery and protected fields, you’re exposed until patched. This isn’t zero-day panic, but ignore it and regret when data walks out via events. Self-hosters, own your stack—audit perms, rotate keys if compromised.
