ApostropheCMS CVE-2026-113653

Exploitable only when a developer has exposed user objects to anonymous visitors - specifically through a publicly rendered relationship OR an expressly enabled public API - AND uses inadequately limited templates that serialize the entire related user object. This is explicitly NOT a default configuration: relationships do not automatically publish full user objects, so a vanilla install is not affected. Limiting factors: disclosure is conditional on these developer choices, is read-only, and password hashes are stored separately and never disclosed. Where the exposure exists, no authentication is required (CVSS PR:N) and attack complexity is low.

This is a broken-access-control / improper-authorization issue (CWE-863) in ApostropheCMS where viewRole is not enforced for anonymous visitors when a developer has deliberately exposed user objects through a publicly rendered relationship or an expressly enabled public API. The input provides only a CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L, base 6.9) indicating unauthenticated network reach with low complexity - but the impact claim is internally inconsistent with the description, which describes ONLY conditional disclosure of user fields (a confidentiality concern), with no integrity or availability effect; the VI:L/VA:L metrics appear overstated and should be treated as confidentiality-only. No EPSS score, no CISA KEV listing, and no POC were supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Crucially, exploitation is NOT a default-configuration flaw: the description explicitly states relationships do not automatically publish full user objects and that disclosure is 'conditional' on a developer exposing users and using inadequately limited templates. This materially lowers real-world risk below what the 6.9 'medium-high' score suggests - it is a conditional info-leak dependent on specific developer choices, and password hashes are explicitly unaffected. Treat as a real but situational data-exposure issue, not a broadly exploitable priority.

In a site where a developer has published a relationship or enabled a public API that serializes an entire related user object, an anonymous attacker simply requests the rendered page or public API endpoint and reads user fields (e.g., usernames, emails, profile metadata) that viewRole should have restricted. No authentication or user interaction is needed given AV:N/PR:N/UI:N, but the attack only works where that exposure has been configured. No public exploit code was identified at time of analysis.