# nzbdav: WebDAV over Usenet, with a SABnzbd compatible API

> nzbdav is a WebDAV server that mounts NZB documents as a virtual file system, so Plex, Jellyfin, Sonarr and Radarr can stream from a usenet provider without downloading anything to local storage. It shipped a SABnzbd compatible API for drop-in integration, a health check that replaces content the provider removed, and an authentication bypass fix, and it is now unmaintained with community forks carrying it forward.

**nzbdav-dev/nzbdav** — Usenet streaming with a WebDAV server and a SABnzbd-compatible API

- Repository: https://github.com/nzbdav-dev/nzbdav
- Stars: 1,184 · Forks: 112
- Language: C#
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/nzbdav-dev-nzbdav

## A file system that is really a network of NZB documents

NzbDav is a WebDAV server that lets you mount and browse NZB documents as a virtual file system without downloading them. The design goal is to integrate with other media management tools, such as Sonarr and Radarr, by providing a SABnzbd compatible API, and the payoff it describes is an infinite Plex or Jellyfin media library that streams directly from a usenet provider at maxed-out speeds, without using any storage space on your own server.

That last clause is the whole idea, and it is what makes the project interesting next to a normal downloader. In a SABnzbd style setup, the articles are fetched to a disk and then a media stack reads the files. Here the files are a projection: the WebDAV server resolves a path to an NZB document, fetches what it needs on demand, and streams the result. Nothing is stored, so the library size is bounded by the provider rather than by your disk.

The streaming is not limited to a plain file. The feature list includes full streaming and seeking, so a player can jump to a position in the middle of a video without the whole thing being fetched first, and the ability to view, stream and seek content inside RAR and 7z archives, and inside password-protected archives.

The project is written in C# on the backend with a Node frontend, is MIT licensed, and the last push to the repository was on 2026-09-03. The most recent releases are v0.6.4 on 2026-04-08, v0.6.3 the same day and v0.6.2 on 2026-03-24.

## The feature that has no equivalent elsewhere is the health check

Two features in the list deserve more attention than the headline.

The first is health checks and repairs, described as automatically replacing content that has been removed from your usenet provider. This is the failure mode that makes usenet setups annoying in a way that ordinary downloads are not. A provider deletes or expires an article, and a library that pointed at that article now points at nothing, and the repair tool in the stack fills the gap by fetching a replacement. Doing that automatically, across a library of unknown size, is the sort of maintenance that otherwise becomes a weekly chore.

The second is the SABnzbd compatible API, which lets NzbDav act as a drop-in replacement for sabnzbd. That is a compatibility decision with consequences. The queue, the API and the history that Sonarr and Radarr already speak are the same, so the integration is a URL change rather than a rewrite, and the project lists the Sonarr and Radarr integration as configure it once and leave it unattended.

The same compatibility idea extends to the rest of the stack. The comprehensive setup guide covers a Docker Compose stack with an Rclone sidecar and health checks, performance tuning through benchmarking WebDAV connection limits, automating Radarr and Sonarr queue management and repairs, and streaming Usenet directly via Stremio using AIOStreams. The performance section is the one to read before deploying, because a virtual file system that fans out into many range requests is exactly the kind of thing that needs a connection limit tuned rather than guessed.

## Running it, and where the settings live

The easiest way to start is the official Docker image, and the trial command exposes port 3000.

```bash
docker run --rm -it -p 3000:3000 nzbdav/nzbdav:latest
```

To keep your settings across restarts, you attach a volume at /config, and the run also takes the user and group ids so that the files it writes are owned by you rather than by root.

```bash
mkdir -p $(pwd)/nzbdav && \
docker run --rm -it \
  -v $(pwd)/nzbdav:/config \
  -e PUID=1000 \
  -e PGID=1000 \
  -p 3000:3000 \
  nzbdav/nzbdav:latest
```

After the container starts, there are two steps in the web interface. You go to the Settings page to finish setting up your usenet connection settings, and you set a username and password for logging in to the WebDAV server.

Both of those are in the interface rather than in environment variables, which is worth noticing for a container that people expose. The Docker image sets NODE_ENV to production and LOG_LEVEL to warning by default, and the entrypoint script handles the rest of the runtime setup, including dropping privileges with the su-exec helper and the shadow package that the image installs.

The image itself is a three stage build. The frontend is built on Node Alpine with npm install, npm run build, npm run build:server and a prune of the dev dependencies. The backend is built on the .NET 10 SDK Alpine image, with the target architecture passed in as a build argument and the publish targeting linux-musl for that architecture. The final image is the ASP.NET 10 Alpine runtime with the frontend build, the backend publish output and the entrypoint script copied in, exposing port 3000.

## The authentication bypass, and the version that fixes it

The README carries a security note that is more specific than most, and it is the first thing to read before deploying an instance.

