CVE-2026-112957 in ApostropheCMS
Summary
by MITRE • 10/20/2026
ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions. This issue is fixed in version 4.34.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
ApostropheCMS is an open-source content management system built on Node.js that allows organizations to manage digital assets and web content through a structured interface. The platform relies heavily on role-based access control mechanisms, including viewRole for type-level restrictions and viewPermission for field-level redaction, to ensure that sensitive information remains accessible only to authorized personnel. These security controls are critical for maintaining data integrity and confidentiality within enterprise environments where different user tiers such as editors, administrators, and viewers have distinct permissions regarding content visibility and modification.
A significant vulnerability was identified in the getOne REST endpoint prior to version 4.34.0 of ApostropheCMS. This specific API method is designed to retrieve a single document based on its unique identifier, commonly referred to as _id. The flaw lies in the fact that this endpoint fails to enforce viewRole type-level restrictions or viewPermission field-level redaction rules when processing requests for pages marked with admin-only visibility settings. Consequently, an attacker possessing editor-level privileges who also knows the specific _id of a restricted document can bypass standard access controls and retrieve the full content of those documents. This behavior stands in stark contrast to the getAll endpoint, which correctly implements these security restrictions and filters out unauthorized data appropriately.
The operational impact of this vulnerability is substantial because it allows for information disclosure that undermines the intended separation of duties within the CMS. An editor-level user typically has permissions to create and modify standard content but should not have access to administrative configurations or sensitive internal documents reserved for higher-privilege accounts. By exploiting the getOne endpoint, an attacker can read privileged fields and admin-only page contents without triggering any authentication errors or authorization failures. This could lead to the exposure of confidential business logic, internal URLs, API keys embedded in content, or other sensitive data that was intended to be hidden from lower-tier users.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper access control levels for different user roles and resource types. It also maps to the ATT&CK technique T1078 Valid Accounts, as it involves leveraging legitimate but insufficiently restricted credentials to access resources beyond their intended scope. The root cause is likely an inconsistency in how the API layer applies middleware or permission checks across different endpoints within the same module. While the getAll endpoint correctly filters results based on user permissions, the getOne endpoint bypasses these checks entirely when a valid _id is provided, assuming that possession of the identifier implies authorization to view the content.
To mitigate this risk, organizations using ApostropheCMS must upgrade immediately to version 4.34.0 or later where the issue has been resolved. Until an update can be applied, administrators should consider implementing additional network-level controls such as Web Application Firewalls that monitor for unusual patterns of document retrieval by editor accounts. It is also advisable to review audit logs for any instances where editors accessed admin-only pages prior to patching. Furthermore, developers should ensure that all REST endpoints consistently apply the same permission checking logic regardless of whether they are retrieving single items or collections, thereby preventing similar inconsistencies in other parts of the application architecture.