ApostropheCMS EUVD-2026-105214

Requires an authenticated account holding view-draft access - which every editing (editor/contributor) role has - or, when guestApiAccess is enabled, any logged-in account. The consumer deployment MUST use the @apostrophecms/db-connect SQLite, PostgreSQL, or multipostgres adapter; the default MongoDB adapter is NOT affected and is the primary limiting factor. The attacker also needs a matching document for the piece-type REST query to resolve. Exploitation sends an exclusion projection key traversing constructor.prototype (e.g. constructor.prototype.hasOwnProperty) to the SQL-adapter applyProjection/unsetNestedField path. Limiting factors: authentication is required (no anonymous exploitation unless guestApiAccess is enabled), and the vulnerability does not exist on default MongoDB-backed installations.

Multiple signals converge on a moderate-to-serious availability risk that is conditional on deployment. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, base 7.1) indicates a network-reachable, low-complexity attack requiring only low privilege and no user interaction, with high availability impact, low integrity impact and no confidentiality impact - consistent with the CWE-400 shared-state denial of service described. The privilege bar is genuinely low: every editing role holds view-draft, and enabling guestApiAccess reduces the prerequisite to any logged-in account, so in content-heavy deployments the attacker pool is large. However, exploitation is gated by a non-default backend: only consumers using the @apostrophecms/db-connect SQLite, PostgreSQL, or multipostgres adapters are affected, while the default MongoDB adapter is immune, which materially shrinks the real-world exploitable population. No EPSS score was provided in the input, and there is no CISA KEV listing and no public exploit code referenced, so there is no evidence of active exploitation - this is a high-CVSS issue whose real-world priority depends heavily on whether an organization runs a SQL adapter. The GHSA advisory and commit-level source evidence confirm the root cause and fix, so the technical claims are well substantiated even though exploitation-in-the-wild indicators are absent.

A low-privileged but authenticated user (any editor/contributor with view-draft, or any logged-in user if guestApiAccess is enabled) on an ApostropheCMS site backed by the db-connect SQLite or PostgreSQL adapter sends a single piece-type REST GET request whose projection contains an exclusion key such as constructor.prototype.hasOwnProperty. The unsetNestedField helper walks the unvalidated dotted path to Object.prototype and deletes a shared runtime method, breaking request handling for every tenant and user until the process is restarted. No public exploit identified at time of analysis, though the GHSA advisory documents the exact exploit string.