Listen to this Post
How the vulnerability works
The page content retrieval feature in Connect CMS lacks proper authorization checks. When a request is made to fetch page data—such as via an API endpoint like /api/page/content—the system does not verify that the authenticated user has the necessary permissions to view the target page. The vulnerability exists in versions 1.x up to 1.40.0 and 2.x up to 2.40.0. Internally, the controller method responsible for retrieving page content bypasses the authorization middleware that normally enforces access controls for non‑public pages. An attacker with a low‑privileged account (or even an unauthenticated session in misconfigured deployments) can craft a request containing a valid page ID belonging to a restricted page. Because the permission check is omitted, the server returns the full page content, including body text, metadata, and file attachments. The flaw stems from an incorrect assumption that the retrieval endpoint would only be invoked after higher‑level authorization checks, leaving a direct route that circumvents them. Exploitation requires knowledge of the target page’s internal identifier, which may be guessed or enumerated through other endpoints. The issue was fixed by adding a proper authorization hook that validates user roles against page visibility settings before serving any data.
Platform: Connect CMS
Version: ≤1.40.0, 2.0.0‑2.40.0
Vulnerability : Improper Authorization
Severity: High
date: Mar 23, 2026
Prediction: already patched (Mar 23)
What Undercode Say:
Check Connect CMS version grep '"version"' composer.json Test for vulnerable endpoint (authenticated request) curl -X GET "https://target.com/api/page/content?id=non-public-page-id" \ -H "Authorization: Bearer $TOKEN"
Exploit:
Craft a GET request to the page content retrieval endpoint with a known internal ID of a private page; the server returns the full content without enforcing visibility rules.
Protection from this CVE
Update to 1.41.1 (1.x series) or 2.41.1 (2.x series). If immediate update is not possible, restrict access to the `/api/page/content` endpoint via web server rules until patching is complete.
Impact:
Unauthorized disclosure of non‑public page contents and attachments, potentially exposing sensitive internal information or draft materials.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
