How severe is GHSA-2j32-q6rx-h844?

GHSA-2j32-q6rx-h844 has a CVSS score of 5.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-2j32-q6rx-h844?

GHSA-2j32-q6rx-h844 affects the following packages: apostrophe (npm). Ecosystems affected: npm.

How do I fix GHSA-2j32-q6rx-h844?

Update apostrophe to 4.33.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2j32-q6rx-h844 is resolved across your whole dependency graph.

How do I detect GHSA-2j32-q6rx-h844 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apostrophe, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-2j32-q6rx-h844 if there is no patch (or I can't update yet)?

Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Is GHSA-2j32-q6rx-h844 actively exploited in the wild?

No public exploit code has been indexed for GHSA-2j32-q6rx-h844 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-2j32-q6rx-h844?

GHSA-2j32-q6rx-h844 has an EPSS (Exploit Prediction Scoring System) score of 0.2%, placing it in the 15th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-2j32-q6rx-h844?

GHSA-2j32-q6rx-h844 is classified as CWE-863 (CWE-863). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-2j32-q6rx-h844 published, and has it been updated?

GHSA-2j32-q6rx-h844 was published on October 20, 2026 and was last updated on October 20, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦

📦 npm

Not in CISA KEV

MEDIUM severity

ApostropheCMS: Page REST API authorization bypassGHSA-2j32-q6rx-h844

MEDIUMFix: apostrophecms/apostrophe@9500b8b

GHSA-2j32-q6rx-h844 is a medium-severity (CVSS 5.3) CWE-863 vulnerability in apostrophe. A fix is available for apostrophe — see the affected versions and patch details below.

Also known asCVE-2026-110904 CVE-2026-113670

Published

Oct 20, 2026

Updated

Oct 20, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-2j32-q6rx-h844.

EPSS Exploitation Probability

via FIRST.org ↗

0.2%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs15th percentile — riskier than 15% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-2j32-q6rx-h844 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

8other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

apostrophenpm

18Kdownloads / week

Description

Summary The core page REST API reads full page documents with .permission(false) in getOne and in the all=1 tree dump, bypassing page-type viewRole, visibility: private, and visibility: loginRequired checks. Unauthenticated visitors and low-privilege contributors can read admin-only and non-public page content by _id/slug.

Details packages/apostrophe/modules/@apostrophecms/page/index.js:

getOne (L456–465): await self.publicApiCheckAsync(req); ... self.getRestQuery(req).permission(false).and(criteria) — no viewRole threshold, no visibility filtering.
all handler (L318–395): getRestQuery(req).permission(false) (L384–385) walks every page type and returns the projection including visibility.
publicApiCheckAsync (L3044) only checks that publicApiProjection exists — it performs no authorization.
Correct control behaves differently: piece-type/index.js:getOne (L319–327) uses getRestQuery(req) without .permission(false) and enforces viewRole.

PoC

# Anonymous (no session) — private, admin-only page:
curl "http://localhost:3100/api/v1/@apostrophecms/page/d576242ve1dkzb12jiiabujd:en:published"
# → 200  {"_id":"...:en:published","title":"Secret Private Page","slug":"/secret-page",
#         "type":"private-type","visibility":"private","secretData":"TOP-SECRET-VALUE-abc123"}

# Anonymous full site-map dump (includes private + loginRequired pages):
curl "http://localhost:3100/api/v1/@apostrophecms/page?all=1"        # → 200, full tree

# Contributor (cont_admin) reads full admin-only doc incl. protected field:
curl -b contrib.cookies ".../api/v1/@apostrophecms/page/d576242ve1dkzb12jiiabujd:en:published"
# → 200  secretData = TOP-SECRET-VALUE-abc123
# Controls (correctly enforced):
curl -b contrib.cookies ".../api/v1/@apostrophecms/page?type=private-type&autocomplete=zz"   # → 403
curl -b contrib.cookies ".../api/v1/@apostrophecms/page/d576242ve1dkzb12jiiabujd:en:draft"   # → 403

Impact Unauthenticated disclosure of visibility: private and loginRequired pages (full documents, not just paths) and of the complete site structure with visibility/type metadata; contributors read admin-only page types and their protected fields. Because _ids are enumerable and leaked by all=1, this is systemic.

Remediation — Remove .permission(false) from getOne/all or re-apply the type's viewRole threshold plus the same visibility/login-required criteria the list and autocomplete paths use (mirror piece-type); make publicApiCheck config-presence-only and add an explicit authorization step per verb.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`apostrophe`	all versions	4.33.0`npm install apostrophe@4.33.0`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apostrophe, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update apostrophe to 4.33.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2j32-q6rx-h844 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

**Summary** The core page REST API reads full page documents with `.permission(false)` in `getOne` and in the `all=1` tree dump, bypassing page-type `viewRole`, `visibility: private`, and `visibility: loginRequired` checks. Unauthenticated visitors and low-privilege contributors can read admin-only and non-public page content by `_id`/slug. **Details** `packages/apostrophe/modules/@apostrophecms/page/index.js`: - `getOne` (L456–465): `await self.publicApiCheckAsync(req); ... self.getRestQuery(req).permission(false).and(criteria)` — no `viewRole` threshold, no `visibility` filtering. - `all` h

O3 Security · Impact-Aware SCA

Is GHSA-2j32-q6rx-h844 in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works

CVSS Score

5.3/10CVSS v3 base

Vector breakdown

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Raw vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CWE Classification

CWE-863CWE-863

Weaponization

No known public exploit tooling found.

OpenSSF Scorecard

Package health score

apostrophe

6.4/10

Code-Review10/10

Maintained10/10

Branch-ProtectionN/A

Assessed Oct 19, 2026

Timeline

Disclosed

Oct 20, 2026

Identifiers

GHSA-2j32-q6rx-h844

References

Webgithub.com Webgithub.com Webgithub.com Webgithub.com Packagegithub.com

Related vulnerabilities

This CVE is medium severity; 8 of 8 other CVEs affecting apostrophe are rated as high or higher (top: high).

CVE-2026-113649CVE-2026-112958CVE-2026-113711CVE-2026-112952CVE-2026-112954CVE-2026-112957CVE-2026-112951CVE-2026-113670

Provenance

Sources

OSV.devNVDFIRST.org (EPSS)

Last verifiedOct 20, 2026

ApostropheCMS: Page REST API authorization bypassGHSA-2j32-q6rx-h844

Exploitation Status

Proof-of-concept exploit code exists

EPSS Exploitation Probability

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

Description

Affected Packages

Detection & mitigation playbook

Detect

Fix

Workarounds

Frequently Asked Questions

Is GHSA-2j32-q6rx-h844 in your dependencies?