CVE-2026-16219 : laboratoire défensif Croogo FileManager

Ce dépôt documente et démontre en toute sécurité la faille d'autorisation de chemin référencée sous CVE-2026-16219 dans Croogo CMS. Il est destiné aux défenseurs, aux mainteneurs, aux étudiants et aux chercheurs qui testent des systèmes leur appartenant ou qu'ils sont explicitement autorisés à évaluer.

Limite de sécurité : La preuve de concept HTTP incluse n'accepte que l'adresse de bouclage littérale 127.0.0.1, n'écrit qu'un marqueur .txt généré dans la destination fixe hors web /tmp/croogo-cve-2026-16219/, ne suit pas les redirections et refuse de s'exécuter sans un accusé de réception explicite du laboratoire. Elle ne contient aucune charge utile exécutable et aucun mode de cible distante.

Aperçu de l'état

Date de l'aperçu : 2026-07-20.

Le statut actuel peut évoluer. Revérifiez les sources primaires dans docs/references.md avant de prendre des décisions de production.

Quel est le problème

Croogo configure une racine éditable restreinte telle que WWW_ROOT/assets. L'helper affecté obtient FileManager.editablePaths avec Configure::check() plutôt que Configure::read(). check() répond si la clé existe ; il ne renvoie pas la liste des chemins configurés. Le booléen obtenu est ensuite utilisé par le contrôle de confinement de chemin, compromettant la limite d'autorisation prévue.

Les opérations de création et de modification du File Manager se fient à cette vérification. Dans les conditions décrites par le rapport amont, un utilisateur FileManager authentifié peut écrire en dehors de la racine éditable configurée lorsque le compte de service PHP peut écrire à l'emplacement choisi.

Voir docs/technical-analysis.md pour le flux de données et docs/remediation.md pour les recommandations de durcissement.

Contenu du dépôt

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

Démonstration sûre la plus rapide

Le modèle autonome explique le bug sans exécuter un CMS vulnérable ni envoyer de requête réseau :

php demo/path_authorization_demo.php

Résultat attendu :

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

La démo crée des fichiers temporaires dans le répertoire temporaire du système d'exploitation et les supprime avant de se terminer.

PoC local pour le laboratoire Croogo

1. Préparer un laboratoire isolé

Suivez docs/lab-setup.md. Liez l'application à 127.0.0.1 uniquement et créez le répertoire de marqueur fixe dans la même VM ou le même conteneur que Croogo :

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

Remplacez www-data par le compte PHP-FPM ou serveur web dans le laboratoire jetable.

2. Exporter les valeurs d'authentification propres au laboratoire

Obtenez l'en-tête Cookie complet et le jeton CSRF CakePHP à partir d'une requête légitime du File Manager dans votre propre laboratoire. Ne les committez jamais.

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. Valider les mesures de protection sans envoyer de requête

POC_VALIDATE_ONLY=1 ./poc/croogo_local_poc.sh

4. Envoyer la requête avec le marqueur texte

./poc/croogo_local_poc.sh

Le script affiche le nom de fichier généré et le statut HTTP. Une redirection HTTP ou une réponse de succès ne constitue pas une preuve en soi ; vérifiez le marqueur depuis l'intérieur de la VM ou du conteneur Croogo :

sudo ./poc/verify_marker.sh

Un marqueur en dehors de WWW_ROOT/assets démontre l'échec d'autorisation. Le marqueur est en texte brut et n'est pas exécutable via le web.

5. Nettoyer

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

Tester le dépôt

make test

Les tests confirment la syntaxe shell, rejettent les entrées non-bouclage et les confusions d'URL, garantissent que les secrets ne sont pas affichés lors de la validation, et vérifient le résultat attendu du modèle autonome.

Priorités de remédiation

1. Désactivez le File Manager d'administration ou restreignez-le à un ensemble minimal d'administrateurs de confiance jusqu'au déploiement d'un correctif testé.
2. Corrigez la récupération de configuration en utilisant Configure::read().
3. Canonicalisez la racine autorisée et le répertoire candidat, puis effectuez une vérification de confinement tenant compte des séparateurs.
4. Rejetez les séparateurs de chemin, les octets NUL et les noms non sûrs dans le nom de fichier soumis.
5. Empêchez PHP d'écrire dans les sources de l'application et dans les emplacements exécutables de la racine web.
6. Examinez les journaux et les emplacements inscriptibles à l'aide de docs/detection.md.

Le patch utilitaire dans patches/illustrative-hardening.patch et le guide de contrôleur dans patches/create-file-hardening-example.md sont des aides à la revue, pas des correctifs officiels du fournisseur. Testez-les sur la branche exactement déployée.

Utilisation éthique

Utilisez ce dépôt uniquement sur des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de test. N'adaptez pas la PoC pour des cibles publiques, des charges utiles exécutables, la persistance, l'accès aux identifiants ou des actions destructrices. Voir SECURITY.md et DISCLAIMER.md.

Licence

MIT. Voir LICENSE.