Audit Pass 3 - Dashboard 33800

Status : IMPLEMENTEE

Angle : INTEGRATION & CONTRATS INTER-SERVICES

Date : 15-02-2026 04:00

Auditeur : Claude Opus 4.6 (pass independante)

Resume executif

Severite	Nombre
BUG CERTAIN	7
BUG PROBABLE	8
RISQUE THEORIQUE	9
Total findings	24

Les problemes les plus graves concernent l'exposition massive de credentials en clair dans le HTML genere (secrets.html, endpoints.html) qui est pousse vers O2switch (serveur public), des mots de passe Redis et des JWT Supabase hardcodes dans collect.sh, et l'absence d'echappement des donnees SSH avant injection dans le JSON et le HTML.

Findings

F-01 : Credentials en clair dans HTML pousse vers O2switch (public)

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/generate.d/04-secrets.sh:112-199 + /stock_8to/33800-stack/monitoring/generate.d/05-endpoints.sh:162-232
Description : Les pages secrets.html et endpoints.html contiennent en clair : mots de passe (MyUlia75$w, ntfy33800, 33800admin, d9fx-RNEz-xfK(, aE1RmUsd198cTt, oIoIlGGh6t4CDBLT), tokens API (glpat-yaowLwWBJhXfzJEC8UBC, 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, ptr_8B9+nxAyk...), cles Mailjet (0e24bea8cb588b742cccf75b34a253b1 / 3cbedc00ad58e9660585af9a5b73767d). Ces fichiers HTML sont generes puis pousses via git push o2switch main (generate.sh:4912). Le .gitignore n'exclut PAS les fichiers *.html. Le dashboard est accessible a https://dashboard.nowhere84.com sur Internet.

Code concerne :

# generate.sh:4910-4912
git add -A 2>/dev/null
git commit -m "Update: $(date +%Y-%m-%d_%H:%M)" 2>/dev/null
git push o2switch main 2>/dev/null &

<!-- 04-secrets.sh:129 -->
<td><code>MyUlia75$w</code></td>
<!-- 04-secrets.sh:177 -->
<tr><td>Token</td><td><code>glpat-yaowLwWBJhXfzJEC8UBC</code></td></tr>

Impact : Tous les credentials de l'infrastructure (SSH, GitLab, Portainer, Grafana, o2switch, Mailjet, GitHub) sont exposes sur Internet via le dashboard public. Un attaquant qui accede a https://dashboard.nowhere84.com/secrets.html ou endpoints.html obtient un acces complet a l'infrastructure.
Fix suggere : Soit exclure secrets.html et endpoints.html du push O2switch (ajouter dans .gitignore), soit ne pas hardcoder les credentials dans le HTML et utiliser une page protegee par authentification cote serveur.

F-02 : Token GitLab dans l'URL du remote git origin

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/.git/config:10
Description : Le remote "origin" contient le token GitLab en clair dans l'URL : http://oauth2:glpat-yaowLwWBJhXfzJEC8UBC@192.168.1.196/gouroubleu/dashboard-33800.git. Ce fichier est dans le repertoire .git qui n'est pas pousse, mais il reste un risque de fuite si le dossier est copie ou sauvegarde.

Code concerne :

[remote "origin"]
  url = http://oauth2:glpat-yaowLwWBJhXfzJEC8UBC@192.168.1.196/gouroubleu/dashboard-33800.git

Impact : Le token GitLab est stocke en clair dans le fichier .git/config. Toute personne ayant acces en lecture au filesystem voit le token.
Fix suggere : Utiliser un credential helper git ou une variable d'environnement au lieu d'inliner le token dans l'URL.

F-03 : Mots de passe Redis hardcodes dans collect.sh

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:480-501
Description : Les mots de passe Redis PROD (urefsLoXibTZ36mtuygcLyNuqzOmIVkF) et DEV (rYfXNQRrVef2LXp8E1B06o4jiT5f5bxs) sont hardcodes en clair dans le script. Ce script est versionne dans le repo git (pousse vers GitLab et O2switch).

Code concerne :

REDIS_PROD_PING=$(ssh gouroubleu@192.168.1.12 'docker exec redis-prod redis-cli -a "urefsLoXibTZ36mtuygcLyNuqzOmIVkF" PING 2>/dev/null' | tr -d '\r\n')

REDIS_DEV_PING=$(ssh_cmd 192.168.1.51 "docker exec redis-dev redis-cli -a 'rYfXNQRrVef2LXp8E1B06o4jiT5f5bxs' PING 2>/dev/null" | tr -d '\r\n')

Impact : Les mots de passe Redis sont visibles dans l'historique git et dans le repo O2switch. Quiconque a acces au repo peut lire les mots de passe Redis.
Fix suggere : Charger les mots de passe depuis un fichier .env exclu du git, ou depuis les variables d'environnement.

F-04 : JWT Supabase (anon keys) hardcodes dans collect.sh

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:517,533
Description : Les JWT anon keys Supabase PROD et DEV sont hardcodes dans les appels curl de collect.sh. Bien que ce soient des cles "anon" (lecture publique par design), elles sont neanmoins versionnees dans le repo git pousse vers O2switch.

Code concerne :

SUPABASE_PROD_API=$(curl -s ... -H "apikey: eyJhbGciOiJIUzI1NiIs..." 2>/dev/null)

Impact : Exposition des cles anon Supabase. Impact modere car les cles anon sont conçues pour etre publiques, mais elles ne devraient pas etre dans le code versionne.
Fix suggere : Charger depuis un fichier de configuration non versionne.

F-05 : Token GitLab hardcode dans collect-gitlab.sh

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/collect-gitlab.sh:15
Description : Le token GitLab glpat-yaowLwWBJhXfzJEC8UBC est hardcode en clair dans le script de collecte GitLab. Ce script est versionne dans le repo git.

Code concerne :

GITLAB_TOKEN="glpat-yaowLwWBJhXfzJEC8UBC"

Impact : Le token donne un acces complet a l'API GitLab (lecture/ecriture de tous les projets). Il est expose dans le repo.
Fix suggere : Utiliser une variable d'environnement ou un fichier de credentials exclus du git.

F-06 : StrictHostKeyChecking=no dans toutes les connexions SSH

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/collect.d/_common.sh:39,46 + /stock_8to/33800-stack/monitoring/collect.sh:52
Description : Toutes les fonctions SSH (ssh_cmd, ssh_root) utilisent -o StrictHostKeyChecking=no. En cas de compromission DNS ou ARP spoofing sur le reseau local, un attaquant peut intercepter les connexions SSH (attaque MITM) et capturer les commandes executees (incluant les credentials Redis hardcodes).

Code concerne :

ssh_cmd() {
  local host=$1
  shift
  timeout $SSH_TIMEOUT ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no -o BatchMode=yes gouroubleu@$host "$@" 2>/dev/null || echo ""
}

Impact : Vulnerabilite MITM sur toutes les connexions SSH de collecte. Sur un reseau local controle, le risque est reduit mais reel.
Fix suggere : Utiliser StrictHostKeyChecking=accept-new au lieu de no, et maintenir un fichier known_hosts pre-rempli.

F-07 : Absence d'echappement des donnees SSH dans la generation JSON

Severite : BUG CERTAIN
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:985-1029
Description : Les fonctions vms_to_json, containers_to_json et sites_to_json construisent du JSON par concatenation de strings sans echapper les caracteres speciaux JSON (guillemets, backslashes, etc.). Le champ status est partiellement echappe avec sed 's/"/\\"/g', mais les champs name, target, restrict, auth ne sont pas du tout echappes. Si un nom de container ou un nom de site nginx contient un guillemet, le JSON sera invalide.

Code concerne :


containers_to_json() {
  local containers=$1
  # ...
  status=$(echo "$status" | sed 's/"/\\"/g')
  # name et port ne sont PAS echappes
  result+="{\"name\":\"$name\",\"status\":\"$status\",\"port\":\"$port\"}"
}

sites_to_json() {

name, target, restrict, auth ne sont PAS echappes

result+="{\"name\":\"$name\",\"target\":\"$target\",\"access\":\"$restrict\",\"auth\":\"$auth\"}"

}

- **Impact** : Si un nom de container Docker ou un nom de site nginx contient un guillemet ou un backslash, le fichier current.json devient du JSON invalide, ce qui casse tout le dashboard. Ce cas peut se produire si un container est deploye avec un nom atypique.
- **Fix suggere** : Utiliser `jq` pour construire le JSON au lieu de la concatenation manuelle, ou echapper tous les champs avec une fonction dediee.

---

### F-08 : IP PVE inconsistante dans config.json vs code reel
- **Severite** : BUG PROBABLE
- **Fichier** : `/stock_8to/33800-stack/monitoring/config.json:4-5`
- **Description** : config.json declare `"ip": "192.168.1.10"` pour PVE, avec un champ additionnel `"ip_main": "192.168.1.4"`. Or, dans CLAUDE.md la machine PVE est referencee a `192.168.1.4`. Tous les scripts de collecte (collect.sh, collect.d/01-pve.sh) utilisent `192.168.1.10` en dur. Si PVE a deux IPs (une principale 192.168.1.4 et une autre 192.168.1.10), la distinction `ip` vs `ip_main` dans config.json pretent a confusion. De plus, `get_host_ip("pve")` retournerait `192.168.1.10` alors que la "vraie" IP principale est .4.
- **Code concerne** :
```json
"pve": {
    "ip": "192.168.1.10",
    "ip_main": "192.168.1.4",

Impact : Si un generate.d module utilise get_host_ip("pve"), il obtiendra .10 au lieu de .4. Les scripts collect.d sont hardcodes sur .10 donc ils fonctionnent, mais la semantique de config.json est ambigue.
Fix suggere : Documenter clairement quel IP est quoi (vmbr0 vs vmbr1) ou normaliser un seul champ "ip" vers l'IP de management reelle.

F-09 : Port browser-connector incorrect dans config.json

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/config.json:161
Description : config.json declare "browser-connector": {"port": 5401} alors que CLAUDE.md (section "Ports services") indique explicitement : "browser-connector: port 5404 (pas 5401)". Cependant, le script collect.d/09-linkedin.sh utilise le port 5401 (BROWSER_PORT=5401) et semble fonctionner.

Code concerne :

"browser-connector": {
  "host": "prod-portainer",
  "port": 5401,

Impact : Incoherence entre config.json et la documentation CLAUDE.md. L'un des deux est faux. Si le port reel est 5404 et que le code utilise 5401, les health checks echouent.
Fix suggere : Verifier le port reel du browser-connector et synchroniser config.json et CLAUDE.md.

F-10 : Port connectors-api potentiellement incorrect dans config.json

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/config.json:155
Description : config.json declare "connectors-api": {"port": 5400} alors que CLAUDE.md indique "connectors-api: port 5403 (derriere wireguard sidecar, pas 5400)". Selon le contexte, 5400 est le port interne (dans le container) et 5403 est le port expose/route via wireguard.

Code concerne :

"connectors-api": {
  "host": "prod-portainer",
  "port": 5400,

Impact : Un health check depuis l'exterieur du container sur le port 5400 pourrait echouer si le port expose est 5403.
Fix suggere : Documenter clairement dans config.json si le port est le port interne ou le port expose, ou ajouter un champ external_port.

F-11 : collect.sh n'a pas de `set -e` et masque les erreurs avec `2>/dev/null`

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:6
Description : Le script documente "set -e retire car le script gere ses propres erreurs" mais en realite, les erreurs sont simplement ignorees par 2>/dev/null || echo "". Cela signifie que si une commande SSH retourne une erreur (auth failure, timeout), le script continue avec des valeurs vides ou "0" sans signaler le probleme. Combine avec l'absence de validation des valeurs avant insertion dans le JSON, cela produit silencieusement un JSON avec des valeurs manquantes ou invalides.

Code concerne :

# Note: set -e retiré car le script gère ses propres erreurs
# ...
ssh_cmd() {
  timeout $SSH_TIMEOUT ssh ... "$@" 2>/dev/null || echo ""
}

Impact : Les erreurs de collecte sont silencieusement ignorees. Le dashboard peut afficher des donnees obsoletes ou des zeros sans que personne ne le remarque.
Fix suggere : Logger les erreurs SSH (au minimum dans un fichier de log) au lieu de les supprimer avec 2>/dev/null.

F-12 : Variables non quotees dans ssh_cmd et check_ping

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/collect.d/_common.sh:37-39
Description : Dans ssh_cmd(), la variable $host n'est pas quotee dans l'appel SSH : gouroubleu@$host. Si $host contient des espaces ou caracteres speciaux (improbable pour des IPs mais possible pour des hostnames), cela causerait une erreur. De meme, check_ping ne quote pas $host.

Code concerne :

ssh_cmd() {
  local host=$1
  shift
  timeout $SSH_TIMEOUT ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no -o BatchMode=yes gouroubleu@$host "$@" 2>/dev/null || echo ""
}

Impact : Risque de comportement inattendu si un hostname contient des caracteres speciaux. En pratique, les IPs numeriques ne posent pas ce probleme.
Fix suggere : Quoter : gouroubleu@"$host".

F-13 : `git add -A` dans generate.sh pousse tout vers O2switch

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/generate.sh:4910
Description : La commande git add -A ajoute TOUS les fichiers non-gitignored au commit, incluant potentiellement des fichiers sensibles crees entre deux commits (ex: des fichiers .json temporaires dans data/, des fichiers de collecte). Le .gitignore est minimal et n'exclut que current.json (racine), history/*.json, logs/, archives/, downloads/. Les fichiers .html generes (dont secrets.html) sont pousses.

Code concerne :

git add -A 2>/dev/null
git commit -m "Update: $(date +%Y-%m-%d_%H:%M)" 2>/dev/null
git push o2switch main 2>/dev/null &

Impact : Tout nouveau fichier cree dans le dossier monitoring est automatiquement pousse vers O2switch sans verification.
Fix suggere : Remplacer git add -A par git add explicite des fichiers attendus, ou enrichir le .gitignore pour exclure les fichiers sensibles.

F-14 : services-registry.json est owned par root avec permissions 600

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/services-registry.json (permissions: -rw------- root root)
Description : Le fichier services-registry.json a les permissions 600 et est owned par root, alors que le script generate.sh s'execute en tant que gouroubleu. La commande chown -R gouroubleu:gouroubleu *.json data/ (generate.sh:4909) tente de corriger les permissions mais chown sur un fichier owned par root necessite sudo. Le || true masque l'erreur.

Code concerne :

chown -R gouroubleu:gouroubleu *.json data/ 2>/dev/null || true

Impact : services-registry.json ne peut pas etre lu par le script generate.sh (owner root, mode 600). Si un module de generation en a besoin, il echouera silencieusement.
Fix suggere : Corriger les permissions (sudo chown gouroubleu:gouroubleu services-registry.json) ou s'assurer que generate.sh tourne avec les privileges adequats.

F-15 : Pas de nettoyage de /tmp/monitoring-buffer

Severite : BUG PROBABLE
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:32 + /stock_8to/33800-stack/monitoring/collect.d/_common.sh:16
Description : Le dossier /tmp/monitoring-buffer est cree et rempli a chaque execution de collect.sh, mais il n'est jamais nettoye. Les fichiers JSON dans ce buffer contiennent des donnees d'infrastructure (etats ZFS, statistiques). Le trap en ligne 20 ne nettoie que le lockfile, pas le buffer.

Code concerne :

BUFFER_DIR="/tmp/monitoring-buffer"
mkdir -p "$BUFFER_DIR" "$MONITORING_DIR/history" "$LOGS_DIR"
# ... aucun cleanup de BUFFER_DIR
trap "rm -f $LOCKFILE" EXIT

Impact : Accumulation de fichiers temporaires dans /tmp. Faible risque de fuite d'information si /tmp est partage entre utilisateurs.
Fix suggere : Ajouter rm -rf "$BUFFER_DIR" au trap EXIT.

F-16 : SSH PROD Redis utilise ssh directe au lieu de ssh_cmd

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:480-485
Description : Les commandes Redis PROD utilisent ssh gouroubleu@192.168.1.12 sans ssh_cmd (pas de timeout, pas de BatchMode, pas de ConnectTimeout). Si le serveur est lent a repondre, le script peut bloquer indefiniment.

Code concerne :

REDIS_PROD_PING=$(ssh gouroubleu@192.168.1.12 'docker exec redis-prod redis-cli -a "urefsLoXibTZ36mtuygcLyNuqzOmIVkF" PING 2>/dev/null' | tr -d '\r\n')

Impact : Le script de collecte peut bloquer si le serveur PROD ne repond pas au SSH.
Fix suggere : Utiliser ssh_cmd 192.168.1.12 a la place de ssh gouroubleu@192.168.1.12.

F-17 : data-loader.js - innerHTML avec donnees non echappees

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/assets/data-loader.js:28,86
Description : data-loader.js utilise innerHTML pour inserer des donnees dans le DOM : (1) le message d'erreur (ligne 28) inclut error.message dans du HTML via template literal, (2) statusBadge() (ligne 86) insere la valeur de status directement dans du HTML. Si current.json contient des donnees malformees (ex: un statut qui contient du HTML), cela pourrait mener a du XSS.

Code concerne :

errorDiv.innerHTML = `<span style="color: var(--red);">Erreur chargement données: ${error.message}</span>`;
// ...
function statusBadge(status) {
  return `<span class="status status-${color}">${status}</span>`;
}

Impact : Risque de XSS si un attaquant peut injecter du contenu dans current.json (faible risque car le fichier est genere cote serveur). En pratique, le dashboard est consultable uniquement par l'administrateur.
Fix suggere : Utiliser textContent au lieu de innerHTML, ou echapper les donnees avant insertion.

F-18 : Duplication massive de code entre generate.sh et generate.d/

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/generate.sh (4935 lignes) + /stock_8to/33800-stack/monitoring/generate.d/*.sh
Description : generate.sh contient des fallbacks inline enormes (pages entieres de HTML) pour chaque module. Par exemple, le bloc secrets dans generate.sh (lignes ~3090-3240) est un duplicata complet de generate.d/04-secrets.sh. De meme, le bloc endpoints est duplique. De plus, il y a 3 systemes de templates differents : templates.sh (html_head/html_header/html_footer), generate.d/_common.sh (gen_html_head/gen_header/gen_footer), et les fonctions inline de generate.sh (generate_html_head/generate_header/generate_footer). Les navigations ne sont pas synchronisees entre ces 3 systemes.
Code concerne : Navigation dans templates.sh (11 liens), generate.d/_common.sh (14 liens), generate.sh (14 liens avec schema+o2switch), generate.d/01-index.sh (17 liens avec ai-tools+orchestrator+syncthing+linkedin), nav.js (18 liens avec ai-tools+orchestrator+syncthing+linkedin+schema+o2switch).
Impact : Les pages generees par differents modules ont des navigations differentes. Certaines pages n'apparaissent pas dans la navigation d'autres pages. Difficulte de maintenance extreme.
Fix suggere : Centraliser la navigation dans un seul endroit (soit nav.js cote client, soit une seule fonction shell).

F-19 : Race condition lors du push O2switch en background

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/generate.sh:4912
Description : git push o2switch main 2>/dev/null & est execute en arriere-plan. Si une nouvelle execution de generate.sh demarre avant que le push ne soit termine, le prochain git add -A && git commit pourrait entrer en conflit avec le push en cours (git lock file).

Code concerne :

git push o2switch main 2>/dev/null &
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Push O2switch en background"

Impact : Le push pourrait echouer silencieusement si deux executions se chevauchent. Le 2>/dev/null masque l'erreur.
Fix suggere : Ne pas lancer le push en background, ou utiliser un lock pour le push.

F-20 : collect.sh - Injection de commandes via noms de containers

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:866-888
Description : La fonction collect_container_schedulers itere sur les noms de containers Docker et les utilise directement dans des commandes SSH (docker cp $container:...). Si un nom de container contient des caracteres speciaux shell (espace, point-virgule, backtick), cela pourrait mener a une injection de commande.

Code concerne :

for container in $containers; do
  local manifest=$(ssh_cmd "$host" "docker cp $container:/app/scheduler.json ...")

Impact : Faible en pratique car les noms de containers Docker sont controles. Neanmoins, le pattern est dangereux.
Fix suggere : Quoter la variable $container dans les commandes SSH.

F-21 : Notification JSON non echappee dans generate.sh

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/generate.sh:4929-4932
Description : La notification push construit un JSON avec des variables non echappees. Si NOTIF_TITLE ou NOTIF_BODY contient des guillemets, le JSON sera invalide et la notification echouera.

Code concerne :


NOTIF_TITLE="Dashboard généré ✓"
NOTIF_BODY="${PAGES_COUNT} pages - ${TIMESTAMP}
https://dashboard.nowhere84.com"

curl -s -X POST "http://192.168.1.12:5300/api/notify/push" \ -H "Content-Type: application/json" \ -d "{\"title\": \"${NOTIF_TITLE}\", \"body\": \"${NOTIF_BODY}\", \"level\": \"info\"}"

- **Impact** : Le newline dans NOTIF_BODY casse le JSON. La notification echoue probablement a chaque execution. Le `|| echo` masque l'erreur.
- **Fix suggere** : Utiliser `jq` pour construire le JSON, ou echapper les newlines.

---

### F-22 : audit-notify.sh - Injection JSON dans le body de notification
- **Severite** : RISQUE THEORIQUE
- **Fichier** : `/stock_8to/33800-stack/monitoring/audit-notify.sh:59-62`
- **Description** : Le body de notification inclut la variable `$BODY` qui contient des backslash-n et des details extraits de la sortie de l'audit. Ces details ne sont pas echappes pour JSON, ce qui peut casser le JSON si les messages d'audit contiennent des guillemets.
- **Code concerne** :
```bash
BODY="Score: $PASSED/$TOTAL checks OK\nCritical: $CRITICAL\nWarning: $WARNING\n\nDetails:\n$DETAILS"

curl -s -X POST "$NOTIF_URL" \
    -H "Content-Type: application/json" \
    -d "{\"title\": \"$TITLE\", \"body\": \"$BODY\", \"level\": \"$LEVEL\"}"

Impact : Les notifications d'audit echouent si le contenu contient des caracteres speciaux JSON.
Fix suggere : Utiliser jq -n --arg body "$BODY" --arg title "$TITLE" '{title: $title, body: $body, level: "warning"}'.

F-23 : config.json - vscode IP potentiellement obsolete

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/config.json:47-51
Description : config.json declare une machine vscode a l'IP 192.168.1.154, mais cette machine n'apparait pas dans les scripts de collecte (pas de collect.d module pour vscode) et n'est pas referencee dans CLAUDE.md comme une VM active. Le label "VSCode" fait penser a l'editeur web (Coder), qui est normalement un service Docker, pas une VM dediee.

Code concerne :

"vscode": {
  "ip": "192.168.1.154",
  "mdns": "vscode.local",
  "label": "VSCode"
},

Impact : Entree potentiellement obsolete dans config.json. Pas d'impact fonctionnel si elle n'est pas referencee.
Fix suggere : Verifier si cette VM existe toujours et supprimer l'entree si elle est obsolete.

F-24 : Lockfile de collect.sh vulnerables au PID reuse

Severite : RISQUE THEORIQUE
Fichier : /stock_8to/33800-stack/monitoring/collect.sh:10-20
Description : Le mecanisme de lockfile ecrit le PID dans /tmp/collect-monitoring.lock et verifie avec kill -0. Si le processus d'origine se termine et qu'un nouveau processus (sans rapport) recoit le meme PID, la verification kill -0 reussira et le lock sera considere comme actif alors qu'il ne l'est plus. De plus, entre la verification et la creation du lockfile, il y a une race condition (TOCTOU).

Code concerne :

LOCKFILE="/tmp/collect-monitoring.lock"
if [ -f "$LOCKFILE" ]; then
  LOCK_PID=$(cat "$LOCKFILE" 2>/dev/null)
  if [ -n "$LOCK_PID" ] && kill -0 "$LOCK_PID" 2>/dev/null; then
      echo "[$(date)] Collecte déjà en cours (PID $LOCK_PID), abandon."
      exit 0
  fi
  rm -f "$LOCKFILE"
fi
echo $$ > "$LOCKFILE"

Impact : En theorie, deux instances concurrentes pourraient s'executer simultanement, ou une instance pourrait etre bloquee indefiniment. En pratique, le cron toutes les heures et la duree d'execution courte minimisent ce risque.
Fix suggere : Utiliser flock au lieu d'un lockfile PID.

Synthese par theme

Securite des credentials (CRITIQUE)

F-01 (BUG CERTAIN) : Tous les mots de passe et tokens de l'infra sont dans du HTML pousse sur Internet
F-02 (BUG CERTAIN) : Token GitLab dans l'URL git remote
F-03 (BUG CERTAIN) : Redis passwords hardcodes dans le code versionne
F-04 (BUG CERTAIN) : JWT Supabase hardcodes dans le code versionne
F-05 (BUG CERTAIN) : Token GitLab hardcode dans collect-gitlab.sh
F-13 (BUG PROBABLE) : git add -A pousse tout sans filtrage

Integration SSH

F-06 (BUG CERTAIN) : StrictHostKeyChecking=no systematique
F-11 (BUG PROBABLE) : Erreurs SSH masquees silencieusement
F-12 (BUG PROBABLE) : Variables non quotees dans les appels SSH
F-16 (RISQUE THEORIQUE) : SSH sans timeout pour Redis PROD

Coherence config.json

F-08 (BUG PROBABLE) : IP PVE ambigue (ip vs ip_main)
F-09 (BUG PROBABLE) : Port browser-connector possiblement incorrect
F-10 (BUG PROBABLE) : Port connectors-api possiblement incorrect
F-23 (RISQUE THEORIQUE) : Entree vscode possiblement obsolete

Generation HTML / Echappement

F-07 (BUG CERTAIN) : Pas d'echappement JSON pour les donnees SSH
F-17 (RISQUE THEORIQUE) : innerHTML avec donnees non echappees (XSS)
F-18 (RISQUE THEORIQUE) : Navigation desynchronisee entre 4 systemes de templates
F-21 (RISQUE THEORIQUE) : Newline casse le JSON de notification

Scripts bash

F-14 (BUG PROBABLE) : Permissions root sur services-registry.json
F-15 (BUG PROBABLE) : Pas de cleanup du buffer /tmp
F-19 (RISQUE THEORIQUE) : Race condition git push en background
F-20 (RISQUE THEORIQUE) : Noms de containers non quotes dans SSH
F-22 (RISQUE THEORIQUE) : Injection JSON dans audit-notify.sh
F-24 (RISQUE THEORIQUE) : Lockfile PID vulnerable au PID reuse

Deploiement O2switch

Le deploiement se fait via git push o2switch main vers un bare repo sur O2switch. Le transport utilise une connexion SSH (o2switch:repositories/dashboard.git). Le transfert est securise par SSH. Cependant, le contenu pousse inclut secrets.html et endpoints.html contenant tous les credentials en clair (cf. F-01).

Audit Pass 3 - Dashboard 33800

Angle : INTEGRATION & CONTRATS INTER-SERVICES

Date : 15-02-2026 04:00

Auditeur : Claude Opus 4.6 (pass independante)

Resume executif

Findings

F-01 : Credentials en clair dans HTML pousse vers O2switch (public)

F-02 : Token GitLab dans l'URL du remote git origin

F-03 : Mots de passe Redis hardcodes dans collect.sh

F-04 : JWT Supabase (anon keys) hardcodes dans collect.sh

F-05 : Token GitLab hardcode dans collect-gitlab.sh

F-06 : StrictHostKeyChecking=no dans toutes les connexions SSH

F-07 : Absence d'echappement des donnees SSH dans la generation JSON

name, target, restrict, auth ne sont PAS echappes

F-09 : Port browser-connector incorrect dans config.json

F-10 : Port connectors-api potentiellement incorrect dans config.json

F-11 : collect.sh n'a pas de set -e et masque les erreurs avec 2>/dev/null

F-12 : Variables non quotees dans ssh_cmd et check_ping

F-13 : git add -A dans generate.sh pousse tout vers O2switch

F-14 : services-registry.json est owned par root avec permissions 600

F-15 : Pas de nettoyage de /tmp/monitoring-buffer

F-16 : SSH PROD Redis utilise ssh directe au lieu de ssh_cmd

F-17 : data-loader.js - innerHTML avec donnees non echappees

F-18 : Duplication massive de code entre generate.sh et generate.d/

F-19 : Race condition lors du push O2switch en background

F-20 : collect.sh - Injection de commandes via noms de containers

F-21 : Notification JSON non echappee dans generate.sh

F-23 : config.json - vscode IP potentiellement obsolete

F-24 : Lockfile de collect.sh vulnerables au PID reuse

Synthese par theme

Securite des credentials (CRITIQUE)

Integration SSH

Coherence config.json

Generation HTML / Echappement

Scripts bash

Deploiement O2switch

F-11 : collect.sh n'a pas de `set -e` et masque les erreurs avec `2>/dev/null`

F-13 : `git add -A` dans generate.sh pousse tout vers O2switch