GHSA-6j4c-mgqr-qv76
Fix: getkirby/kirby@2b6fab9GHSA-6j4c-mgqr-qv76 is a Path Traversal vulnerability in getkirby/cms. O3 Security confirms whether GHSA-6j4c-mgqr-qv76 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Kirby: Access to image files outside of the site root via path traversal in the media handling
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6j4c-mgqr-qv76.
Real-World Exposure
getkirby/cms🐘getkirby/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
TL;DR
This vulnerability affects all Kirby sites that are deployed in a way that their index root on the server is next to a second directory that is read-accessible to PHP and shares the same name prefix (such as the site with the index root /var/www/site being next to /var/www/site2).
It was possible to create and access thumbnails from media files within such sibling directories that have a valid thumbnail configuration (JSON job file). This can affect staging sites, site backups or other internal sites.
Introduction
A path traversal (also known as directory traversal) vulnerability occurs when untrusted input is used to build a filesystem path without properly confining the result to an intended base directory. By injecting sequences such as ../, an attacker can escape that directory and reach files elsewhere on the server.
Affected components
Kirby's media handler processes requests for files in the media directory that have not been generated yet. It parses the provided path and finds the correct file or asset to generate a thumbnail of. Each thumbnail needs to have a prepared job file (a metadata file with file extension .json) in order to allow the media handler to generate a thumbnail.
The media handler uses filesystem containment checks in several places that are supposed to prevent breakout of the media and index roots of the site.
Impact
In affected releases, the containment checks were incomplete and did not cover the case of a sibling directory next to the containment directory that starts with the same prefix. E.g. a directory site2 passed the containment check of directory site. This allowed attackers to access media files with prepared job files that are stored within such sibling directories of the site's index root, opening the potential for information leaks from sensitive files stored within them, and deleting the job file in the process.
Patches
The problem has been patched in Kirby 4.9.5 and Kirby 5.5.2. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, we have hardened the containment helpers Kirby\Filesystem\Dir::realpath() and Kirby\Filesystem\F::realpath() to require either an exact match or a DIRECTORY_SEPARATOR boundary, so that a sibling path sharing the same name prefix can no longer pass the check. This prevents access to files outside the index root of the active site. We have also hardened the Asset class to block paths that contain the ../ sequence.
Credits
Thanks to @0x1saac for responsibly reporting the identified issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | getkirby/cms | all versions | 4.9.5 |
| 🐘Packagist | getkirby/cms | ≥ 5.0.0&&< 5.5.2 | 5.5.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for getkirby/cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update getkirby/cms to 4.9.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6j4c-mgqr-qv76 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6j4c-mgqr-qv76 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6j4c-mgqr-qv76. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6j4c-mgqr-qv76 in your dependencies?
O3 detects GHSA-6j4c-mgqr-qv76 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.