CVE-2026-16219: Laboratorio defensivo del FileManager de Croogo

Este repositorio documenta y demuestra de forma segura la falla de autorización de rutas registrada como CVE-2026-16219 en Croogo CMS. Está dirigido a defensores, mantenedores, estudiantes e investigadores que prueban sistemas propios o sobre los que tienen autorización explícita para evaluar.

Límite de seguridad: La prueba de concepto HTTP incluida acepta únicamente la dirección literal de loopback 127.0.0.1, escribe solo un marcador .txt generado en el destino fijo no web /tmp/croogo-cve-2026-16219/, no sigue redirecciones y se niega a ejecutarse sin un acuse de recibo explícito de laboratorio. No contiene payload ejecutable ni modo de objetivo remoto.

Estado actual

Fecha de la instantánea: 2026-07-20.

El estado actual puede cambiar. Vuelva a consultar las fuentes primarias en docs/references.md antes de tomar decisiones de producción.

Qué es lo que falla

Croogo configura una raíz editable estrecha como WWW_ROOT/assets. El helper afectado obtiene FileManager.editablePaths con Configure::check() en lugar de Configure::read(). check() responde si la clave existe; no devuelve la lista de rutas configurada. El Boolean resultante se usa luego en la comprobación de contención de rutas, socavando el límite de autorización previsto.

Las operaciones de creación y edición del File Manager confían en esa comprobación. Bajo las condiciones descritas en el informe upstream, un usuario autenticado de FileManager puede escribir fuera de la raíz editable configurada cuando la cuenta de servicio de PHP puede escribir en la ubicación seleccionada.

Consulte docs/technical-analysis.md para el flujo de datos y docs/remediation.md para obtener orientación de endurecimiento.

Contenido del repositorio

.
|-- demo/                         Demostración lógica independiente; no requiere Croogo
|-- docs/                         Análisis, configuración del laboratorio, detección, remediación, referencias
|-- patches/                      Parche ilustrativo de defensa en profundidad
|-- poc/                          PoC HTTP estrictamente de loopback, con marcador de texto, y herramientas de limpieza
|-- tests/                        Pruebas de salvaguarda y de la demo
|-- .github/workflows/validate.yml
|-- DISCLAIMER.md
|-- GITHUB_UPLOAD.md
|-- LICENSE
|-- Makefile
|-- SECURITY.md
`-- VERSION

Demostración segura más rápida

El modelo independiente explica el fallo sin ejecutar un CMS vulnerable ni enviar ninguna petición de red:

php demo/path_authorization_demo.php

Resultado esperado:

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

La demo crea archivos temporales en el directorio temporal del sistema operativo y los elimina antes de salir.

PoC del laboratorio local de Croogo

1. Prepare un laboratorio aislado

Siga docs/lab-setup.md. Vincule la aplicación únicamente a 127.0.0.1 y cree el directorio fijo de marcadores dentro de la misma VM o contenedor que Croogo:

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

Reemplace www-data con la cuenta de PHP-FPM o del servidor web en el laboratorio desechable.

2. Exporte los valores de autenticación exclusivos del laboratorio

Obtenga la cabecera Cookie completa y el token CSRF de CakePHP a partir de una petición legítima del File Manager en su propio laboratorio. No los confíe nunca al control de versiones.

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. Valide las salvaguardas sin enviar una petición

POC_VALIDATE_ONLY=1 ./poc/croogo_local_poc.sh

4. Envíe la petición de marcador de texto

./poc/croogo_local_poc.sh

El script imprime el nombre de archivo generado y el estado HTTP. Una redirección HTTP o una respuesta de éxito no son prueba por sí solas; verifique el marcador desde dentro de la VM o contenedor de Croogo:

sudo ./poc/verify_marker.sh

Un marcador fuera de WWW_ROOT/assets demuestra la falla de autorización. El marcador es texto sin formato y no es ejecutable en la web.

5. Limpieza

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

Probar el repositorio

make test

Las pruebas confirman la sintaxis del shell, rechazan entradas que no sean de loopback y de confusión de URL, garantizan que los secretos no se impriman durante la validación y verifican el resultado esperado del modelo independiente.

Prioridades de remediación

1. Deshabilite el Admin File Manager o restringirlo a un conjunto mínimo de administradores de confianza hasta que se implemente un parche probado.
2. Corrija la obtención de configuración usando Configure::read().
3. Canonicalice tanto la raíz permitida como el directorio candidato y, a continuación, realice una comprobación de contención sensible a separadores.
4. Rechace separadores de ruta, bytes NUL y nombres inseguros en el nombre de archivo enviado.
5. Impida que PHP escriba en el código fuente de la aplicación y en ubicaciones ejecutables del webroot.
6. Revise los registros y las ubicaciones escribibles usando docs/detection.md.

El parche utilitario en patches/illustrative-hardening.patch y la guía de controlador en patches/create-file-hardening-example.md son ayudas de revisión, no correcciones oficiales del proveedor. Pruébelos contra la rama desplegada exacta.

Uso ético

Utilice este repositorio únicamente en sistemas propios o sobre los que tenga autorización escrita explícita para probar. No adapte la PoC para objetivos públicos, payloads ejecutables, persistencia, acceso a credenciales o acciones destructivas. Consulte SECURITY.md y DISCLAIMER.md.

Licencia

MIT. Consulte LICENSE.