ApostropheCMS EUVD-2026-105170

Requires an authenticated account with at least editor-level privileges on the ApostropheCMS instance, plus knowledge of the specific document _id of an admin-only page. Exploitation targets the getOne pages REST endpoint specifically; the getAll endpoint is not vulnerable because it correctly applies viewRole type-level restrictions and viewPermission field-level redaction. Only instances running versions prior to 4.34.0 that actually use viewRole/viewPermission to restrict admin-only pages or privileged fields from editors are exposed; installations where editors are already trusted with that content, or that have upgraded to 4.34.0, are not meaningfully affected. No user interaction is needed, but the editor-account and known-_id prerequisites are the primary limiting factors.

This is a broken-access-control / missing-authorization flaw (CWE-862), not an authentication bypass despite the input tag. The provided CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (base 4.3, Medium) is internally consistent with the description: exploitation is network-reachable (REST endpoint) but requires an authenticated editor-level account (PR:L) and yields only a confidentiality impact (C:L, I:N, A:N) - the attacker reads admin-only page content and privileged fields but cannot modify or deny service. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no signal of active or probable exploitation; absence of these is expected for a freshly disclosed, medium-severity info-disclosure bug and should not be read as suppression. This is a genuine but bounded privilege-escalation-of-read issue: real priority only for deployments that rely on viewRole/viewPermission to hide admin-only pages from editors, and a lower priority elsewhere. The limiting factors (trusted-but-lower-privilege account required, attacker must already know a target document _id) make widespread opportunistic exploitation unlikely; the realistic threat is an insider or a compromised editor account.

An authenticated editor-level user - or an attacker who has phished/compromised such an account - discovers or guesses the _id of an admin-only page and calls the getOne pages REST endpoint directly. Because getOne skips the viewRole type-level check and viewPermission field-level redaction that getAll enforces, the response discloses the full content of the restricted page including privileged fields. No public exploit code is identified at time of analysis.