Listen to this Post
How the mentioned CVE works:
The vulnerability stems from missing authorization checks in Kirby CMS versions prior to 4.9.0 and 5.4.0. Authenticated users with roles that have pages.access, pages.list, files.access, or `files.list` permissions disabled can still view or infer the existence of restricted pages and files. Specifically, the Panel’s changes dialog lists changed models even when they are not listable. The REST API fails to filter collections, children, drafts, files, parents, siblings, and related models (e.g., next/prev for files). It incorrectly uses `pages.access` instead of `pages.list` for site children and search routes, and `files.access` instead of `files.list` for account, site, pages, and users file routes. Additionally, Panel images for non-listable models appear in parent lists, and previous/next file links are not gated by isListable(). Attackers exploit this by authenticating as a low-privilege user and accessing API endpoints or Panel views to enumerate hidden content. Write actions remain unaffected. The root cause is inconsistent enforcement of the `isListable()` property across modules, allowing unauthorized information disclosure.
Platform: Kirby CMS
Version: <4.9.0, <5.4.0
Vulnerability: Missing authorization
Severity: High
date: Not specified
Prediction: Already patched
What Undercode Say:
Check Kirby version from composer.json cat composer.json | grep "getkirby/cms" Test if site is vulnerable (requires authenticated session) curl -X GET "https://target.com/api/pages/children?q=secret" \ -H "Authorization: Bearer <low_priv_token>" Enumerate hidden files via REST API curl -X GET "https://target.com/api/site/files" \ -H "Authorization: Bearer <low_priv_token>" Simulate missing listable check for siblings curl -X GET "https://target.com/api/pages/parent/children?include=siblings" Check Panel changes dialog endpoint curl -X GET "https://target.com/api/changes" \ -H "X-Fingerprint: <user_fingerprint>" \ -H "Cookie: kirby_session=..."
How Exploit:
- Obtain credentials for a user whose role has `pages.list = false` or
files.list = false. - Log into the Panel or obtain an API token.
- Call REST API endpoints like
/api/pages/children,/api/site/files, `/api/users//files` – observe that non-listable models appear in responses. - For Panel, open the “Changes” dialog – hidden changed pages/files are listed.
- Navigate to a parent page with non-listable children – the children’s images may still render in lists.
- Use
next/prevlinks in file view to cycle through restricted files. - Access search routes (e.g.,
/api/pages/search) – results include non-listable pages due to incorrect permission check.
Protection from this CVE:
- Upgrade to Kirby 4.9.0 or 5.4.0 immediately.
- If patching is delayed, apply the fix manually: add `$model->isListable()` checks in all core controllers and API endpoints that return collections or related models.
- Override panel and API routes via custom plugins to enforce `pages.list` and `files.list` consistently.
- Set `’debug’ => false` in config to avoid exposing internal paths.
- Audit user blueprints to ensure
pages.access,pages.list,files.access, `files.list` are explicitly `false` for roles that should have no visibility. - Use firewall rules to restrict Panel and API access to trusted IPs only.
Impact:
- Unauthorized disclosure of page s, file names, and metadata.
- Attackers can enumerate hidden content (e.g., draft pages, private files) leading to information leakage.
- Indirectly, exposed content may reveal sensitive business logic or user data.
- No impact on write operations (create/update/delete).
- For sites where all authenticated users are trusted to see all content, impact is mitigated.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
