Bazarr CVE-2026-61826 : l'API Plex accessible sans authentification (CVSS 10/10)

CVE-2026-61826 : tout le namespace API Plex ouvert sans authentification

Le 30 octobre 2026, le NIST a publié CVE-2026-61826, une vulnérabilité critique dans Bazarr, l'application web compagnon de Sonarr et Radarr utilisée pour gérer automatiquement les sous-titres sur un serveur multimédia auto-hébergé. Le score CVSS v3.1 atteint 10/10, la note maximale : n'importe qui peut accéder sans mot de passe ni login à l'intégralité du namespace API Plex de Bazarr (avis de sécurité GitHub, GHSA-fvcv-hh55-x3r4). Toutes les versions antérieures à 1.5.7-beta.14 sont vulnérables.

Si vous hébergez votre propre stack multimédia (Sonarr, Radarr, Bazarr, Plex ou Emby) sur un VPS Linux ou un serveur dédié, cet article détaille la faille, son impact et les mesures à prendre pour sécuriser vos configurations. Les administrateurs qui ont lu notre article sur Plex2Shell retrouveront un thème familier : une application web auto-hébergée dont une partie de l'API est restée sans protection.

Bazarr et la stack *arr : Sonarr, Radarr, Prowlarr

Bazarr est un logiciel open source écrit en Python (Flask) qui s'intègre à Sonarr (séries) et Radarr (films) pour télécharger et synchroniser automatiquement les sous-titres depuis des fournisseurs comme OpenSubtitles ou Addic7ed. Dans une stack *arr typique auto-hébergée sur un serveur virtuel, Bazarr communique avec Sonarr, Radarr et le serveur multimédia (Plex ou Emby) via leurs API respectives en utilisant des protocoles HTTP internes.

De nombreux admin système déploient cette stack sur un VPS sous Ubuntu ou Debian avec Docker Compose et un reverse proxy Nginx. Chaque application web de la stack (Sonarr sur le port 8989, Radarr sur 7878, Bazarr sur 6767) écoute sur un port dédié et possède son propre système de login avec mots de passe. Le problème survient quand Bazarr est exposé directement sur internet sans couche d'authentification réseau, ce que CVE-2026-61826 rend particulièrement dangereux.

La faille : zéro authentification sur les endpoints Plex

Dans Bazarr 1.5.6 et versions antérieures, le namespace complet de l'API Plex OAuth (fichier bazarr/api/plex/oauth.py) ne porte aucun décorateur d'authentification. Les 65 autres gestionnaires d'API de Bazarr utilisent le décorateur @authenticate pour vérifier l'identité de l'appelant avant d'autoriser l'accès. Le namespace Plex, lui, est entièrement ouvert (CWE-306 : Missing Authentication for Critical Function).

Les endpoints exposés sans authentification sont :

Un problème secondaire aggrave la situation : la validation du jeton d'état (state token) dans PlexPinCheck utilise une logique non contraignante (if state_param:). Omettre le paramètre suffit à contourner la vérification CSRF (CWE-352).

Impact concret pour un administrateur de serveur

Un attaquant distant non authentifié peut, sans aucun mot de passe ni login :

• Voler la clé API Plex : l'endpoint /api/plex/select-server déclenche des requêtes HTTP sortantes qui transmettent la clé API Plex dans l'en-tête X-Plex-Token. L'attaquant récupère le jeton en pointant l'URL vers un serveur qu'il contrôle (SSRF, CWE-918).
• Prendre le contrôle de l'intégration : il peut lier son propre compte Plex à votre instance Bazarr, modifier la configuration du serveur et persister dans votre infrastructure multimédia.
• Couper Bazarr de Plex : un simple appel à /api/plex/oauth/logout supprime les identifiants Plex de façon persistante. L'admin doit alors reconfigurer manuellement l'intégration depuis l'interface web.

Combinée avec la chaîne d'exploitation Plex2Shell (corrigée en Plex 1.43.3, quatre CVE chaînées pour obtenir l'exécution de code), un serveur hébergeant Plex et Bazarr non mis à jour offre deux vecteurs d'attaque indépendants. Bazarr permet de voler le jeton Plex sans même exploiter Plex directement.

Vérifier si votre instance est exposée

Avant de mettre à jour, vérifiez si votre Bazarr est accessible depuis internet. Connectez-vous à votre VPS en SSH (en ligne de commande depuis un terminal) et contrôlez les connexions actives sur le port 6767 :

ss -tlnp | grep 6767

Si Bazarr écoute sur 0.0.0.0:6767 (toutes les adresses IP), il est potentiellement accessible depuis internet. Vérifiez ensuite les règles de votre firewall. Avec UFW sur Ubuntu ou Debian :

sudo ufw status verbose | grep 6767

Si le port est ouvert dans le firewall, consultez les logs d'accès de Bazarr pour repérer des connexions suspectes depuis des adresses IP inconnues. Les fichiers log se trouvent dans le répertoire de config de Bazarr (/config/log/bazarr.log sous Docker, /opt/bazarr/data/log/bazarr.log en installation native) :

