CVE-2026-16219: Defensives Labor für Croogo FileManager

Dieses Repository dokumentiert und demonstriert sicher die Schwachstelle in der Pfadautorisierung, die als CVE-2026-16219 in Croogo CMS geführt wird. Es richtet sich an Verteidiger, Betreuer, Studierende und Forschende, die Systeme testen, die ihnen gehören oder für deren Bewertung sie ausdrücklich autorisiert sind.

Sicherheitsgrenze: Der enthaltene HTTP-Proof-of-Concept akzeptiert ausschließlich die wörtliche Loopback-Adresse 127.0.0.1, schreibt nur einen generierten .txt-Marker in das feste, nicht im Web liegende Ziel /tmp/croogo-cve-2026-16219/, folgt keinen Weiterleitungen und verweigert die Ausführung ohne eine ausdrückliche Labor-Bestätigung. Er enthält keine ausführbare Nutzlast und keinen Modus für entfernte Ziele.

Statusübersicht

Stichtag: 2026-07-20.

Der aktuelle Status kann sich ändern. Prüfen Sie die Primärquellen in docs/references.md erneut, bevor Sie Produktionsentscheidungen treffen.

Was ist das Problem?

Croogo konfiguriert ein schmales bearbeitbares Wurzelverzeichnis wie WWW_ROOT/assets. Der betroffene Helper erhält FileManager.editablePaths mit Configure::check() statt Configure::read(). check() beantwortet, ob der Schlüssel existiert; es gibt die konfigurierte Pfadliste nicht zurück. Das resultierende Boolean wird dann von der Pfad-Einschlussprüfung verwendet, was die beabsichtigte Autorisierungsgrenze untergräbt.

Die Erstellungs- und Bearbeitungsvorgänge des File Managers vertrauen dieser Prüfung. Unter den vom Upstream-Bericht beschriebenen Bedingungen kann ein authentifizierter FileManager-Benutzer außerhalb des konfigurierten bearbeitbaren Wurzelverzeichnisses schreiben, wenn das PHP-Dienstkonto in den ausgewählten Speicherort schreiben kann.

Siehe docs/technical-analysis.md für den Datenfluss und docs/remediation.md für Härtungsempfehlungen.

Repository-Inhalt

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

Schnellste sichere Demonstration

Das eigenständige Modell erklärt den Fehler, ohne ein verwundbares CMS auszuführen oder eine Netzwerkanfrage zu senden:

php demo/path_authorization_demo.php

Erwartetes Ergebnis:

Buggy modeled check for outside path: ALLOWED
Safe boundary check for outside path: DENIED

Die Demo erstellt temporäre Dateien im temporären Verzeichnis des Betriebssystems und entfernt sie vor dem Beenden.

Lokales Croogo-Labor-PoC

1. Ein isoliertes Labor vorbereiten

Befolgen Sie docs/lab-setup.md. Binden Sie die Anwendung ausschließlich an 127.0.0.1 und erstellen Sie das feste Marker-Verzeichnis in derselben VM oder demselben Container wie Croogo:

sudo install -d -o www-data -g www-data -m 0750 \
  /tmp/croogo-cve-2026-16219

Ersetzen Sie www-data durch das PHP-FPM- oder Webserver-Konto im Wegwerf-Labor.

2. Nur für das Labor bestimmte Authentifizierungswerte exportieren

Holen Sie den vollständigen Cookie-Header und das CakePHP-CSRF-Token aus einer legitimen File-Manager-Anfrage in Ihrem eigenen Labor. Committen Sie diese niemals.

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. Die Schutzmaßnahmen validieren, ohne eine Anfrage zu senden

POC_VALIDATE_ONLY=1 ./poc/croogo_local_poc.sh

4. Die Text-Marker-Anfrage senden

./poc/croogo_local_poc.sh

Das Skript gibt den generierten Dateinamen und den HTTP-Status aus. Eine HTTP-Weiterleitung oder Erfolgsantwort ist für sich genommen kein Beweis; überprüfen Sie den Marker von innerhalb der Croogo-VM oder des Croogo-Containers:

sudo ./poc/verify_marker.sh

Ein Marker außerhalb von WWW_ROOT/assets zeigt den Autorisierungsfehler. Der Marker ist reiner Text und nicht über das Web ausführbar.

5. Aufräumen

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

Repository testen

make test

Die Tests bestätigen die Shell-Syntax, weisen Nicht-Loopback- und URL-Verwechslungseingaben zurück, stellen sicher, dass bei der Validierung keine Geheimnisse ausgegeben werden, und verifizieren das erwartete Ergebnis des eigenständigen Modells.

Prioritäten für die Behebung

1. Deaktivieren Sie den Admin File Manager oder beschränken Sie ihn auf eine minimale Gruppe vertrauenswürdiger Administratoren, bis ein getesteter Fix bereitgestellt ist.
2. Korrigieren Sie den Abruf der Konfiguration, indem Sie Configure::read() verwenden.
3. Kanonisieren Sie sowohl das erlaubte Wurzelverzeichnis als auch das Kandidatenverzeichnis und führen Sie dann eine trennerbewusste Einschlussprüfung durch.
4. Weisen Sie Pfadtrenner, NUL-Bytes und unsichere Namen im übermittelten Dateinamen zurück.
5. Verhindern Sie, dass PHP in Anwendungsquellen und ausführbare Webroot-Speicherorte schreibt.
6. Überprüfen Sie Protokolle und beschreibbare Speicherorte anhand von docs/detection.md.

Das Hilfspatch in patches/illustrative-hardening.patch und die Controller-Anleitung in patches/create-file-hardening-example.md sind Überprüfungshilfen, keine offiziellen Hersteller-Fixes. Testen Sie sie gegen den exakt eingesetzten Branch.

Ethische Nutzung

Verwenden Sie dieses Repository nur auf Systemen, die Ihnen gehören oder für deren Tests Sie eine ausdrückliche schriftliche Genehmigung haben. Passen Sie den PoC nicht für öffentliche Ziele, ausführbare Nutzlasten, Persistenz, Zugriff auf Anmeldedaten oder destruktive Aktionen an. Siehe SECURITY.md und DISCLAIMER.md.

Lizenz

MIT. Siehe LICENSE.