On 2026-03-17 the researcher g0ldyy reported an authentication bypass vulnerability in nzbdav. It affected versions 0.2.46 through 0.6.1. The Docker Hub and GitHub container registry images for those versions were patched, rebuilt and republished on 2026-03-18, and the instruction is simply to repull whichever image tag you are using to make sure your instance is patched.

How you confirm a patched version is running is worth noting, because it is not obvious. You look for a +260317 suffix on the version displayed in the nzbdav user interface. The README also says this matters especially if your instance is public facing and not behind a VPN or single sign-on.

Those two details together are the lesson. The vulnerable range is long, which means an instance that has been running since before March 2026 is probably still vulnerable, and the only test is whether the image you pulled after 18 March 2026 contains the fix. The version suffix in the UI is there so that you can answer that question without guessing.

There is also a legal note in the README that belongs in any evaluation. NzbDav is intended for use with legally obtained content only, the project maintainers do not condone piracy, and they will not provide support for users suspected of engaging in copyright infringement.

## The project is done, and it says so

The first line of the README is a note that this project is no longer maintained, and the reason is stated with a shrug: it was a hobby and the maintainer's interests have changed.

What follows is a list of where to go instead. There are two community forks, infinidysk and qooode's nzbdavex, followed by similar projects, altmount and decypharr, which are not forks of this one but tools in the same space.

That recommendation list is the most useful thing in the document for anyone evaluating the project today. A hobby project that was well built, had a security fix handled properly within a day, and was then abandoned is not a disaster; it is a normal lifecycle, and the maintainer did the courteous thing by naming successors rather than leaving the repository to rot.

The release history gives a sense of the arc. The versions run to 0.6.4, released on 2026-04-08, with 0.6.3 the same day and 0.6.2 on 2026-03-24, which is right after the security fix on 18 March. The last push to the repository is on 2026-09-03, so something was still being committed after the release, even if the project as a whole was being handed over.

For a user, the practical question is which fork you would run, and the practical risk is that the security history does not transfer automatically. A fork that took the 0.6.1 tree rather than the 0.6.4 tree would inherit the authentication bypass, and nothing in the fork's name would tell you.

## Conclusion

nzbdav fits someone who already pays a usenet provider, wants the library to appear to their media stack as a mounted drive, and is willing to run the container and accept that a community fork is where the fixes will come from. It does not fit a new deployment, since the upstream project says plainly that it is no longer maintained and points at two forks, and it does not fit anyone who intends to run it publicly without reading the authentication section first. Verify three things before you deploy anything based on it: that you are on a version past 0.6.1, because the authentication bypass affected 0.2.46 through 0.6.1, that your image has been repulled so the +260317 build suffix is present, and that you are on a fork that is still taking security reports, since the original will not be answering them.

## FAQ

### What does NzbDav actually do?

It is a WebDAV server that mounts NZB documents as a virtual file system without downloading them, and provides a SABnzbd compatible API so media tools such as Sonarr and Radarr can treat it as a drop-in replacement for sabnzbd. Streaming and seeking work, including inside RAR and 7z archives and password-protected archives.

### How do I run NzbDav with Docker?

The quick command is docker run --rm -it -p 3000:3000 nzbdav/nzbdav:latest, and to persist settings you mount a volume at /config and pass PUID and PGID, for example -v $(pwd)/nzbdav:/config -e PUID=1000 -e PGID=1000. After the container starts you set the usenet connection in the Settings page and set a username and password for the WebDAV server.

### Was there a security vulnerability in NzbDav?

Yes. An authentication bypass vulnerability was reported on 2026-03-17 and affected versions 0.2.46 through 0.6.1. The images were patched, rebuilt and republished on 2026-03-18, so you should repull whichever tag you use, and you can confirm a patched build by looking for the +260317 suffix on the version shown in the user interface. It matters most on instances that are public facing and not behind a VPN or single sign-on.

### Is NzbDav still maintained?

No. The README states that the project is no longer maintained because it was a hobby and the maintainer's interests have changed. It points to the community forks infinidysk and qooode's nzbdavex, and to related projects altmount and decypharr. The last release was v0.6.4 on 2026-04-08 and the last push was on 2026-09-03.

### What else is in the NzbDav setup guide?

The guide covers a Docker Compose stack with an Rclone sidecar and health checks, performance tuning through benchmarking WebDAV connection limits, automating Radarr and Sonarr queue management and repairs, and streaming Usenet directly via Stremio using AIOStreams. There is also a health check feature in the tool itself that automatically replaces content removed from the usenet provider.

## Sources

- [Issues](https://github.com/nzbdav-dev/nzbdav/issues)
- [License: MIT](https://github.com/nzbdav-dev/nzbdav/blob/main/LICENSE)
- [nzbdav-dev/nzbdav on GitHub](https://github.com/nzbdav-dev/nzbdav)
- [README](https://github.com/nzbdav-dev/nzbdav/blob/main/README.md)
- [Releases](https://github.com/nzbdav-dev/nzbdav/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nzbdav-dev-nzbdav