Portainer 2.39.6 LTS schließt SSRF und Path Traversal
Portainer 2.39.6 LTS behebt SSRF Risiken, Path Traversal im Swarm Compose Deployer und eine fehlerhafte RBAC Auflösung. Admins sollten Version und Exposition prüfen, Daten sichern und den Container kontrolliert neu erstellen.

Betroffen sind Installationen von Portainer Community Edition und Business Edition vor Portainer 2.39.6 LTS mit den korrigierten Komponenten. Besonders relevant sind Umgebungen mit erreichbarer Portainer API, Edge Agents, dem Swarm Compose Deployer oder dem Docker Proxy. Angriffspfade reichen von manipulierten ausgehenden Serveranfragen über unzulässige Config und Secret Dateipfade bis zu fehlerhaften RBAC Entscheidungen. Portainer 2.39.6 LTS schließt diese Pfade laut offiziellen Release Notes, für bereits erfolgte Ausnutzung gibt es dort keinen Beleg.
Direkt aus dem Internet erreichbare Instanzen und Mehrbenutzerumgebungen sollten noch am selben Tag geprüft und in ein kurzfristiges Wartungsfenster aufgenommen werden. Intern abgeschottete Einzelinstanzen ohne Swarm und Edge Funktionen haben ein geringeres Risiko, profitieren aber ebenfalls von den aktualisierten Abhängigkeiten. Admins sollten zuerst die laufende Version feststellen, Konfiguration und Daten sichern, das Image laden, den Container neu erstellen und danach Version, Status sowie Logs kontrollieren. Bis zum Update sollte der Zugriff auf vertrauenswürdige Netze und berechtigte Konten begrenzt bleiben.
Was Portainer 2.39.6 LTS ändert
Das am 13. August 2026 dokumentierte LTS Update bündelt mehrere Sicherheitskorrekturen und aktualisiert sicherheitsrelevante Bibliotheken. Die Änderungen härten Vertrauensgrenzen zwischen Browser, Portainer Server, Docker API, Edge Agent, Git Repository und Container Runtime.
| Bereich | Änderung | Bedeutung |
|---|---|---|
| SSRF Schutz | Allowlist Modi off, audit, enforce | Ausgehende Ziele beobachten oder verbindlich begrenzen. |
| Edge Registrierung | EdgeID beim Erstkontakt serverseitig gesetzt | Server übernimmt die Identitätsvergabe. |
| Swarm Compose Deployer | Path Traversal bei Config/Secret Pfaden behoben | Dateien außerhalb des Projektstamms nicht mehr einbindbar. |
| Docker Proxy | RBAC Auflösung aus Endpoint Snapshot korrigiert | Berechtigungen nutzen wieder die vorgesehene Grundlage. |
| Abhängigkeiten | Go, go-git, containerd aktualisiert | Mehrere CVEs über neue Versionen adressiert. |
Angriffspfade und Betroffenheit
SSRF steht für Server Side Request Forgery: Eine Eingabe bringt den Server dazu, eine Anfrage an ein Ziel zu senden, das der Angreifer nicht direkt erreichen kann. Der Portainer Server hat oft Zugriff auf interne APIs und Verwaltungsnetze, deshalb ist der neue Allowlist Schutz relevant. audit eignet sich zur Einführung, weil Abweichungen sichtbar werden, enforce setzt die Vorgabe verbindlich durch. Die Path Traversal Korrektur betrifft den Swarm Compose Deployer, bei dem Dateipfade für Configs oder Secrets aus dem Projektstamm herausführen konnten, das setzt passenden Zugriff auf die Bereitstellung voraus. Die RBAC Korrektur betrifft den Docker Proxy, dessen Auflösung aus einem gecachten Endpoint Snapshot falsche Berechtigungsentscheidungen begünstigen konnte. Das Risiko steigt bei mehreren Rollen, Einzelbenutzerinstallationen sollten die Korrektur trotzdem übernehmen.
Aktualisierte Abhängigkeiten und CVEs
Portainer nennt Go 1.25.12 als aktualisierte Build Grundlage und ordnet ihr die Korrekturen für CVE-2026-42505 und CVE-2026-39822 zu. Außerdem wird go-git 5.19.2 wegen CVE-2026-71556 und CVE-2026-71557 eingesetzt. containerd 1.7.33 adressiert CVE-2026-53488 und CVE-2026-47262. Entscheidend ist das ausgelieferte Portainer Image, einzelne Bibliotheken im laufenden Container manuell auszutauschen wäre nicht reproduzierbar. Die Release Notes belegen die Zuordnung der Updates, sagen aber nicht, dass die Schwachstellen aktiv ausgenutzt werden. Ohne Beleg ist ein kontrolliertes Update angemessen, eine Behauptung über laufende Angriffe jedoch nicht.
- Go: Version 1.25.12.
- go-git: Version 5.19.2.
- containerd: Version 1.7.33.
- Korrekturen und Bibliotheksupdates gemeinsam übernehmen.
- Ein Image Pull allein aktualisiert keinen laufenden Container.
Vorbereitung, Backup und Versionscheck
Die folgenden Schritte gehen von einer Docker Compose Installation mit dem Service portainer und dem benannten Volume portainer_data aus. Bei abweichenden Namen an die lokale Konfiguration anpassen. Zuerst in das Projektverzeichnis wechseln, Konfiguration prüfen und danach ein Backup des Datenvolumes erstellen, bevor der Stack neu gestartet wird.
cd /pfad/zum/portainer-projekt
docker compose config
docker compose ps
docker inspect portainer --format '{{.Config.Image}}'
mkdir -p ./backup
docker compose stop
docker run --rm -v portainer_data:/data:ro -v "$PWD/backup:/backup" alpine:3.22 tar -czf /backup/portainer-data-before-2.39.6.tgz -C /data .
sha256sum ./backup/portainer-data-before-2.39.6.tgz
Prüfen, ob das Archiv existiert, eine plausible Größe besitzt und außerhalb des Docker Hosts gesichert wird. Ein Backup ohne getesteten Wiederherstellungsweg ist kein belastbarer Rollback Plan.
Update mit Docker Compose durchführen
In der Compose Datei einen eindeutigen Image Tag setzen, beispielsweise portainer/portainer-ce:2.39.6. Für Business Edition ist das tatsächlich eingesetzte, lizenzierte Image maßgeblich. Für diesen Wartungsschritt keinen beweglichen Tag wie latest verwenden, weil das die spätere Reproduktion erschwert.
cp compose.yaml ./backup/compose.yaml.before-2.39.6
docker compose config
docker compose pull portainer
docker compose up -d --no-deps --force-recreate portainer
docker compose ps
docker compose logs --since=10m portainer
Falls die Datei lokal docker-compose.yml heißt, den Kopierbefehl entsprechend anpassen. docker compose up erstellt den Dienst mit dem geladenen Image neu, das Datenvolume bleibt dabei erhalten. Das Volume nicht löschen und bei diesem Update kein docker compose down -v verwenden.
Prüfung nach dem Neustart
Ein laufender Container allein belegt noch kein erfolgreiches Update. Die angezeigte Portainer Version, Anmeldung, alle benötigten Endpoints und mindestens einen Lesezugriff pro relevanter Rolle prüfen. Bei Edge Umgebungen zusätzlich kontrollieren, ob Agents nach dem Erstkontakt wieder verbunden sind. Bei Swarm sollten bestehende Stacks sichtbar sein, ohne sofort eine produktive Neubereitstellung auszulösen. Protokolle des Wartungsfensters, Hash des Backups und verwendete Image Referenz aufbewahren.
- In der Oberfläche muss Portainer 2.39.6 angezeigt werden.
docker compose psmuss den erwarteten Servicezustand zeigen.- Die Logs dürfen keine wiederkehrenden Startfehler enthalten.
- Docker und Swarm Endpoints müssen erreichbar sein.
- Rollen mit eingeschränkten Rechten dürfen keine zusätzlichen Ressourcen sehen.
- Edge Agents müssen wieder den erwarteten Verbindungsstatus erreichen.
- SSRF Allowlist Einstellungen zunächst im Modus
auditbeobachten. - Nach der Beobachtungsphase
enforceplanen, sofern alle legitimen Ziele erfasst sind.
Rollback bei Problemen
Bei schwerwiegenden Fehlern zuerst den Stack stoppen, dann die vorherige Compose Datei und, falls nötig, das gesicherte Datenvolume wieder herstellen. Die folgenden Befehle setzen den zuvor verwendeten Volume Namen voraus.
docker compose down
cp ./backup/compose.yaml.before-2.39.6 ./compose.yaml
docker run --rm -v portainer_data:/data -v "$PWD/backup:/backup:ro" alpine:3.22 sh -c 'rm -rf /data/* /data/.[!.]*; tar -xzf /backup/portainer-data-before-2.39.6.tgz -C /data'
docker compose up -d
Der Wiederherstellungsbefehl löscht den aktuellen Inhalt des Portainer Volumes und darf nur nach Prüfung von Pfad, Volume Name und Backup ausgeführt werden. Nach einem Rollback bleibt das Sicherheitsrisiko der älteren Version bestehen. Zugang begrenzen und Updateursache analysieren, bevor das Wartungsfenster geschlossen wird.
Wie kritisch ist das Update?
Für öffentlich erreichbare Verwaltungsoberflächen, Swarm Bereitstellungen mit externen Compose Quellen, Edge Flotten und Plattformen mit mehreren Rollen ist das Update hoch zu priorisieren, da die korrigierten Pfade dort auf größere Angriffsflächen und stärkere Berechtigungen treffen. Für intern isolierte Einzelinstallationen ohne diese Funktionen reicht in der Regel ein kurzfristig geplantes Wartungsfenster, sofern der Zugriff beschränkt und überwacht wird. Nicht betroffen von diesen Fehlern sind Docker Umgebungen ohne Portainer. Wer bereits eine neuere, vom Hersteller unterstützte Linie betreibt, sollte anhand der Release Notes prüfen, ob die Korrekturen enthalten sind, die Versionsnummer allein ersetzt diese Prüfung nicht.
Passende Anleitungen auf S-EDV
- Docker Compose unter Linux als Selfhosting Grundlage: Aufbau eines nachvollziehbaren Compose Projekts.
- Docker Compose mit Secrets, Healthchecks und Non Root Betrieb absichern: zusätzliche Härtung für Container Dienste.
- Docker sicher aktualisieren: Wartungsablauf mit Prüfung, Backup und kontrolliertem Neustart.
Quellen
- Portainer Release Notes: Primärquelle zu Portainer 2.39.6 LTS, abgerufen am 1. September 2026.
- Offizielle Installationsdokumentation für Portainer CE: Referenz zu Installationswegen und Images, abgerufen am 1. September 2026.
- Marius Hosting zur Portainer Aktualisierung: Sekundärquelle zum praktischen Container Update, abgerufen am 1. September 2026.