CVE-2026-25499: Kritische Sicherheitslücke im Proxmox Terraform/OpenTofu Provider – Jetzt patchen!

VonContentKalle

Der bpg/terraform-provider-proxmox ist mit über 10.000 GitHub-Stars einer der meistgenutzten Community-Provider für Proxmox VE. Er ermöglicht es, Proxmox-Ressourcen wie VMs, LXC-Container, Storage und Netzwerke vollständig per Terraform oder OpenTofu zu verwalten – Infrastructure as Code für den Homelab-Betrieb. Gerade in der Proxmox-Community hat er sich zur Standardlösung für automatisierte Deployments entwickelt. Umso wichtiger ist es, die kritische Schwachstelle CVE-2026-25499 ernst zu nehmen und umgehend zu beheben.

Was steckt hinter CVE-2026-25499?

Eine kritische Sicherheitslücke erschüttert die Homelab-Community: CVE-2026-25499 betrifft den weit verbreiteten Terraform/OpenTofu Provider für Proxmox VE (bpg/terraform-provider-proxmox) und ermöglicht durch eine unsichere sudoers-Konfiguration in der offiziellen Dokumentation das Traversieren beliebiger Verzeichnisse auf dem Host-System. Alle Versionen vor 0.93.1 sind verwundbar. Wer Proxmox mit Infrastructure-as-Code betreibt, sollte jetzt handeln.

Technischer Hintergrund: Was ist das Problem?

Der Proxmox Terraform Provider ermöglicht es, VMs, Container und Storage-Ressourcen deklarativ per Code zu verwalten. Für SSH-basierte Operationen empfiehlt die Dokumentation eine sudoers-Regel, die dem Provider erlaubt, Dateien via tee zu schreiben – beispielsweise Snippets nach /var/lib/vz/snippets/.

Genau hier liegt das Problem: Die empfohlene sudoers-Konfiguration verwendete ein unsicheres Wildcard-Muster wie:

