CVE-2026-16219: laboratorio difensivo Croogo FileManager

Questo repository documenta e dimostra in modo sicuro il difetto di autorizzazione dei percorsi tracciato come CVE-2026-16219 in Croogo CMS. È pensato per difensori, manutentori, studenti e ricercatori che testano sistemi di cui sono proprietari o che sono esplicitamente autorizzati a valutare.

Confine di sicurezza: la prova di concetto HTTP inclusa accetta solo l'indirizzo di loopback letterale 127.0.0.1, scrive solo un marcatore .txt generato nella destinazione fissa non web /tmp/croogo-cve-2026-16219/, non segue i reindirizzamenti e rifiuta di essere eseguita senza un'esplicita conferma del laboratorio. Non contiene payload eseguibile né modalità di destinazione remota.

Istantanea dello stato

Data dell'istantanea: 2026-07-20.

Field	Value
Prodotto	Croogo CMS, Admin File Manager
Versioni interessate (NVD)	Dalla 4.0.0 alla 4.0.7
Debolezza	CWE-22, path traversal / restrizione impropria del percorso
NVD CNA CVSS v3.1	6.3 Medio
Privilegi	Account autenticato con permessi FileManager
Interazione utente	Nessuna dopo l'autenticazione
Divulgazione pubblica	Esistono segnalazioni upstream e informazioni pubbliche di exploit
Versione corretta	Non identificata nell'istantanea dell'avviso citato

Lo stato attuale può cambiare. Ricontrolla le fonti primarie in docs/references.md prima di prendere decisioni in produzione.

Qual è il problema

Croogo configura una radice modificabile ristretta come WWW_ROOT/assets. L'helper interessato ottiene FileManager.editablePaths con Configure::check() invece di Configure::read(). check() risponde se la chiave esiste; non restituisce l'elenco dei percorsi configurati. Il Booleano risultante viene poi utilizzato dal controllo di contenimento del percorso, compromettendo il confine di autorizzazione previsto.

Le operazioni di creazione e modifica del File Manager si fidano di quel controllo. Nelle condizioni descritte dal report upstream, un utente FileManager autenticato può scrivere al di fuori della radice modificabile configurata quando l'account del servizio PHP può scrivere nella posizione selezionata.

Vedi docs/technical-analysis.md per il flusso dei dati e docs/remediation.md per le indicazioni di hardening.

Contenuto del repository

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

Dimostrazione sicura più rapida

Il modello standalone spiega il bug senza eseguire un CMS vulnerabile né inviare alcuna richiesta di rete:

php demo/path_authorization_demo.php

Risultato atteso:

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

La demo crea file temporanei nella directory temporanea del sistema operativo e li rimuove prima di uscire.

PoC nel laboratorio Croogo locale

1. Prepara un laboratorio isolato

Segui docs/lab-setup.md. Collega l'applicazione solo a 127.0.0.1 e crea la directory fissa del marcatore nella stessa VM o container di Croogo:

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

Sostituisci www-data con l'account PHP-FPM o del server web nel laboratorio usa e getta.

2. Esporta i valori di autenticazione riservati al laboratorio

Ottieni l'header Cookie completo e il token CSRF di CakePHP da una richiesta legittima del File Manager nel tuo laboratorio. Non committarli mai.

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. Valida le salvaguardie senza inviare richieste

POC_VALIDATE_ONLY=1 ./poc/croogo_local_poc.sh

4. Invia la richiesta del marcatore di testo

./poc/croogo_local_poc.sh

Lo script stampa il nome del file generato e lo stato HTTP. Un reindirizzamento HTTP o una risposta di successo non costituiscono di per sé una prova; verifica il marcatore dall'interno della VM o del container di Croogo:

sudo ./poc/verify_marker.sh

Un marcatore al di fuori di WWW_ROOT/assets dimostra il fallimento dell'autorizzazione. Il marcatore è testo semplice e non è eseguibile via web.

5. Pulizia

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

Testa il repository

make test

I test confermano la sintassi della shell, rifiutano input non-loopback e di confusione URL, garantiscono che i segreti non vengano stampati durante la convalida e verificano il risultato atteso del modello standalone.

Priorità di risanamento

1. Disattiva il File Manager Admin o limitane l'uso a un insieme minimo di amministratori fidati finché non viene distribuita una correzione testata.
2. Correggi il recupero della configurazione usando Configure::read().
3. Canonicalizza sia la radice consentita sia la directory candidata, quindi esegui un controllo di contenimento sensibile ai separatori.
4. Rifiuta separatori di percorso, byte NUL e nomi non sicuri nel nome file inviato.
5. Impedisci a PHP di scrivere nel sorgente dell'applicazione e nelle posizioni eseguibili della webroot.
6. Esamina log e posizioni scrivibili usando docs/detection.md.

Il patch di utilità in patches/illustrative-hardening.patch e le indicazioni per il controller in patches/create-file-hardening-example.md sono ausili di revisione, non correzioni ufficiali del fornitore. Testali sulla branch esatta distribuita.

Uso etico

Usa questo repository solo su sistemi di tua proprietà o per i quali hai un'esplicita autorizzazione scritta a testarli. Non adattare la PoC per bersagli pubblici, payload eseguibili, persistenza, accesso alle credenziali o azioni distruttive. Vedi SECURITY.md e DISCLAIMER.md.

Licenza

MIT. Vedi LICENSE.