CVE-2026-110854

Executive Summary

CVE-2026-110854 is an uncaught exception vulnerability in Parse Server that allows an unauthenticated client — holding only the public application keys — to crash the Node.js server process by triggering error conditions in outbound email flows. Affected deployments are Parse Server versions before 8.6.97 and 9.0.0 through 9.10.2-alpha.6. Because any anonymous client can induce a full process exit, the flaw is a low-complexity remote denial-of-service (DoS) primitive against public-facing Parse backends.

Technical Analysis

Parse Server is an open-source Node.js backend (the server component of the Parse Platform) that exposes REST and GraphQL-style APIs to client applications. The NVD description states that the server "does not handle errors raised while sending verification or password reset emails, causing the server process to exit." This maps directly to CWE-248 (Uncaught Exception).

The attack surface involves two publicly reachable workflows: user sign-up (which can dispatch a verification email) and password reset requests (which dispatch a reset email). Both are routinely exposed to unauthenticated callers by design — a prospective user has only the public application keys (application ID and JavaScript key/client key), which are embedded in client applications and are not secrets. When these workflows hand off message delivery to the configured mail provider, transient or persistent mail-side failures can occur, including:

• Provider rejection of the message (bounce, blocklist, invalid configuration),
• Provider rate limiting / throttling, or
• Provider unavailability (timeout, connection refused, outage).

The described defect is that the resulting error from the mail-sending path is not caught (no try/catch wrapping an awaited/rejected promise, or no .catch() on the email-send promise — the description does not name specific functions). In Node.js, an unhandled promise rejection or uncaught exception on the main event loop terminates the process by default. Consequently, the error raised during email delivery propagates to the top of the process and the server exits, rather than returning a handled error to the caller. The key insight is that the server's process lifecycle is coupled to the downstream mail provider's behavior — an external dependency failure becomes a self-inflicted availability incident.

No public proof-of-concept exists and the NVD description does not disclose the specific internal function names, mail-send wrapper, or error-handling code paths, so the precise code location cannot be cited without invention. The vulnerability class (uncaught exception → process exit) is nonetheless well understood.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (uncaught exception / CWE-248) and the behavior described in the NVD text. Only the endpoints conceptually described (sign-up, verification email, password reset) are referenced; no invented routes or parameters are used.

1. Reconnaissance / target identification. An attacker identifies a publicly reachable Parse Server instance. Public application keys are, by design, extractable from any client application that talks to that backend (mobile/Web apps embed the application ID and client key). No credential compromise is required. Attackers can fingerprint Parse deployments via server headers, GraphQL/REST behavior, or Shodan using the dorks above.

2. Triggering the flawed code path. The attacker submits a sign-up request, a verification-email request, or a password-reset request using only the public keys. The server enters the email-sending workflow. Critically, the attacker can also condition the environment to make mail delivery fail: repeatedly consuming the mail provider's rate limit with bulk requests, or simply waiting for / inducing provider unavailability or rejection. The description explicitly enumerates "mail provider rejects, rate limits, or is unavailable" as the failure conditions that surface the unhandled error.

3. Payload / execution method (vulnerability-class level). The "payload" is not exploit code but a protocol-valid request that drives the server into the email dispatch path while that path is in a failing state. When the mail provider errors, the unexpected rejection/exception is not caught, and the Node.js process exits. An attacker can sustain this by issuing repeated requests; each mail-provider failure that coincides with a request results in a process termination.

4. Post-exploitation impact. The outcome is denial of service: the server process exits, taking down the Parse API for all tenants and users on that instance until it is restarted (and, in some deployments, until mail configuration is corrected). Because the trigger is trivial and unauthenticated, low-skill actors — including accidental self-inflicted triggers by legitimate users during a mail outage — can cause outages. Repetition yields sustained unavailability (availability impact rated High in the derived vector).

Impact Assessment

The primary impact is availability. Using the standard CVSS v3.1 vector derived from the description — AV:N (network), AC:L (the failure condition is controllable via bulk requests or occurs naturally), PR:N (public keys only, no privileges), UI:N (no user interaction), S:U, C:N/I:N/A:H — the qualitative severity is High for availability, with no confidentiality or integrity impact demonstrated by the description.

Blast radius: a single Parse Server process typically serves an entire application backend; its exit disrupts all API consumers for that deployment, not just the requesting client. Business impact includes application downtime, failed authentications, lost writes during the outage window, and operational cost of restarts/monitoring. Secondary risk: if the deployment runs behind a process manager without timely restart, or if restarts cascade, downtime extends. Multi-tenant or shared Parse instances amplify the impact across all dependent applications. The low EPSS score (0.00263, ~16.8th percentile) suggests no observed mass exploitation, but the low complexity and lack of authentication prerequisites make it an attractive nuisance for DoS-focused actors.

No CVSS score or vector was provided in the CVE data; the vector above is a reasoned derivation from the description, not an authoritative assignment.

Detection Guidance

Sigma Rule

