CVE-2026-113670: 
JavaScript vulnerability analysis and mitigation

CVE-2026-113670 is a Page REST API authorization bypass vulnerability in ApostropheCMS, an open-source Node.js content management system. The flaw allows unauthenticated visitors and low-privilege contributors to read full page documents that are marked as private, login-required, or restricted to admin-only page types. It affects all versions of the apostrophe npm package prior to 4.33.0. The vulnerability was published on October 2, 2026, and added to the GitHub Advisory Database on October 20, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory).

The root cause is Incorrect Authorization (CWE-863) in packages/apostrophe/modules/@apostrophecms/page/index.js. Both the getOne handler (L456–465) and the all=1 tree dump handler (L318–395) call .permission(false) on the REST query, which explicitly disables all authorization checks — bypassing page-type viewRole thresholds, visibility: private, and visibility: loginRequired enforcement. The publicApiCheckAsync function (L3044) only verifies that a publicApiProjection configuration key exists but performs no actual authorization, making it ineffective as a security gate. By contrast, the piece-type getOne handler correctly omits .permission(false) and enforces viewRole. Because page _ids are enumerable via the all=1 endpoint, an attacker can first dump the full site tree to harvest IDs and then query individual private pages by ID or slug without any credentials (Github Advisory, Security Fix Commit).

Successful exploitation results in unauthorized disclosure of the full content of pages configured as visibility: private or visibility: loginRequired, including all document fields and protected custom fields (e.g., secretData). Unauthenticated visitors can retrieve the complete site page tree — including visibility metadata and page types — via the all=1 dump, and low-privilege contributors can read admin-only page types and their protected fields. There is no integrity or availability impact; the vulnerability is limited to confidentiality loss, but the systemic nature of the all=1 ID enumeration makes it broadly exploitable across an entire site (Github Advisory).

No public proof-of-concept exploit code has been observed beyond the PoC included in the official security advisory itself, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is 0.0, reflecting a very low current probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires no authentication, no user interaction, and no special configuration — only network access to the ApostropheCMS REST API endpoint — making it trivially easy to attempt once a target is identified.

1. Reconnaissance: Identify internet-facing ApostropheCMS instances running versions prior to 4.33.0 using tools like Shodan or Censys, searching for the characteristic /api/v1/@apostrophecms/ API path.
2. Enumerate the full site tree: Send an unauthenticated HTTP GET request to the all=1 endpoint to dump the complete page tree, including private and login-required pages with their _id values, slugs, and visibility metadata:

   curl "http://target.example.com/api/v1/@apostrophecms/page?all=1"

3. Identify sensitive pages: Parse the JSON response to locate pages with visibility: private, visibility: loginRequired, or admin-only type values.
4. Retrieve full page content: Query individual private pages by their _id or slug to retrieve the full document, including all protected fields:

   curl "http://target.example.com/api/v1/@apostrophecms/page/<_id>:en:published"

5. Exfiltrate data: Collect the returned JSON documents containing sensitive content such as draft text, protected custom fields, and administrative metadata (Github Advisory).

• Network: Unauthenticated HTTP GET requests to /api/v1/@apostrophecms/page?all=1 from external IP addresses; repeated unauthenticated GET requests to /api/v1/@apostrophecms/page/<id>:en:published for multiple page IDs in rapid succession.
• Logs: Web server or application access logs showing 200 responses to /api/v1/@apostrophecms/page endpoints from unauthenticated sessions (no session cookie or bearer token present); bulk sequential requests to the page API from a single IP suggesting automated enumeration.
• Behavioral: Unusual volume of API requests to the page REST endpoint outside of normal CMS editor activity, particularly targeting the all=1 parameter or iterating over known _id patterns.

The fix is available in apostrophe version 4.33.0 (npm package), which removes .permission(false) from the getOne and all handlers and enforces proper viewRole and visibility checks mirroring the piece-type implementation (Github Advisory, Release 4.33.0). Upgrading immediately is the recommended remediation. As a temporary workaround until patching is possible, restrict network access to the /api/v1/@apostrophecms/page endpoints at the reverse proxy or WAF level, requiring authentication before requests reach the application, or block unauthenticated access to the REST API entirely.

The vulnerability was reported by security researcher chaitanyaeshwarprasad and credited in the official GitHub advisory. The fix was merged as part of a broader batch of security advisories (commit f84fd41) that addressed over a dozen separate vulnerabilities in ApostropheCMS simultaneously, suggesting a coordinated security review effort by the maintainers (Security Fix Commit). No significant broader media coverage or social media discussion has been observed beyond standard vulnerability database indexing.