CVE-2026-30925

Workarounds

Use the beforeSubscribe Cloud Code hook to reject any LiveQuery subscription that contains a $regex operator. Note that this also blocks the LiveQuery startsWith, endsWith, and contains query methods, as they use $regex internally.

// Repeat for each class that is used with LiveQuery
Parse.Cloud.beforeSubscribe('MyClass', request => {
  const where = request.query._where || {};
  for (const value of Object.values(where)) {
    if (value?.$regex) {
      throw new Parse.Error(Parse.Error.OPERATION_FORBIDDEN, '$regex not allowed in LiveQuery subscriptions');
    }
  }
});

References

• GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mf3j-86qx-cq5j
• Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.14
• Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.11

A malicious client can subscribe to a LiveQuery with a crafted $regex pattern that causes catastrophic backtracking, blocking the Node.js event loop. This makes the entire Parse Server unresponsive, affecting all clients. Any Parse Server deployment with LiveQuery enabled is affected. The attacker only needs the application ID and JavaScript key, both of which are public in client-side apps.

This only affects LiveQuery subscription matching, which evaluates regex in JavaScript on the Node.js event loop. Normal REST and GraphQL queries are not affected because their regex is evaluated by the database engine.

A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.

Kodem intelligence

Regex evaluation in LiveQuery subscription matching now runs in an isolated VM context with a configurable timeout via a new Parse Server option `liveQuery.regexTimeout, with defaults 100 ms. A regex that exceeds the timeout is treated as non-matching.

The protection adds approximately 50 microseconds of overhead per regex evaluation. For most applications this is negligible, but it can add up if there is a very large number of LiveQuery subscriptions that use $regex on the same class. For example, 10,000 concurrent regex subscriptions would add approximately 500ms of processing time per object save event on that class. Set liveQuery.regexTimeout: 0 to disable the protection and use native regex evaluation without overhead.

1. What is CVE-2026-30925? CVE-2026-30925 is a high-severity inefficient regular expression (ReDoS) vulnerability in parse-server (npm), affecting versions >= 9.0.0-alpha.1, < 9.5.0-alpha.14. It is fixed in 9.5.0-alpha.14, 8.6.11. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
2. Which versions of parse-server are affected by CVE-2026-30925? parse-server (npm) versions >= 9.0.0-alpha.1, < 9.5.0-alpha.14 is affected.
3. Is there a fix for CVE-2026-30925? Yes. CVE-2026-30925 is fixed in 9.5.0-alpha.14, 8.6.11. Upgrade to this version or later.
4. Is CVE-2026-30925 exploitable, and should I be worried? Whether CVE-2026-30925 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-30925 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-30925?
   • Upgrade parse-server to 9.5.0-alpha.14 or later
   • Upgrade parse-server to 8.6.11 or later

Other vulnerabilities in parse-server