CVE-2026-113653 in ApostropheCMS
Summary
by MITRE • 10/20/2026
ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, viewRole is not applied to anonymous visitors when a developer exposes user objects through a publicly rendered relationship or expressly enabled public API. Inadequately limited templates, including serialization of an entire related user object, can conditionally disclose user fields, but relationships do not automatically publish full user objects and password hashes are stored separately and are not affected. This issue is fixed in version 4.33.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
ApostropheCMS is a widely utilized open-source content management system built on the Node.js platform, designed to facilitate flexible website creation and maintenance. A significant security vulnerability was identified within versions prior to 4.33.0 concerning how access control policies are enforced for anonymous users interacting with exposed data relationships. The core issue stems from an inadequate implementation of role-based access controls when developers expose user objects through publicly rendered relationships or expressly enabled public APIs. In these specific scenarios, the viewRole permission check is not correctly applied to anonymous visitors, leading to a potential information disclosure vulnerability where sensitive user attributes may be inadvertently revealed to unauthenticated parties.
The technical flaw arises from how ApostropheCMS handles serialization of related entities within its API layer. When a developer configures a relationship that includes user objects and renders this data publicly, the system fails to strictly enforce the viewRole restrictions for anonymous sessions. This allows templates or API responses to conditionally disclose fields associated with user profiles that should remain restricted. While the vulnerability is conditional on specific development choices regarding public exposure of relationships, it represents a critical lapse in default security expectations for content management systems where data isolation between authenticated and unauthenticated contexts is paramount. The flaw aligns with CWE-200, which categorizes this as an Information Exposure vulnerability, specifically involving sensitive information being accessible to unauthorized actors due to improper access control enforcement.
The operational impact of this vulnerability depends heavily on the specific configuration of the ApostropheCMS instance and the data exposed through public APIs or rendered relationships. If a developer exposes user objects without proper filtering, anonymous users could potentially retrieve personal identifiable information such as usernames, email addresses, profile descriptions, or other metadata associated with those accounts. This exposure can facilitate further attacks, including social engineering campaigns, credential stuffing attempts if combined with other leaked data, or reconnaissance activities that aid in targeting specific individuals within the system's user base. However, it is important to note that password hashes are stored separately and are not affected by this vulnerability, meaning direct account compromise via hash extraction is not a direct consequence of this flaw alone. The risk is mitigated by the fact that relationships do not automatically publish full user objects unless explicitly configured to do so by the developer, making exploitation dependent on specific misconfigurations rather than a universal system failure.
To address this vulnerability and ensure secure operation, organizations running ApostropheCMS must upgrade immediately to version 4.33.0 or later, where the viewRole enforcement for anonymous visitors has been corrected in publicly rendered relationships and public APIs. For environments that cannot yet be upgraded, administrators should review their API configurations and template structures to ensure that no user objects are exposed through public endpoints without rigorous filtering of sensitive fields. Developers must adhere to the principle of least privilege by explicitly defining which roles can view specific data attributes and ensuring that anonymous access is restricted to non-sensitive information only. Additionally, implementing robust input validation and output encoding practices will help mitigate broader risks associated with API exposure. Regular security audits focusing on role-based access control implementations are recommended to prevent similar misconfigurations in custom modules or extensions integrated into the CMS ecosystem. This incident underscores the importance of rigorous testing of public-facing APIs against unauthenticated access scenarios, aligning with ATT&CK techniques related to Collection and Exfiltration over alternative protocols if such exposure were exploited for data theft purposes.