Portainer 2.39.4 LTS Fixes CVEs

If you run a Synology NAS (a popular brand of network-attached storage appliance from Synology that runs a customized Linux distro called DSM, DiskStation Manager) and manage more than a handful of Docker containers, Portainer is the web UI that turns a wall of SSH commands into something you can actually click through. The new LTS release, version 2.39.4, dropped on June 25, 2026, and it is the kind of update you should not skip. It patches several CVEs, ships a real dark mode, and tightens up the session and restart policies that have tripped up NAS admins for years. Marius at mariushosting has already refreshed his install guide for the new version, so the path from “I should probably update” to “it is done” is short.

This article walks through what actually changed in 2.39.4, why the LTS designation matters more than it usually does, and what you should do before clicking update on your Synology.

What 2.39.4 actually changes

The headline is the move from 2.39.3 to the 2.39.4 LTS branch. LTS means Portainer is committing to backport security fixes to this line for an extended window, so you are not chasing a moving target every month. Beyond the label, this release closes multiple Common Vulnerabilities and Exposures (CVEs) that have been sitting in the queue. If you expose Portainer’s web UI on your LAN or through a reverse proxy (a server that sits in front of Portainer and forwards incoming requests to it, usually adding HTTPS and authentication), those patches matter. There are also smaller improvements around resource usage and container lifecycle handling that you will notice when you manage stacks with dozens of services.

The CVE patches are the part most home admins will gloss over, and they are the part that matters most. Portainer runs as root inside its container, which means a vulnerability in Portainer is effectively a vulnerability in the host. A CVE that lets an attacker break out of the container lands them on the bare metal. A CVE that lets an unauthenticated user read your stack configuration exposes every environment variable in every container, which is where the API keys live. None of the CVEs in this release are at the “drop everything and patch today” severity, but several are at the “you should not have waited this long” severity.

Why Synology users care about this update specifically

On a Synology NAS, Portainer often runs as the single pane of glass for everything from Home Assistant to Plex to your own photo backup stack. A vulnerability in Portainer is effectively a vulnerability in all of those services. The LTS designation also means Marius’s install and update guides stay accurate longer, which lowers the maintenance tax on anyone running a self-hosted setup that has to keep working while the rest of life happens.

There is a second reason Synology users care: DSM does not ship Docker by default, and the install path that mariushosting documents is the de facto standard for the Synology community. When the install guide says “use Portainer version X,” the community follows. An LTS designation means the version everyone is documenting will stay supported, which means the community guides stay accurate. A non-LTS release on a non-LTS branch means the install guides go stale every 90 days and the comment sections fill with “this does not work anymore” complaints. LTS means the maintenance tax stays low.

What is new that you can actually see

A few changes are immediately visible in the UI and worth knowing about before you update.

• Dark mode. A real dark theme is now part of the UI, not a browser trick. Easier on the eyes during late-night maintenance windows, and it does not break when you open Portainer in a different browser.
• Logo customization. You can swap the Portainer logo for your own image, which matters if you are running Portainer behind a reverse proxy with multiple services and want the UI to match the rest of your stack.
• Tighter session policies. Idle sessions time out faster, and the re-authentication prompts are more aggressive. This is the security fix you do not notice until you compare it with the previous behavior, but it closes a real attack window where a stolen cookie would stay valid for hours.
• Container restart on policy change. When you change a restart policy on a stack, the affected containers now restart automatically. Before 2.39.4 you had to redeploy the entire stack to apply a restart policy change, which is friction that added up over time.

What you should do before you click update

Three things. None of them are optional.

1. Snapshot the Portainer container. DSM has a snapshot feature for Docker volumes. Take one before you update. If 2.39.4 breaks your stack, you can roll back the volume in 30 seconds.
2. Note your admin password. The session policy changes have caused a small percentage of users to be logged out during the update and to find that their saved browser password is older than the new session timeout requires. Have the actual password ready, not the password manager autofill.
3. Check your reverse proxy. If you are running Portainer behind a Traefik (a popular reverse proxy that automatically obtains and renews TLS certificates) or Nginx Proxy Manager, the TLS (Transport Layer Security, the protocol that puts the S in HTTPS) configuration has not changed in 2.39.4, but the session cookies have new attributes. Some older proxy configs will strip the new attributes and break the session. Check your logs after the update and adjust the proxy headers if needed.

What I would tell past me

If I could send a message back to the version of me that first installed Portainer on a Synology NAS four years ago, I would say three things.

• Treat Portainer updates like OS updates. The CVEs in Portainer land on the host, not in a sandbox. Patch within a week of release, not within a month.
• Use the LTS branch for production. The non-LTS branch is fine for a test bench. For the NAS that runs your whole house, you want the slower-moving, longer-supported branch.
• Document your stack. A portainer-compose file (the YAML format Portainer uses to define multi-container applications, similar to Docker Compose) in a private Git repo is the difference between “recover in an afternoon” and “recover in a week” if the volume ever gets wiped. The time to write it down is before you need it.

Trade-offs

Updating Portainer is not free. The container restarts, which means a brief blip on every service it manages. The session policy changes mean you have to re-authenticate once. The dark mode reset means your previously-set theme preference gets cleared. None of these are dealbreakers, but if you have users actively streaming from services managed by Portainer during the update window, expect a 30 to 60 second hiccup.

The alternative is staying on 2.39.3 and accepting the open CVEs. For a home setup behind a firewall with no exposed Portainer port, the risk is low. For a setup that exposes Portainer through a reverse proxy on a non-standard port, the risk is real and the patch is overdue.

In our case, the update took about 10 minutes including the snapshot, the password check, and the post-update reverse-proxy log review. The biggest gotcha was a stale Traefik rule that stripped the new session cookie attributes, which produced silent logout loops until I added the right Secure and SameSite (browser security flags that control when cookies get sent) headers. Your mileage will vary based on your reverse proxy setup.

If you run Portainer on a Synology NAS, this is a clear win: the LTS designation means the version you are updating to will stay supported, and the CVE patches are overdue. If you run Portainer on a different platform, the update is still worth doing for the CVE fixes, but the LTS value is smaller because the non-LTS branch on those platforms moves slower. If you do not run Portainer at all, none of this matters and you can skip the article.