title: Parse Server Process Exit Following Email Send Failure (CVE-2026-110854)
id: 6f2c1a90-3b7e-4d21-9c55-cve2026110854
status: experimental
description: Detects Parse Server process termination correlated with mail-provider errors during signup/verification/password-reset email dispatch.
logsource:
  product: linux
  service: syslog
detection:
  keywords_mail:
    - 'mail'
    - 'smtp'
    - 'sendmail'
    - 'email'
  keywords_error:
    - 'ECONNREFUSED'
    - 'ETIMEDOUT'
    - 'rate limit'
    - 'rate-limit'
    - '429'
    - 'rejected'
    - 'unhandled'
    - 'UnhandledPromiseRejection'
  keywords_exit:
    - 'Parse Server'
    - 'parse-server'
  condition: keywords_mail and keywords_error and keywords_exit
fields:
  - host
  - process
  - message
falsepositives:
  - Planned maintenance of the mail provider coinciding with a restart
  - Legitimate SMTP outages with no attacker involvement
level: medium
tags:
  - attack.t1499
  - cve.2026.110854

YARA Rule

rule CVE_2026_110854_ParseServer_EmailUncaughtException
{
    meta:
        author = "Threat Intelligence"
        description = "Detects Parse Server source/config referencing unhandled email send paths associated with CVE-2026-110854"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-110854"
        cve = "CVE-2026-110854"
        date = "2026-01-01"

    strings:
        $p1 = "parse-server" nocase
        $m1 = "passwordReset" nocase
        $m2 = "verification" nocase
        $m3 = "sendMail" nocase
        $m4 = "mailProvider" nocase
        $e1 = "UnhandledPromiseRejection" nocase
        $e2 = "ECONNREFUSED" nocase

    condition:
        $p1 and (2 of ($m*)) and (1 of ($e*))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-110854 Parse Server email-triggered DoS attempt (repeated signup/password-reset)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/"; pcre:"/(requestPasswordReset|verification|signup|users)/Ui"; threshold:type both, track by_src, count 30, seconds 60; classtype:attempted-dos; reference:cve,2026-110854; sid:2026110854; rev:1;)

Elastic Detection

sequence by process.entity_id with maxspan=30s
  [process where process.name in ("node","nodejs") and process.args : "*parse*"]
  [process where event.type == "end" and process.exit_code != 0]

Splunk SPL Query

index=app_logs (sourcetype=nodejs OR sourcetype=parse-server)
| search ("Parse Server" OR "parse-server")
| search ("UnhandledPromiseRejection" OR "uncaughtException" OR "ECONNREFUSED" OR "ETIMEDOUT" OR "rate limit" OR "429")
| stats count min(_time) as first_seen max(_time) as last_seen by host, process, message
| where count >= 1

Wazuh OSSEC Rule

<group name="parse_server,cve_2026_110854,">
  <rule id="1108540" level="10" frequency="2" timeframe="120">
    <decoded_as>syslog</decoded_as>
    <match>parse-server|Parse Server</match>
    <regex>UnhandledPromiseRejection|uncaughtException|ECONNREFUSED|ETIMEDOUT|429</regex>
    <description>CVE-2026-110854: Parse Server email send failure leading to possible process exit</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 2/4 (CLAIMED via a single OSV source; not independently confirmed). Treat patch status as unverified until a vendor advisory or code-level fix is confirmed.

1. Immediate mitigations. Enforce a process supervisor that aggressively restarts the Parse Server process (systemd Restart=always, PM2/Kubernetes restart policies) to bound downtime. Apply rate limiting and abuse controls on sign-up, verification-email, and password-reset endpoints to constrain the ability to drive the mail path into failure. Harden the mail provider relationship: use a provider with high rate limits/retries, a transactional queue, and alerting on send failures. Where possible, move email dispatch to an asynchronous worker/queue so an external mail failure cannot propagate to the API process.

2. Patch / upgrade steps. Upgrade Parse Server to 8.6.97 or later on the 8.x line, or to 9.10.2-alpha.6 or later on the 9.x line, per the OSV-sourced fix. Because the fix is only claim-verified, validate by deploying to a staging environment, confirming the email error path no longer terminates the process (e.g., simulate provider failure), and only then rolling to production. Track the upstream Parse Server changelog/release notes for the official advisory.

3. Long-term hardening. Add global process.on('unhandledRejection') / uncaughtException handling with logging and graceful degradation where safe. Wrap all external I/O (SMTP, HTTP mail APIs) in explicit error handling with bounded retries, timeouts, and circuit breakers. Adopt dependency-outage resilience testing (chaos testing of the mail provider). Monitor process exits as a first-class availability signal and alert on restart loops.

References

• NVD — CVE-2026-110854: https://nvd.nist.gov/vuln/detail/CVE-2026-110854
• OSV advisory entry (patch source): https://osv.dev/ (search CVE-2026-110854)
• Parse Server project / release notes (verify fixed versions 8.6.97 and 9.10.2-alpha.6): https://github.com/parse-community/parse-server/releases
• CWE-248 — Uncaught Exception: https://cwe.mitre.org/data/definitions/248.html
• CISA KEV catalog — not listed for this CVE: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No exploit-in-the-wild, threat actor campaign, or public PoC evidence was identified in the provided data.