Sonarr ouvre la bêta v5 et remplace l’auth basique par l’OIDC
Le 12 octobre 2026, Sonarr annonce la bêta v5, sa première version majeure depuis près de deux ans, avec une interface refondue, l’OIDC et le blocage des extensions malveillantes dans les torrents. Si votre instance est exposée derrière un reverse proxy, la v5 est le bon prétexte pour passer enfin à une authentification solide.
12 octobre 2026. L’équipe Sonarr annonce la bêta v5 sur son forum, « presque 1 000 commits par presque 100 contributeurs » depuis la v4. 16 octobre 2026. La version 5.0.0.2635 est publiée sur la branche develop. 12 octobre 2026. Une compétition communautaire s’ouvre pour choisir les futurs messages de chargement de l’application. Pourquoi c’est important : Sonarr abandonne l’authentification basique au profit de l’OIDC, et bloque désormais les extensions malveillantes dans les torrents — deux changements de fond pour un logiciel que beaucoup exposent à tort sur Internet.
La bêta la plus importante depuis la v4
Sonarr, l’un des piliers de la stack Servarr aux côtés de Radarr et Lidarr, automatise la récupération des séries : il surveille des flux RSS, trie les sorties, les renomme et les déplace. Sortie il y a près de deux ans, la v4 avait déjà apporté le passage à .NET, les Custom Formats et l’authentification obligatoire par défaut. La v5 s’attaque à la suite : l’interface, la recherche, et surtout la sécurité.
La bêta est proposée sur la branche develop, et l’équipe prévient d’emblée : le retour en v4 est impossible sans restaurer une sauvegarde de la base. Les images Docker :develop de Hotio et LinuxServer.io ont été informées, et les binaires natifs Windows, macOS, Linux et FreeBSD sont disponibles.
L’auth basique disparaît, l’OIDC arrive
Le changement le plus structurant tient en deux lignes de l’annonce : « Basic auth a été supprimé pour des raisons de sécurité, l’auth par formulaire est désormais le défaut » et « Nouvelle option d’authentification OIDC ». Concrètement, une instance Sonarr ne s’ouvrira plus derrière un simple couple utilisateur/mot de passe passé dans l’en-tête HTTP.
C’est une décision cohérente avec la réalité du terrain. Sonarr est régulièrement pointé comme l’exemple type de l’application self-hosted exposée sur Internet alors qu’elle n’était pas conçue pour ça : l’auth basique, transmise en clair hors TLS et sans gestion fine des sessions, offrait une protection de façade. Le support OIDC ouvre la porte aux fournisseurs d’identité que les homelabs sérieux utilisent déjà — Authelia, Authentik, Keycloak — et permet l’authentification unique avec le reste de la stack.
La conséquence pratique est immédiate : si votre Sonarr est derrière un reverse proxy qui portait lui-même l’auth basique, vous allez devoir reconfigurer la chaîne d’authentification lors du passage en v5.
Le fond du problème est connu de tous ceux qui ont déjà exposé un service self-hosted. L’auth basique encode l’identifiant et le mot de passe en Base64 dans l’en-tête Authorization — ce n’est pas du chiffrement, et sans TLS les identifiants circulent en clair. S’y ajoutent l’absence de vraie session (le navigateur renvoie le couple à chaque requête), l’impossibilité de révoquer un utilisateur sans tout reconfigurer, et aucune protection native contre la force brute. L’OIDC déplace cette responsabilité vers un fournisseur d’identité dédié : connexion unique, révocation centralisée, et surtout MFA possible à l’entrée — ce que l’auth basique ne permettait pas.
Le blocage des extensions malveillantes
Le second changement de sécurité est moins visible mais tout aussi utile : Sonarr peut désormais empêcher l’envoi au client de téléchargement des torrents contenant des extensions de fichier malveillantes (.lnk, .scr, .exe, .vbs et consorts). Le chemin est prévu pour s’étendre : la feuille de route mentionne un blocage au niveau du client — empêcher le téléchargement de certains fichiers tout en laissant Sonarr traiter la sortie comme échouée — en commençant par qBittorrent.
Pour un outil qui récupère des torrents issus de sources publiques, c’est une protection concrète contre les archives piégées qui tentent d’exécuter du code sur la machine qui héberge la bibliothèque.
Le scénario d’attaque est précis. Un torrent piégé embarque un fichier au nom anodin mais à l’extension exécutable — par exemple episode.s01e01.mkv.lnk ou cover.jpg.exe — qui, ouvert ou déclenché par l’indexation, exécute un script. Sur un poste Windows qui sert aussi de machine de téléchargement, c’est la porte d’entrée d’un stealer ou d’un rançongiciel. Bloquer ces extensions en amont, avant même que le fichier n’atteigne le client, supprime la fenêtre d’exposition — et la future extension au niveau du client, à commencer par qBittorrent, fermera le cas où l’archive est décompressée après coup.
Une interface refondue et une recherche repensée
L’interface est entièrement redessinée : navigation, tableaux, boîtes de dialogue et comportement responsive revus, avec une accessibilité améliorée (navigation clavier, lecteurs d’écran, gestion du focus) et une nouvelle page Statistiques pour voir sa bibliothèque d’un coup d’œil.
La recherche change aussi en profondeur :
- La recherche interactive est virtualisée — plus de gel d’interface sur des milliers de résultats — avec des explications plus claires sur les raisons d’acceptation ou de rejet d’une sortie, et un filtre par titre.
- Les Release Profiles deviennent plus puissants : un même profil peut s’appliquer à plusieurs indexeurs.
- Le parsing des sorties gagne en robustesse sur les noms difficiles, les groupes non-ASCII et les sorties multi-épisodes ou multi-saisons.
Côté métadonnées, Sonarr peut désormais lire TMDb comme alternative à TheTVDB, utiliser des métadonnées TVDB dans d’autres langues que l’anglais, et choisir l’ordre des épisodes (DVD ou streaming) au moment de l’ajout d’une série.
Ce chantier préfigure aussi l’avenir du reste de la famille Servarr. Radarr et Lidarr partagent le même socle et la même politique de sécurité : quand Sonarr supprime l’auth basique, c’est un signal de ce qui attend les deux autres à leur prochaine version majeure. Pour un homelab qui héberge les trois derrière le même Authentik ou Authelia, la bascule vers l’OIDC se fera de toute façon selon la même mécanique.
Ce qu’il faut vérifier avant de migrer
La v5 reste une bêta : les migrations de base de données sont multiples, et l’équipe signale que des bases corrompues tolérées en v4 peuvent casser en v5, même si elle s’attend à moins de cas qu’entre v3 et v4. La consigne est donc simple :
- Sauvegarder la base et la configuration v4 avant toute tentative — le retour arrière passe par la restauration.
- Tester sur une instance séparée ou sur un clone de la bibliothèque, jamais sur la production.
- Reconfigurer l’authentification : l’auth basique disparaît, prévoyez l’OIDC ou l’auth par formulaire.
- Surveiller les conteneurs
:developde Hotio et LinuxServer.io, qui basculeront vers v5.
Dans les faits, le passage se joue souvent au niveau du reverse proxy. Un déploiement typique mettait nginx ou Traefik en basic auth devant Sonarr, l’application restant ouverte en interne. Avec la v5, ce schéma devient incohérent : mieux vaut laisser le proxy faire la terminaison TLS et déléguer l’authentification à l’OIDC de Sonarr, ou placer le proxy et l’application derrière le même fournisseur d’identité. Tester la chaîne complète sur un sous-domaine de préproduction évite de se retrouver avec une instance qui refuse toute connexion après la migration.
Verdict
Si votre Sonarr est exposé derrière un reverse proxy ou partagé entre plusieurs utilisateurs, la v5 vaut le coup pour le seul passage à l’OIDC — mais c’est une bêta sans retour arrière simple, alors sauvegardez et attendez la stable si vous dépendez de l’outil au quotidien. Si vous tournez en v4 en interne, non exposée, vous pouvez attendre : les gains de la v5 sont réels, mais rien ne presse tant que l’auth basique reste derrière votre réseau local.