Zum Hauptinhalt springen
S-EDV news
← Alle News
Docker 01.09.2026 · 6 min Lesezeit

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.

Illustration zu Portainer 2.39.6 LTS Sicherheitsupdate: Dashboard-Mockup mit Container-Uebersicht, Warnhinweis zu ungeschuetzten ausgehenden Anfragen und Angriffskette von SSRF ueber Schwachstellenausnutzung bis Kompromittierung

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ÄnderungBedeutung
SSRF SchutzAllowlist Modi off, audit, enforceAusgehende Ziele beobachten oder verbindlich begrenzen.
Edge RegistrierungEdgeID beim Erstkontakt serverseitig gesetztServer übernimmt die Identitätsvergabe.
Swarm Compose DeployerPath Traversal bei Config/Secret Pfaden behobenDateien außerhalb des Projektstamms nicht mehr einbindbar.
Docker ProxyRBAC Auflösung aus Endpoint Snapshot korrigiertBerechtigungen nutzen wieder die vorgesehene Grundlage.
AbhängigkeitenGo, go-git, containerd aktualisiertMehrere 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 ps muss 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 audit beobachten.
  • Nach der Beobachtungsphase enforce planen, 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

Quellen

PortainerDockerDocker ComposeSicherheitsupdateSSRFSwarmRBACcontainerd