Le wizard setup.sh écrit systématiquement HOST=0.0.0.0 dans le .env généré (ligne 480), sans activer API_AUTH_ENABLED et sans mentionner l'authentification à l'utilisateur. Résultat : l'API FastAPI écoute sur toutes les interfaces réseau sans aucune protection.
Le .env.example a pourtant le bon comportement : HOST=0.0.0.0 est commenté (ligne 14) avec un avertissement explicite d'activer API_AUTH_ENABLED=***. Mais setup.sh` ignore cet avertissement.
Impact
Avec HOST=0.0.0.0 + auth désactivée, n'importe qui sur le LAN/WiFi/VPN peut :
Accéder à http://:8000/admin — dashboard admin complet
Lire toutes les conversations, topics mémoire, sessions
Exécuter POST /system/update (git pull + uv sync)
Exécuter POST /api/system/restart (DoS — kill du serveur)
Accéder aux tokens OAuth stockés en local
Correctif proposé
Dans setup.sh, étape 8 (génération .env) :
Code
· bash
Actuel (dangereux) :
HOST=0.0.0.0
Corrigé :
HOST=127.0.0.1
Et si l'utilisateur demande explicitement l'exposition réseau (question interactive du wizard), alors seulement écrire HOST=0.0.0.0 avec API_AUTH_ENABLED=*** + token généré automatiquement (openssl rand -hex 32`).
Autres points relevés (bonus)
Clés LiveKit dev hardcodées (setup.sh:399-401, jarvis:100) — LIVEKIT_API_KEY=***, LIVEKIT_API_SECRET=devsec...cret. Si le port LiveKit (7880) est exposé, ces credentials triviaux permettent à n'importe qui de rejoindre la room vocale. → Générer des clés aléatoires au setup.
/system/update utilise create_subprocess_shell (admin.py:233) au lieu de create_subprocess_exec avec args listés — surface d'injection plus large si le endpoint évolue pour accepter des paramètres.
/api/system/restart sans auth supplémentaire (system.py:242) — os.kill(os.getpid(), SIGTERM) exposé sans vérification au-delà du Bearer token global (lui-même désactivé par défaut).
Environnement
Version : 0.2.0 (commit actuel sur main)
Fichiers concernés : setup.sh, jarvis, src/jarvis/interfaces/api/admin.py, src/jarvis/interfaces/api/system.py
Le wizard setup.sh écrit systématiquement HOST=0.0.0.0 dans le .env généré (ligne 480), sans activer API_AUTH_ENABLED et sans mentionner l'authentification à l'utilisateur. Résultat : l'API FastAPI écoute sur toutes les interfaces réseau sans aucune protection.
Le .env.example a pourtant le bon comportement : HOST=0.0.0.0 est commenté (ligne 14) avec un avertissement explicite d'activer API_AUTH_ENABLED=***. Mais setup.sh` ignore cet avertissement.
Impact
Avec HOST=0.0.0.0 + auth désactivée, n'importe qui sur le LAN/WiFi/VPN peut :
Accéder à http://:8000/admin — dashboard admin complet
Lire toutes les conversations, topics mémoire, sessions
Exécuter POST /system/update (git pull + uv sync)
Exécuter POST /api/system/restart (DoS — kill du serveur)
Accéder aux tokens OAuth stockés en local
Correctif proposé
Dans setup.sh, étape 8 (génération .env) :
Code
· bash
Actuel (dangereux) :
HOST=0.0.0.0
Corrigé :
HOST=127.0.0.1
Et si l'utilisateur demande explicitement l'exposition réseau (question interactive du wizard), alors seulement écrire HOST=0.0.0.0 avec API_AUTH_ENABLED=*** + token généré automatiquement (openssl rand -hex 32`).
Autres points relevés (bonus)
Clés LiveKit dev hardcodées (setup.sh:399-401, jarvis:100) — LIVEKIT_API_KEY=***, LIVEKIT_API_SECRET=devsec...cret. Si le port LiveKit (7880) est exposé, ces credentials triviaux permettent à n'importe qui de rejoindre la room vocale. → Générer des clés aléatoires au setup.
/system/update utilise create_subprocess_shell (admin.py:233) au lieu de create_subprocess_exec avec args listés — surface d'injection plus large si le endpoint évolue pour accepter des paramètres.
/api/system/restart sans auth supplémentaire (system.py:242) — os.kill(os.getpid(), SIGTERM) exposé sans vérification au-delà du Bearer token global (lui-même désactivé par défaut).
Environnement
Version : 0.2.0 (commit actuel sur main)
Fichiers concernés : setup.sh, jarvis, src/jarvis/interfaces/api/admin.py, src/jarvis/interfaces/api/system.py