Kritische Patches für Veeam, Terraform MCP Server und Django schließen elf Schwachstellen

Veeam hat in einem am 4. August veröffentlichten Sicherheitsbulletin vier Schwachstellen in der Veeam Service Provider Console beschrieben. Die Konsole wird von Hosting-Anbietern und Managed Service Providern genutzt, um Backups von Kunden zu betreiben und zu überwachen. Die Korrekturen stecken in Build 9.3.0.35057, den Veeam bereits am 29. Juli veröffentlicht hatte. Betroffen sind VSPC 9.2.1.33875 sowie alle früheren Builds der Versionsreihe 9.

Zwei der vier Veeam-Lücken sind als kritisch eingestuft. Der schwerwiegendere der beiden Fehler trägt einen CVSS-Wert von 9,5. Der Quelltext betont allerdings, dass die hohe Angriffskomplexität verhindert, dass sich die Schwachstelle geradlinig ausnutzen lässt; dass keine Anmeldung nötig ist, bedeutet hier also nicht automatisch eine einfache Ausnutzung. Hinzu kommen zwei Schwachstellen mit hohem Schweregrad: CVE-2026-58067, ein Denial-of-Service durch Speicherauslastung ohne Anmeldung, sowie CVE-2026-58071. Letztere legt die API einer vorgeschalteten Appliance für kurze Zeit nach Beginn einer Administratorsitzung mit den Rechten eines Portal-Administrators offen.

Für Veeam ist es bereits die zweite kritische Patch-Runde für die Konsole innerhalb von etwa drei Monaten. Im Mai hatte das Unternehmen bereits CVE-2026-32998 behoben, eine mit 9,4 bewertete Schwachstelle zur Remotecodeausführung im Zusammenhang mit der Ausführung von Alarmskripten.

HashiCorp hat seinerseits drei zusammenhängende Schwachstellen im Terraform MCP Server behoben. Das Produkt verbindet KI-Assistenten über das Model Context Protocol mit Terraform. Die Fehler wurden am 28. Juli offengelegt und in Version 1.1.0 behoben; die korrigierte Version hatte HashiCorp bereits am 14. Juli veröffentlicht. Am 4. August folgte zusätzlich Version 1.2.0. Nicht betroffen sind Bereitstellungen, die ausschließlich im stdio-Modus laufen. Die Schwachstellen betreffen den für zentrale, gemeinsam genutzte Deployments gedachten Streamable-HTTP-Modus.

Am schwersten wiegt CVE-2026-16498 mit CVSS 10,0. Es handelt sich um einen Cross-Tenant-Fehler zur Wiederverwendung von Zugangsdaten im zustandslosen HTTP-Modus. Laut Quelltext vergibt die zugrunde liegende MCP-Bibliothek keine eindeutigen Sitzungskennungen, während der Server seinen Zugangsdaten-Cache genau auf diese Kennungen stützte, um Benutzer auseinanderzuhalten. Dadurch konnte das Terraform-Token eines Benutzers für spätere Anfragen anderer Benutzer wiederverwendet werden.

Die zweite Isolationsschwäche, CVE-2026-16496 mit CVSS 8,9, betrifft den zustandsbehafteten Modus, der bei zentralem Betrieb der Standard ist. Hier diente die MCP-Sitzungskennung als einziger Schlüssel für den Cache, ohne den zwischengespeicherten Client an das erzeugende Token zu binden. Wer an die Sitzungskennung eines anderen Benutzers gelangte, konnte damit Werkzeugaufrufe über dessen Terraform-Client ausführen und auf Ressourcen zugreifen, die dessen Token erlaubte. Juan Pablo Martinez Kuhn von Coinspect meldete diese Schwachstelle; die beiden anderen fand HashiCorp intern.

Die dritte HashiCorp-Lücke, CVE-2026-14869 mit CVSS 8,6, ist ein serverseitiger Request-Forgery-Fehler. Eine Middleware blockierte eine vom Client gelieferte Terraform-Adresse nur dann, wenn sie als HTTP-Header übermittelt wurde, nicht aber als Query-Parameter. Ein nicht authentifizierter Angreifer mit Zugriff auf den Streamable-HTTP-Listener konnte den Server so veranlassen, sein konfiguriertes Bearer-Token an einen vom Angreifer kontrollierten Endpunkt zu senden. HashiCorp weist zudem auf eine Abweichung bei den betroffenen Versionsbereichen hin: Das Sammelbulletin nennt Versionen 0.2.1 bis 1.0.0, die einzelnen CVE-Einträge beginnen dagegen bei 0.3.0. Einig sind sich beide Quellen darin, dass Version 1.1.0 die erste fehlerbereinigte Ausgabe ist.

Django hat mit den Versionen 6.0.8 und 5.2.17 vier CVEs behoben; dieselben Korrekturen wurden auch in den Hauptzweig und den Release-Candidate-Zweig von Django 6.1 übernommen. Nach der eigenen Sicherheitsrichtlinie des Projekts wird nur eine der vier Lücken als hoch eingestuft: CVE-2026-15307 in GeoDjango, der Komponente für geografische Daten. Räumliche Abfragen akzeptierten dort Werte vom Typ str und dict und reichten sie an GDALRaster weiter, wenn sie wie Rasterdaten aussahen.

Abhängig vom eingesetzten Raster-Treiber konnte das Dateien auf die Festplatte schreiben oder den Django-Prozess zu einer Netzwerkanfrage veranlassen. Wird eine Datei an einen Ort geschrieben, von dem die Anwendung später importiert, kann das laut Quelltext zu Remotecodeausführung führen. Der dokumentierte Angriffsweg über das Admin-Interface setzt ein Mitarbeitenden-Konto mit Ansichtsrechten auf ein registriertes Modell mit räumlichem Feld voraus. Die Korrektur unterbindet dict-Werte und Zeichenketten, die keine gültigen GEOSGeometry-Werte sind, in räumlichen Abfragen; direkte Zuweisungen an Modellfelder akzeptieren diese Typen weiterhin. Nicht mehr unterstützte ältere Zweige, darunter Django 5.1, 5.0 und 4.2, wurden nicht untersucht und könnten ebenfalls betroffen sein.