Thanks for helping keep Convertarr and its users safe. This document explains which versions receive security fixes and how to report a vulnerability.

Convertarr is distributed primarily as a Docker image at ghcr.io/opvault/convertarr. Security fixes are applied to 1.1.0 and later only. Anything below 1.1.0 is End of Support (EOS) and will not receive security updates — please upgrade before reporting.

1.0.1 was the last release of the 1.0 line and is now officially EOS. The 1.1.0 release reworked the security model (secure-by-default auth, scoped pairing tokens, worker filesystem containment, and more — see the security posture below), so reports against 1.0.x will be closed with a request to upgrade.

Please do not open a public GitHub issue for security problems.

Use GitHub's private vulnerability reporting instead:

1. Go to the Security tab of this repository.
2. Click Report a vulnerability.
3. Fill in the advisory form with as much detail as you can.

If you cannot use GitHub's private reporting for any reason, send a direct message to the maintainer on X: @olayzen. Keep the initial message short ("convertarr security report — can I share details here?") and wait for a reply before sending sensitive details.

A good report makes triage much faster. Please include:

• The Convertarr version (or image tag / commit SHA) you tested against.
• Deployment context (bare metal via run.sh, Docker, host vs. paired worker).
• A clear description of the vulnerability and its impact.
• Step-by-step reproduction instructions, ideally with a minimal proof of concept.
• Any relevant logs, request/response captures, or configuration snippets (with secrets redacted).
• Your assessment of severity and any suggested remediation.

• Acknowledgement: within 72 hours of receiving the report.
• Initial triage: within 7 days, including a severity assessment and whether the report is accepted.
• Fix timeline: depends on severity. Critical issues are prioritised over feature work; lower-severity issues are scheduled into the next release.
• Disclosure: coordinated. We will credit you in the release notes and GitHub Security Advisory unless you prefer to remain anonymous.

Please give us a reasonable window to ship a fix before any public disclosure.

In scope:

• The Convertarr application code in this repository.
• The official Docker images published under ghcr.io/opvault/convertarr.
• The HTTP API surface (web UI, /api/v1/nodes/*, /api/v1/pairing/*).
• Host ↔ worker pairing and job dispatch.
• Handling of Sonarr/Radarr API keys and other credentials stored by Convertarr.

Out of scope:

• Vulnerabilities in third-party dependencies that have no exploitable path through Convertarr — please report those upstream.
• Issues that require a pre-compromised host, root access, or write access to Convertarr's data directory.
• Bugs in Sonarr, Radarr, Jellyfin, Plex, ffmpeg, or other external services Convertarr integrates with.
• Findings from automated scanners without a demonstrated, exploitable impact.
• Denial of service via obviously expensive operations (e.g. scheduling thousands of concurrent encodes against your own instance).

Convertarr is secure by default. As of 1.1.0 the security model was substantially reworked; in practice that means:

• A fresh install forces a /setup admin account before it serves any protected page — it is never anonymous on its default 0.0.0.0 bind. A stored auth_method = none is honoured only when the operator explicitly sets CONVERTARR_ALLOW_NO_AUTH=1.
• The machine-to-machine API (/api/v1/nodes/*, /api/v1/pairing/*) is always API-key gated, independent of the UI auth mode.
• Pairing uses a per-node, scoped, revocable token plus an out-of-band 4-shape confirmation code shown on the worker's own screen — the host never ships its master API key to a worker.
• Session cookies are signed by a dedicated secret (not the API key) and carry a revocable version; passwords are bcrypt-hashed (SHA-256 pre-hashed, no 72-byte truncation).
• Config exports redact instance-identity secrets (app API key, session secret, password hash, pairing tokens), and imports never overwrite them.
• Worker filesystem access is contained to configured media roots, and ffmpeg/ffprobe I/O is locked to the file: protocol.

That said, hardened ≠ a public-internet appliance — treat the notes below as deployment guidance.

Convertarr is intended to run on a trusted LAN alongside your *arr stack. A few things worth knowing when deploying it:

• Prefer not to expose Convertarr directly to the public internet. Auth is on by default, but the app has no MFA and only a basic login throttle — put it behind a VPN, Tailscale, or an authenticating reverse proxy if it must be reachable remotely, and serve it over HTTPS so the session cookie is marked Secure.
• Never set CONVERTARR_ALLOW_NO_AUTH=1 on a network-reachable bind. It disables authentication entirely; it exists only for isolated/throwaway setups.
• Protect the data directory (data/ for bare metal, /config in Docker). It still contains the SQLite database with Sonarr/Radarr API keys and pairing tokens in plaintext (at-rest column encryption is a documented residual).
• Pairing tokens grant job-dispatch access between host and worker — treat them like passwords. Unpair a decommissioned node to revoke its token (the host stores only a hash).
• Path mappings are per-instance. A worker can read or overwrite any path inside its configured media roots; scope its mounts accordingly, and keep media roots configured so the no-mapping fallback (denylist only) never has to apply.

We appreciate responsible disclosure. Reporters who follow this policy will be acknowledged in the relevant security advisory and release notes.