## https://sploitus.com/exploit?id=3C4F5538-5DE7-512A-B2A4-60C4AAC1BBF7
# CVE-2026-16219: Croogo FileManager defensive lab
[](SECURITY.md)
[](poc/croogo_local_poc.sh)
This repository documents and safely demonstrates the path-authorization flaw tracked as **CVE-2026-16219** in Croogo CMS. It is intended for defenders, maintainers, students, and researchers testing systems they own or are explicitly authorized to assess.
> **Safety boundary:** The included HTTP proof of concept accepts only the literal loopback address `127.0.0.1`, writes only a generated `.txt` marker to the fixed non-web destination `/tmp/croogo-cve-2026-16219/`, does not follow redirects, and refuses to run without an explicit lab acknowledgement. It contains no executable payload and no remote-target mode.
## Status snapshot
Snapshot date: **2026-07-20**.
| Field | Value |
|---|---|
| Product | Croogo CMS, Admin File Manager |
| NVD affected versions | 4.0.0 through 4.0.7 |
| Weakness | CWE-22, path traversal / improper path restriction |
| NVD CNA CVSS v3.1 | 6.3 Medium |
| Privileges | Authenticated FileManager-capable account |
| User interaction | None after authentication |
| Public disclosure | Upstream issue and public exploit information exist |
| Patched version | Not identified in the cited advisory snapshot |
Current status can change. Re-check the primary sources in [docs/references.md](docs/references.md) before making production decisions.
## What is wrong
Croogo configures a narrow editable root such as `WWW_ROOT/assets`. The affected helper obtains `FileManager.editablePaths` with `Configure::check()` rather than `Configure::read()`. `check()` answers whether the key exists; it does not return the configured path list. The resulting Boolean is then used by the path-containment check, undermining the intended authorization boundary.
The File Manager create and edit operations trust that check. Under the conditions described by the upstream report, an authenticated FileManager user can write outside the configured editable root when the PHP service account can write to the selected location.
See [docs/technical-analysis.md](docs/technical-analysis.md) for the data flow and [docs/remediation.md](docs/remediation.md) for hardening guidance.
## Repository contents
```text
.
|-- demo/ Standalone logic demonstration; no Croogo required
|-- docs/ Analysis, lab setup, detection, remediation, references
|-- patches/ Illustrative defense-in-depth patch
|-- poc/ Strictly loopback, text-marker HTTP PoC and cleanup tools
|-- tests/ Guardrail and demo tests
|-- .github/workflows/validate.yml
|-- DISCLAIMER.md
|-- GITHUB_UPLOAD.md
|-- LICENSE
|-- Makefile
|-- SECURITY.md
`-- VERSION
```
## Fastest safe demonstration
The standalone model explains the bug without running a vulnerable CMS or sending any network request:
```bash
php demo/path_authorization_demo.php
```
Expected result:
```text
Buggy modeled check for outside path: ALLOWED
Safe boundary check for outside path: DENIED
```
The demo creates temporary files under the operating system temp directory and removes them before exiting.
## Local Croogo lab PoC
### 1. Prepare an isolated lab
Follow [docs/lab-setup.md](docs/lab-setup.md). Bind the application to `127.0.0.1` only and create the fixed marker directory inside the same VM or container as Croogo:
```bash
sudo install -d -o www-data -g www-data -m 0750 \
/tmp/croogo-cve-2026-16219
```
Replace `www-data` with the PHP-FPM or web-server account in the disposable lab.
### 2. Export lab-only authentication values
Obtain the complete Cookie header and CakePHP CSRF token from a legitimate File Manager request in your own lab. Never commit them.
```bash
export BASE='http://127.0.0.1:8080'
export COOKIE='CAKEPHP=lab-session; csrfToken=lab-cookie-token'
export CSRF_TOKEN='lab-request-token'
export LAB_ACK='I_OWN_THIS_LAB'
```
### 3. Validate the safeguards without sending a request
```bash
POC_VALIDATE_ONLY=1 ./poc/croogo_local_poc.sh
```
### 4. Send the text-marker request
```bash
./poc/croogo_local_poc.sh
```
The script prints the generated filename and HTTP status. An HTTP redirect or success response is not proof by itself; verify the marker from inside the Croogo VM or container:
```bash
sudo ./poc/verify_marker.sh
```
A marker outside `WWW_ROOT/assets` demonstrates the authorization failure. The marker is plain text and is not web-executable.
### 5. Clean up
```bash
sudo LAB_ACK='I_OWN_THIS_LAB' ./poc/cleanup_marker.sh
unset COOKIE CSRF_TOKEN LAB_ACK BASE
```
## Test the repository
```bash
make test
```
Tests confirm shell syntax, reject non-loopback and URL-confusion inputs, ensure secrets are not printed during validation, and verify the standalone model's expected result.
## Remediation priorities
1. Disable the Admin File Manager or restrict it to a minimal set of trusted administrators until a tested fix is deployed.
2. Correct configuration retrieval by using `Configure::read()`.
3. Canonicalize both the allowed root and candidate directory, then perform a separator-aware containment check.
4. Reject path separators, NUL bytes, and unsafe names in the submitted filename.
5. Prevent PHP from writing to application source and executable webroot locations.
6. Review logs and writable locations using [docs/detection.md](docs/detection.md).
The utility patch in [patches/illustrative-hardening.patch](patches/illustrative-hardening.patch) and the controller guidance in [patches/create-file-hardening-example.md](patches/create-file-hardening-example.md) are review aids, not official vendor fixes. Test them against the exact deployed branch.
## Ethical use
Use this repository only on systems you own or have explicit written authorization to test. Do not adapt the PoC for public targets, executable payloads, persistence, credential access, or destructive actions. See [SECURITY.md](SECURITY.md) and [DISCLAIMER.md](DISCLAIMER.md).
## License
MIT. See [LICENSE](LICENSE).