Cmnd_Alias TERRAFORM = /usr/bin/tee /var/lib/vz/*
terraform ALL=(root) NOPASSWD: TERRAFORM

Das Wildcard * in sudoers-Regeln schützt nicht vor Path-Traversal-Angriffen. Ein Angreifer kann damit Pfade wie /var/lib/vz/../../../etc/sudoers.d/malicious übergeben und so beliebige Systemdateien überschreiben – inklusive /etc/sudoers, /etc/shadow oder SSH-Authorized-Keys. Das Ergebnis: vollständige Kompromittierung des Proxmox-Hosts.

Einordnung der Schwere

  • CVE: CVE-2026-25499
  • CVSS 4.0 Score: 8.7 (HIGH)
  • CWE: CWE-22 (Path Traversal) & CWE-1188 (Insecure Default Initialization)
  • Angriffsvektor: Netzwerk, ohne Authentifizierung
  • Betroffen: Alle Versionen des bpg/terraform-provider-proxmox vor 0.93.1

Der CVSS 4.0 Score von 8.7 (HIGH) setzt sich aus mehreren kritischen Faktoren zusammen: Der Angriffsvektor ist Netzwerk (AV:N) – ein Angreifer benötigt keinen physischen oder lokalen Zugang. Es ist keine Authentifizierung erforderlich (PR:N), und User Interaction ist nicht notwendig (UI:N). Der Impact auf die Systemintegrität ist als HIGH eingestuft, da beliebige Systemdateien überschrieben werden können. Besonders problematisch: Da der Provider SSH-Verbindungen vom eigenen System zum Proxmox-Host aufbaut, ist die Ausnutzbarkeit auch in typischen Homelab-Konfigurationen realistisch – sofern ein Angreifer Zugriff auf den Terraform-State oder die Konfigurationsdateien erlangt.

Warum empfiehlt die Dokumentation überhaupt eine Wildcard-Regel?

Die ursprüngliche sudoers-Empfehlung hatte einen nachvollziehbaren Hintergrund: Der Proxmox Terraform Provider benötigt für SSH-basierte Operationen erhöhte Rechte, um Dateien in das Verzeichnis /var/lib/vz/snippets/ zu schreiben. Diese Snippets werden für VM-Cloudinit-Konfigurationen und andere Automatisierungen benötigt.

Ein Wildcard-Muster erschien zunächst praktisch, da es wartungsärmer ist als eine explizite Auflistung aller möglichen Dateinamen. Das Problem: Die Entwickler – und viele Administratoren, die die Dokumentation übernahmen – waren sich der sudo-Wildcard-Problematik nicht bewusst. In Shell-Glob-Mustern schützt * vor Path-Traversal, in sudo-Regeln jedoch nicht. Dies ist ein klassisches Beispiel dafür, wie technische Bequemlichkeit und mangelndes Sicherheitsbewusstsein zu kritischen Schwachstellen führen können.

Bin ich betroffen?

Du bist potenziell betroffen, wenn alle folgenden Punkte zutreffen:

  1. Du nutzt den bpg/terraform-provider-proxmox oder den entsprechenden OpenTofu-Provider
  2. Du hast die SSH-Verbindung aktiviert (statt der API-Token-Methode)
  3. Du hast die in der Dokumentation empfohlene sudoers-Konfiguration übernommen
  4. Dein Provider ist älter als Version 0.93.1

Um die aktuell verwendete Provider-Version zu prüfen:

terraform version
# oder
tofu version

# Zeigt alle Provider-Versionen
terraform providers

Sofortmaßnahmen: So schützt du dein System

Schritt 1: Provider auf 0.93.1 oder neuer aktualisieren

Passe deine versions.tf (oder den required_providers-Block) an:

terraform {
  required_providers {
    proxmox = {
      source  = "bpg/proxmox"
      version = ">= 0.93.1"
    }
  }
}

Anschließend die Provider-Version aktualisieren:

# Terraform
terraform init -upgrade

# OpenTofu
tofu init -upgrade

Schritt 2: sudoers-Konfiguration auf dem Proxmox-Host prüfen und korrigieren

Auf dem Proxmox-Host prüfen, ob eine unsichere sudoers-Regel existiert:

cat /etc/sudoers.d/terraform
# oder
sudo grep -r "tee" /etc/sudoers /etc/sudoers.d/

Falls eine Wildcard-Regel wie /usr/bin/tee /var/lib/vz/* vorhanden ist, ersetze sie durch eine sichere Variante, die nur spezifische Unterverzeichnisse und Dateiendungen erlaubt:

# Unsicher (entfernen!):
terraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/*

# Sicher (ersetzen durch):
terraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/snippets/*.yaml, /usr/bin/tee /var/lib/vz/snippets/*.yml

Schritt 3: Auf Kompromittierung prüfen

Falls du die unsichere Konfiguration länger aktiv hattest, prüfe kritische Systemdateien auf unautorisierte Änderungen:

# Letzte Änderungen an sensiblen Dateien
ls -la /etc/sudoers /etc/sudoers.d/ /root/.ssh/authorized_keys

# Auth-Log auf verdächtige sudo-Aktivitäten prüfen
grep "COMMAND" /var/log/auth.log | grep "tee" | tail -50

Hintergrund: Warum sind sudoers-Wildcards so gefährlich?

Viele Admins sind sich nicht bewusst, dass das *-Wildcard in sudo-Regeln deutlich anders funktioniert als in Shell-Glob-Mustern. Sudo verwendet libpam-based pattern matching, das explizit keine Path-Traversal-Schutzmaßnahmen enthält. Ein Pfad wie /var/lib/vz/../../../etc/passwd matcht problemlos gegen /var/lib/vz/*.

Die korrekte Absicherung erfordert entweder exakte Pfadangaben oder – noch besser – die Nutzung der API-Token-Methode des Proxmox Providers, die keine erhöhten Dateisystemberechtigungen benötigt.

Fazit und Empfehlung

CVE-2026-25499 ist ein klassisches Beispiel dafür, wie gut gemeinte Dokumentation erhebliche Sicherheitsprobleme verursachen kann. Der Fix ist einfach und schnell umgesetzt – aber nur, wenn man weiß, dass man betroffen ist. Wer den bpg Proxmox Terraform Provider nutzt und SSH-Konfigurationen gemäß alter Dokumentation eingerichtet hat, sollte jetzt handeln.

TL;DR:

  • Update auf Provider-Version 0.93.1+
  • sudoers-Konfiguration auf Wildcards prüfen und sichern
  • Bei Verdacht auf Kompromittierung: Systemlogs prüfen und kritische Dateien verifizieren
  • Langfristig: API-Token statt SSH in Betracht ziehen

Langfristige Best Practices

CVE-2026-25499 ist ein Weckruf, die eigene Sicherheitsstrategie zu überdenken. Als langfristige Empfehlung gilt das Principle of Least Privilege: Gib Systemen und Prozessen nur die Berechtigungen, die sie wirklich benötigen – und das so spezifisch wie möglich.

Für den Proxmox Terraform Provider empfehlen sich folgende Maßnahmen:

  • API-Token statt SSH: Verwende wo möglich die API-Token-Methode des Providers. Diese benötigt keine erhöhten Dateisystemberechtigungen und eliminiert die gesamte sudoers-Problematik.
  • Regelmäßige Audits: Führe in regelmäßigen Abständen Audits deiner sudoers-Konfigurationen durch – nicht nur nach CVEs, sondern präventiv.
  • Keine Wildcards in sudo-Regeln: Vermeide generell Wildcard-Muster in sudo-Konfigurationen. Exakte Pfadangaben sind zwar aufwändiger, aber deutlich sicherer.
  • Provider-Updates im Blick behalten: Abonniere die GitHub-Releases des Providers, um sicherheitsrelevante Updates nicht zu verpassen.

Ähnliche Beiträge