CVE-2026-16219: Croogo FileManager defensive lab

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.

Current status can change. Re-check the primary sources in 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 for the data flow and docs/remediation.md for hardening guidance.

Repository contents

.
|-- 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:

php demo/path_authorization_demo.php

Expected result:

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. Bind the application to 127.0.0.1 only and create the fixed marker directory inside the same VM or container as Croogo:

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.

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

POC_VALIDATE_ONLY=1 ./poc/croogo_local_poc.sh

4. Send the text-marker request

./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:

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

sudo LAB_ACK='I_OWN_THIS_LAB' ./poc/cleanup_marker.sh
unset COOKIE CSRF_TOKEN LAB_ACK BASE

Test the repository

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.

The utility patch in patches/illustrative-hardening.patch and the controller guidance in 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 and DISCLAIMER.md.

License

MIT. See LICENSE.