grep -i "plex" /opt/bazarr/data/log/bazarr.log | tail -50

Si vous repérez des requêtes vers les endpoints /api/plex/ provenant d'adresses IP que vous ne reconnaissez pas, votre instance a peut-être été ciblée. Changez immédiatement les mots de passe et clés API de Plex, puis suivez la procédure de mise à jour ci-dessous.

Versions affectées et correctif

Le correctif ajoute le décorateur @authenticate sur tous les endpoints du namespace Plex OAuth, alignant leur protection sur les 65 autres gestionnaires d'API de Bazarr. La vulnérabilité a été signalée par le chercheur ildkh et le correctif vérifié par CyberKareem.

Mettre à jour Bazarr

Avant toute mise à jour, effectuez un backup de la configuration de Bazarr. Avec Docker, sauvegardez le volume contenant le répertoire /config. En installation native, copiez le répertoire de données. Ce backup vous permet de restaurer les configurations en cas de problème :

# Backup du répertoire de config (Docker)
docker cp bazarr:/config ./bazarr-backup-$(date +%Y%m%d)

# Backup du répertoire de config (natif)
cp -r /opt/bazarr/data ./bazarr-backup-$(date +%Y%m%d)

Si vous avez installé Bazarr avec Docker, tirez la dernière image et recréez le conteneur depuis la ligne de commande :

docker compose pull bazarr
docker compose up -d bazarr

Si Bazarr est installé en natif (pip ou clone du dépôt) sur Ubuntu ou Debian, mettez à jour le package depuis le dépôt GitHub officiel et redémarrez le service :

cd /opt/bazarr
git pull
pip install -r requirements.txt
sudo systemctl restart bazarr

Vérifiez la version dans l'interface web de Bazarr (menu System, puis Status). La version affichée doit être 1.5.7-beta.14 ou supérieure. Contrôlez les logs après le redémarrage pour confirmer que le service fonctionne correctement :

docker logs bazarr --tail 20
# ou en natif :
journalctl -u bazarr --no-pager -n 20

Sécuriser votre stack *arr sur un VPS

Cette faille illustre un principe fondamental : les applications web de gestion de médias (Sonarr, Radarr, Bazarr, Prowlarr) n'ont pas vocation à être exposées directement sur internet. Leurs interfaces web sont des outils d'administration interne. Voici comment configurer votre serveur pour les protéger correctement.

• Configurer le firewall pour bloquer les ports applicatifs : Bazarr écoute par défaut sur le port 6767, Sonarr sur 8989, Radarr sur 7878. Fermez ces ports dans votre firewall (guide sécurisation VPS Ubuntu). Seul le reverse proxy doit pouvoir joindre ces services en local. Sur Ubuntu et Debian avec UFW :

sudo ufw deny 6767
sudo ufw deny 8989
sudo ufw deny 7878
sudo ufw reload

• Reverse proxy avec authentification et certificat SSL : un reverse proxy Nginx configuré avec auth_basic ou OAuth2 Proxy ajoute une couche de login indépendante de celle de l'application web. Même si Bazarr oublie un décorateur, l'accès reste protégé par un mot de passe au niveau du serveur web. Le certificat SSL (Let's Encrypt) chiffre les connexions entre le navigateur et le serveur, empêchant l'interception des mots de passe et clés API en transit sur les protocoles HTTP.
• Accès par VPN uniquement : pour un niveau de sécurité maximal, configurez un VPN (WireGuard sur VPS Linux) et restreignez l'accès aux interfaces d'administration à l'adresse IP du tunnel VPN. Aucune connexion depuis internet public ne peut atteindre Bazarr.
• Surveiller les connexions réseau : surveillez les connexions sur votre VPS pour détecter tout trafic suspect vers les ports des applications web *arr. Un script de monitoring automatisé vous alerte si une adresse IP inconnue établit une connexion.
• Mises à jour automatiques des packages système : activez les mises à jour automatiques de sécurité pour les packages système sur Ubuntu et Debian. Pour les conteneurs Docker, Watchtower ou un script cron qui exécute docker compose pull && docker compose up -d garantit que les correctifs s'appliquent sans intervention manuelle.
• Réseau Docker interne : dans votre fichier compose.yaml, créez un réseau Docker internal: true pour les services *arr. Seul le reverse proxy a accès au réseau externe. Les conteneurs communiquent entre eux sans jamais être joignables depuis internet.
• Backup régulier des configurations : sauvegardez votre VPS avec rsync pour conserver un backup hors site de toutes vos configurations. En cas de compromission, vous pouvez restaurer un état sain configuré avant l'incident.
• Sécuriser l'accès SSH : configurez l'authentification SSH par clé et désactivez le login par mot de passe. L'accès admin en ligne de commande à votre serveur est le point d'entrée le plus critique : un attaquant qui obtient un accès SSH a le contrôle total sur toutes les applications web hébergées, Bazarr inclus.