CVE-2026-112952 in ApostropheCMS
Summary
by MITRE • 10/20/2026
ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, 'POST /api/v1/@apostrophecms/doc/slugTaken' with body { "slug": "target-slug" } returns a boolean indicating whether a slug is in use across all document types and visibility levels, with no permission or type filter. Any logged-in user (including editors) can enumerate the slug space of private pages, drafts, and archived content. This issue is fixed in version 4.34.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
ApostropheCMS serves as a robust open-source content management system built on Node.js, designed to facilitate digital asset creation and publishing for organizations ranging from small businesses to large enterprises. Within this ecosystem, the integrity of access controls is paramount to ensuring that sensitive or unpublished content remains restricted to authorized personnel only. The vulnerability identified in versions prior to 4.34.0 represents a critical failure in authorization logic within the API layer, specifically affecting the endpoint responsible for checking slug availability during page creation or modification processes.
The technical flaw resides in the implementation of the POST /api/v1/@apostrophecms/doc/slugTaken endpoint. This function is intended to verify whether a specific URL slug is already occupied by another document to prevent conflicts and ensure unique URLs. However, the underlying logic fails to enforce proper permission checks or filter results based on document visibility levels such as published, draft, private, or archived states. Consequently, when an authenticated user submits a request with a target-slug parameter, the system returns a boolean value indicating whether that slug exists anywhere in the database, regardless of who owns the content or its current publication status. This lack of contextual filtering means the API does not distinguish between public-facing pages and internal-only documents.
The operational impact of this vulnerability is significant information disclosure leading to potential further exploitation by any logged-in user, including those with lower privilege levels such as editors. An attacker can systematically enumerate the slug space used across all document types. By iterating through common words or known identifiers, an adversary can determine which slugs are in use and infer the existence of private pages, unpublished drafts, or archived content that should not be visible to them. This enumeration capability effectively bypasses intended access controls, allowing unauthorized users to map out the internal structure of the CMS, identify potential targets for further attacks such as cross-site scripting on draft pages, or simply gain intelligence about the organization's digital footprint and operational workflows.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically where a user is able to access information that they are not authorized to view due to flawed authorization logic. Furthermore, from an offensive security perspective as defined by MITRE ATT&CK, this behavior facilitates the Discovery phase of an attack lifecycle, particularly under techniques related to Content Search or Application Data Discovery. The ability to enumerate resources without proper permission checks allows attackers to build a comprehensive map of available assets within the application environment.
To mitigate this risk, organizations running ApostropheCMS must upgrade immediately to version 4.34.0 or later, where the developers have implemented strict access controls for the slug checking endpoint. These updates ensure that the API only returns information about slugs belonging to documents accessible by the requesting user based on their role and permissions. Until an upgrade is performed, administrators should consider implementing a Web Application Firewall rule to restrict access to this specific API endpoint or monitor logs for unusual patterns of sequential requests indicative of slug enumeration attacks. Regular security audits and penetration testing are also recommended to identify similar authorization flaws in other parts of the CMS infrastructure.