Sonarr opens the v5 beta and replaces basic auth with OIDC
On 12 October 2026, Sonarr announced the v5 beta, its first major release in nearly two years, with a rebuilt interface, OIDC authentication, and blocking of malicious file extensions in torrents. If your instance is exposed behind a reverse proxy, v5 is the right excuse to finally move to real authentication.
12 October 2026. The Sonarr team announced the v5 beta on its forum, “almost 1,000 commits by almost 100 contributors” since v4. 16 October 2026. Version 5.0.0.2635 landed on the develop branch. 12 October 2026. A community competition opened to pick the app’s future loading messages. Why it matters: Sonarr drops basic authentication in favor of OIDC, and now blocks malicious file extensions in torrents — two substantive changes for a piece of software many people wrongly expose to the Internet.
The biggest beta since v4
Sonarr, a pillar of the Servarr stack alongside Radarr and Lidarr, automates TV collection: it watches RSS feeds, sorts releases, renames and moves them. Released nearly two years ago, v4 had already brought the move to .NET, Custom Formats, and authentication enabled by default. v5 tackles what came next: the interface, search, and above all security.
The beta ships on the develop branch, and the team warns up front: downgrading to v4 is impossible unless you restore a database backup. The :develop Docker images from Hotio and LinuxServer.io have been notified, and native Windows, macOS, Linux, and FreeBSD binaries are available.
Basic auth disappears, OIDC arrives
The most structural change fits in two lines of the announcement: “Basic auth has been removed for security reasons, forms auth is now the default” and “New OIDC auth options.” In practice, a Sonarr instance will no longer open behind a simple username/password pair passed in the HTTP header.
That decision matches reality on the ground. Sonarr is regularly cited as the archetype of a self-hosted app exposed to the Internet while not being designed for it: basic auth, sent in cleartext outside TLS and without fine-grained session management, was a façade. OIDC support opens the door to the identity providers serious homelabs already run — Authelia, Authentik, Keycloak — and enables single sign-on with the rest of the stack.
The practical consequence is immediate: if your Sonarr sat behind a reverse proxy that itself carried basic auth, you will need to rework the authentication chain when moving to v5.
The root problem is familiar to anyone who has exposed a self-hosted service. Basic auth merely encodes the username and password in Base64 in the Authorization header — that is not encryption, and without TLS the credentials travel in cleartext. Add the absence of a real session (the browser resends the pair on every request), no way to revoke a user without reconfiguring everything, and no native defense against brute force. OIDC shifts that responsibility onto a dedicated identity provider: single sign-on, centralized revocation, and above all MFA at the front door — which basic auth could never offer.
The replacement is forms auth, not only OIDC: Sonarr now serves a proper login page with session handling, which on its own closes the cleartext-credential hole for anyone who cannot yet run a full identity provider. OIDC is the optional step up — for homelabs with Authentik, Authelia, or Keycloak already in place, it means one less password to manage and instant revocation when a device is lost.
Blocking malicious file extensions
The second security change is less visible but just as useful: Sonarr can now prevent torrents containing malicious file extensions (.lnk, .scr, .exe, .vbs and the like) from being sent to the download client. The roadmap goes further: blocking at the client level — stopping the download of certain files while letting Sonarr treat the release as failed — starting with qBittorrent.
For a tool that pulls torrents from public sources, that is a concrete defense against booby-trapped archives that try to execute code on the machine hosting the library.
The attack scenario is precise. A booby-trapped torrent ships a file with an innocent name but an executable extension — for example episode.s01e01.mkv.lnk or cover.jpg.exe — which, once opened or triggered during indexing, runs a script. On a Windows box that also doubles as the download machine, that is the entry point for a stealer or ransomware. Blocking those extensions upstream, before the file even reaches the client, removes the exposure window — and the planned client-level extension, starting with qBittorrent, will close the case where an archive is unpacked afterward.
A rebuilt interface and rethought search
The interface is completely redesigned: navigation, tables, dialogs, and responsive behavior all reworked, with improved accessibility (keyboard navigation, screen readers, focus handling) and a new Statistics page for an at-a-glance view of the library.
Search changes just as deeply:
- Interactive search is virtualized — no more UI freezing over thousands of results — with clearer explanations of why a release was accepted or rejected, plus a title filter.
- Release Profiles become more powerful: a single profile can apply to multiple indexers.
- Release parsing gains robustness on difficult names, non-ASCII groups, and multi-episode or multi-season releases.
One smaller change deserves a mention: the ability to prevent grabs before the airdate via Release Profiles. It blocks the classic trap of a mislabeled early release — where a misnamed file or a leak spoils a show — by refusing to download anything before the official air date.
On the metadata side, Sonarr can now read TMDb as an alternative to TheTVDB, use TVDB metadata in non-English languages, and pick episode ordering (DVD or streaming) when adding a series.
This work also previews the future of the rest of the Servarr family. Radarr and Lidarr share the same base and the same security policy: when Sonarr removes basic auth, it signals what awaits the other two at their next major release. For a homelab hosting all three behind the same Authentik or Authelia, the move to OIDC will follow the same mechanics regardless.
What to check before migrating
v5 is still a beta: database migrations are numerous, and the team notes that corrupted databases tolerated in v4 may break in v5, though they expect fewer cases than between v3 and v4. The instructions are simple:
- Back up the v4 database and configuration before any attempt — rollback means restoring.
- Test on a separate instance or a clone of the library, never on production.
- Reconfigure authentication: basic auth is gone, so plan for OIDC or forms auth.
- Watch the Hotio and LinuxServer.io
:developcontainers, which will switch to v5.
The beta caveat is concrete. Sonarr ships v5 on the develop branch, so Docker users on :latest stay on v4 for now; only those pinning :develop — or switching explicitly — move. Because there is no downgrade path without a restore, treat the beta like a migration rather than an update: snapshot the config volume and the database first, and keep a v4 instance running until you are confident.
Verdict
If your Sonarr is exposed behind a reverse proxy or shared between users, v5 is worth it for the move to OIDC alone — but it is a beta with no easy rollback, so back up and wait for stable if you depend on it daily. If you run v4 internally and unexposed, you can wait: v5’s gains are real, but nothing is urgent as long as basic auth stays behind your local network.