bishopfox/cve-2026-58073-checkSicherheitslücke in der Veeam Service Provider Console zur Authentifizierungsumgehung erkennen – CVE-2026-58073
Ein sicherer, nicht authentifizierter Detektor für die KB4893-Schwachstellen in Veeam Service Provider Console (veröffentlicht am 04.08.2026). Er beantwortet eine Frage pro Ziel, vor jeder Authentifizierung oder TLS: Sind die KB4893-Fixes auf dieser Konsole vorhanden?
Das Hauptpaar ist eine Kette. CVE-2026-58073 (CVSS 9.5) erlaubt es einem nicht authentifizierten Netzwerk-Peer, einen verbundenen Management-Agenten zu impersonieren und das echte Zertifikat dieses Agenten ausgestellt zu bekommen, weil der Agenten-Handshake die Autorisierung aus der GUID ableitet, die der Peer in sein eigenes Zertifikat geschrieben hat. CVE-2026-58072 (CVSS 9.0) ist ein beliebiges Dateischreiben, das erreichbar ist, sobald man eine Agenten-Identität besitzt. Verkettet ergeben sie eine nicht authentifizierte Remote-Codeausführung auf der Konsole, die die Backups jedes Mandanten verwaltet. Das gleiche Advisory behebt auch CVE-2026-58071 (CVSS 8.2, proxierte Appliance-API als Portal-Administrator) und CVE-2026-58067 (CVSS 8.7, nicht authentifizierter Speicher-Erschöpfungs-DoS). CVE-2026-58073 und CVE-2026-58072 wurden Veeam über HackerOne gemeldet; das Advisory nennt den Melder nicht.
Dieses Skript versucht nicht, eine Impersonation durchzuführen, ein Zertifikat anzufordern oder eine Datei zu schreiben. Es liest die beworbene Protokollgeneration des Routers und sonst nichts.
Ja. Der Detektor ist für den Produktions- und Bewertungseinsatz konzipiert:
ConnectorSaveFilesChannelHostProxy.m_multiplexers. Es wird kein Empfänger registriert, kein Kanal oder Multiplexer aufgebaut,
kein Agenten-Datensatz berührt. Ein Receiver-Typ-Handshake würde einen Namen registrieren; dieses Tool sendet
nie einen.ConnectionHub.log, jede mit dem Empfängernamen bf-probe-<uuid4>, damit ein Verteidiger einen Scan von einem
Angriff unterscheiden kann. Die genauen Zeilen finden Sie unten.VULNERABLE gemeldet, nachdem es nachweist, dass es ein VSPC
ConnectionHub ist (siehe unten), sodass ein stiller TCP-Dienst nicht mit einer ungepatchten Konsole verwechselt
werden kann.Pro Ziel öffnet das Tool zwei TCP-Verbindungen und sendet auf jeder einen ConnectionHub-Handshake, der einen
Empfänger bf-probe-<uuid4> benennt, der nicht existieren wird.
Unter dem Standard---transport auto kostet ein Ziel, dessen Transport nicht der durch seinen Port implizierte ist,
eine zusätzliche Verbindung: Die Sonde mit dem falschen Transport wird während des Handshakes abgelehnt, bevor ein
Empfängername gelesen wird, und der richtige Transport wird dann für beide echten Sonden verwendet. Fixieren Sie
--transport direct oder --transport gateway, um es bei genau zwei Verbindungen zu halten — sinnvoll, wenn Sie
eine Verbindungsanzahl in einem Änderungsantrag angegeben haben.
Auf dem Server geänderter Zustand: keiner. Der Connector-Codepfad führt eine Wörterbuchsuche in
ChannelHostProxy.m_multiplexers durch, findet nichts und gibt einen Fehler zurück. Es wird kein Empfänger
registriert, kein Multiplexer oder Kanal erstellt, keine TLS-Sitzung ausgehandelt, kein Agenten-Datensatz berührt.
Dieses Tool sendet nie einen Receiver-Typ-Handshake, derjenige wäre es, der einen Namen registrieren würde.
Logeinträge werden in
%ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log geschrieben. Wörtlich von einem
Live-9.2.1.33875-ConnectionHub, mit Zeitstempeln und Scope-JSON gekürzt:
Sonde 1 (Version 6), sowohl gepatchte als auch ungepatchte Builds:
[INFO] ChannelHostProxy: Accept connection begin {"RemoteEndPoint":"<ip>:<port>","Line":"1"}
[INFO] ChannelHostProxy: Accept connection end {"RemoteEndPoint":"<ip>:<port>","Line":"2",...}
[WARN] ChannelHostProxy: Cannot connect transmitter. Requested receiver not found
(receiver name:bf-probe-<uuid>) {"RemoteEndPoint":"<ip>:<port>","Line":"3",...}
Sonde 2 (Version 7), nur gepatchte Builds:
die gleichen drei Zeilen
Sonde 2 (Version 7), ungepatchte Builds:
[INFO] ChannelHostProxy: Accept connection begin
[WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
[INFO] ChannelHostProxy: Accept connection end
Zwei Verbindungen, sechs Zeilen, keine weiteren Einträge und keine Zustandsänderung — bestätigt auf einem Live-Host.
Der wörtliche String bf-probe- in ConnectionHub.log identifiziert den Datenverkehr dieses Tools, sodass ein
Verteidiger ihn zuordnen und ein Scan-Team nachweisen kann, was es gesendet hat. Ändern Sie RECEIVER_PREFIX im
Quellcode, wenn Sie eine andere Markierung benötigen.
Der ConnectionHub-Management-Agenten-Router liest einen Client-Handshake vor jeder Authentifizierung oder TLS, und
Request.Read validiert die vom Client beworbene Protokollversion gegen einen fest codierten Bereich. Der Fix
erweiterte diesen Bereich im selben Build, der die CVEs behob:
| Build | Prüfung | Akzeptiert |
|---|---|---|
<= 9.2.1.33875 (verwundbar) | (uint)(versionByte - 3) <= 3 | 3, 4, 5, 6 |
>= 9.3.0.35057 (gepatcht) | (uint)(versionByte - 3) <= 4 | 3, 4, 5, 6, 7 |
Ein Handshake, der Version 7 bewirbt, ist also ein sauberer binärer Diskriminator. Der Detektor sendet zwei Sonden pro Ziel, in dieser Reihenfolge aus gutem Grund (die Transporterkennung kann eine dritte hinzufügen — siehe unten):
| Sonde | Bewirbt | Zweck |
|---|---|---|
| 1 | Version 6 | Muss Requested receiver not found zurückgeben, was beweist, dass das Ziel wirklich ein VSPC ConnectionHub ist |
| 2 | Version 7 | Eine Antwort bedeutet PATCHED; Stille bedeutet VULNERABLE |
Ohne das Stufe-1-Gate würde Stille in Sonde 2 auch zu jedem stillen TCP-Dienst im Internet passen, und Firewalls würden als verwundbare Veeam-Konsolen gemeldet.
Es funktioniert über beide Pfade, die ein Management-Agent verwendet:
| Transport | Port | Exposition |
|---|---|---|
| Direkt zum ConnectionHub | 9999 | normalerweise intern |
| Über ein Veeam Cloud Connect Gateway | 6180 | konstruktionsbedingt internetzugewandt |
Der Gateway-Pfad benötigt einen Relay-Prolog, den der direkte Pfad nicht haben darf, daher dient Sonde 1 gleichzeitig
als Transporterkennung. Unter dem Standard---transport auto versucht es einen Transport, und wenn das
Fingerprint-Gate nicht besteht, den anderen. Welcher auch immer besteht, wird verriegelt, und Sonde 2 verwendet
ihn erneut — eine gemischte Zieldatei benötigt keine Pro-Host-Annotation.
Die Verriegelung ist tragend. Wenn Sonde 2 auf dem anderen Transport erneut versuchen könnte, wäre Stille nicht mehr
der Versionsprüfung zuzuschreiben, sondern nur noch „einer von zwei Byte-Pfaden hat nicht geantwortet", und genau so
wird ein falsches VULNERABLE erzeugt.
Welcher Transport zuerst versucht wird, entscheidet der Port, und das ist nicht kosmetisch — die beiden Fehlanpassungen scheitern mit sehr unterschiedlicher Geschwindigkeit:
| Fehlanpassung | Wie das entfernte Ende es liest | Kosten |
|---|---|---|
| Relay-Prolog → direkter Hub | int16-Meta von hostType 44 / versionByte 0, scheitert an Request.Read-Bereichsprüfung | in einem Roundtrip entsorgt |
| Direkter Handshake → Gateway | int32-Framelänge von 1.012.729.346 | Gateway wartet auf Bytes, die nie ankommen; verbraucht das volle Timeout |
auto führt also mit dem Dienst, dem der Port gehört: zuerst Gateway auf 6180, sonst überall direkt. Das hält den
häufigen Fall bei einem einzigen Versuch und die teure Fehlanpassung vom schnellen Pfad fern. Eine Sonde, die TCP
überhaupt nicht öffnen kann, bricht kurz ab, ohne den zweiten Transport zu versuchen, sodass tote Hosts in einem
breiten Sweep ein Timeout kosten, nicht zwei.
VULNERABLE bedeutet „die KB4893-Fixes sind nicht vorhanden", nicht „das ist 9.2.1.33875". Builds älter als
9.2.1 teilen dieselbe Versionsprüfung, daher sollten sie Protokoll 6 melden und ebenfalls als verwundbar gemeldet
werden (aus dem Code abgeleitet, nicht gemessen — siehe Einschränkungen), aber das Tool kann 9.2.1 nicht von
9.1 oder 8.1 unterscheiden. Bestätigen Sie den exakten Build in der Konsolen-UI, wenn Sie ihn benötigen.
# einzelner Host (Standard TCP/9999)
./cve_2026_58073_check.py vspc.example.com
# expliziter Port, mehrere Hosts
./cve_2026_58073_check.py vspc.example.com:9999 10.0.0.5
# Liste scannen, ein Ziel pro Zeile ('#'-Kommentare erlaubt), kompakte Ausgabe
./cve_2026_58073_check.py -f targets.txt --brief
# maschinenlesbare Ausgabe für Pipelines
./cve_2026_58073_check.py -f targets.txt --json > results.json
# ein Veeam Cloud Connect Gateway — der Relay-Transport wird automatisch erkannt
./cve_2026_58073_check.py cc-gw.example.com:6180
# Transport fixieren, um die Erkennung zu überspringen (Port wird dann standardmäßig 6180)
./cve_2026_58073_check.py --transport gateway cc-gw.example.com
# Wire-Codecs ohne Netzwerkzugriff validieren
./cve_2026_58073_check.py --self-test
| Flag | Beschreibung |
|---|---|
targets | Ein oder mehrere HOST[:PORT] (Port standardmäßig 9999, oder 6180 mit --transport gateway) |
-f, --targets-file DATEI | Ziele aus einer Datei lesen (eines pro Zeile; #-Kommentare) |
--transport {auto,direct,gateway} | Wie der ConnectionHub erreicht wird. auto (Standard) erkennt es pro Ziel; gateway stellt den Cloud-Connect-Relay-Prolog voran und setzt den Standardport auf 6180 |
-p, --port PORT | Standardport überschreiben |
--timeout SEK | Timeout pro Sonde (Standard: 8) |
--workers N | Gleichzeitige Ziele (Standard: 16); Ausgabe bleibt in Eingabereihenfolge |
-b, --brief | Eine ausgerichtete Zeile pro Ziel — ideal zum Scannen vieler Hosts |
--json | Strukturiertes JSON ausgeben, einschließlich jeder pro Ziel gesendeten Sonde |
--no-color | Farbige Ausgabe deaktivieren (berücksichtigt auch NO_COLOR und Nicht-TTY) |
--self-test | Die .NET-Wire-Codecs validieren und beenden; kein Netzwerkzugriff |
Eine ungepatchte Konsole (die standardmäßige zweizeilige Ausgabe). Die Markierung [!] und VULNERABLE werden
auf einem TTY rot dargestellt:
$ ./cve_2026_58073_check.py vspc.example.com
[!] vspc.example.com:9999: VULNERABLE [protocol-7-rejected]
ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)
Eine gepatchte Konsole:
$ ./cve_2026_58073_check.py patched.example.com
[+] patched.example.com:9999: PATCHED [protocol-7-accepted]
ConnectionHub accepts protocol 7, so the KB4893 fixes are present (>= 9.3.0.35057)
Ein Gateway-Ziel, mit automatisch erkanntem Relay-Transport. Das Suffix (gateway) benennt den Transport, über
den das Urteil gefällt wurde:
$ ./cve_2026_58073_check.py cc-gw.example.com:6180
[!] cc-gw.example.com:6180 (gateway): VULNERABLE [protocol-7-rejected]
ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)
Ein Bestand wird gesweept, eine ausgerichtete Zeile pro Host (--brief). Der Exit-Status ist 1, wenn ein Host
VULNERABLE ist, sonst 0 — praktisch in Skripten:
$ ./cve_2026_58073_check.py -f targets.txt --brief; echo "exit: $?"
VULNERABLE vspc.example.com:9999 protocol-7-rejected
PATCHED patched.example.com:9999 protocol-7-accepted
UNAFFECTED fileserver.example.com:9999 not-vspc
ERROR unused.example.com:9999 unreachable
exit: 1
Maschinenlesbare Ausgabe für Pipelines (--json). Jede Sonde ist pro Ziel enthalten, sodass ein Befund aus den
Beweisen neu abgeleitet werden kann, statt ihm zu vertrauen. transport ist derjenige, über den das Urteil gefällt
wurde, und jede Sonde trägt den von ihr verwendeten Transport — ein automatisch erkanntes Ziel zeigt also auch den
abgelehnten Versuch:
$ ./cve_2026_58073_check.py vspc.example.com --json
[
{
"target": "vspc.example.com:9999",
"host": "vspc.example.com",
"port": 9999,
"transport": "direct",
"verdict": "VULNERABLE",
"reason": "protocol-7-rejected",
"detail": "ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)",
"protocol_version": 6,
"affected_cves": [
"CVE-2026-58073",
"CVE-2026-58072",
"CVE-2026-58071",
"CVE-2026-58067"
],
"probes": [
{
"version_byte": 6,
"transport": "direct",
"connected": true,
"responded": true,
"status": "Error",
"message": "Cannot connect transmitter. Requested receiver not found (receiver name:bf-probe-b7c40be0-e2e8-41dc-9fc3-cbbd7345954a)",
"error": ""
},
{
"version_byte": 7,
"transport": "direct",
"connected": true,
"responded": false,
"status": "",
"message": "",
"error": ""
}
]
}
]
| Urteil | Grund-Tag | Bedeutung |
|---|---|---|
VULNERABLE | protocol-7-rejected | Bestätigter VSPC ConnectionHub, der Protokoll 6 akzeptiert und 7 ablehnt. Die KB4893-Fixes fehlen (<= 9.2.1.33875). |
PATCHED | protocol-7-accepted | Bestätigter VSPC ConnectionHub, der Protokoll 7 akzeptiert. Die KB4893-Fixes sind vorhanden (>= 9.3.0.35057). |
UNAFFECTED | not-vspc | TCP akzeptiert, aber auf keinem versuchten Transport mit einem gültigen ConnectionHub-Handshake geantwortet, also kein VSPC ConnectionHub. |
INCONCLUSIVE | unexpected-reply | Auf die Fingerprint-Sonde mit etwas anderem als Requested receiver not found geantwortet. |
INCONCLUSIVE | inconclusive-discriminator | Das Fingerprint-Gate bestanden, dann auf die Version-7-Sonde weder bestanden noch nicht bestanden geantwortet — oder diese zweite Verbindung schlug vollständig fehl. Erneut versuchen. |
ERROR | unreachable | Keine Verbindung möglich, oder das Cloud-Connect-Gateway verweigerte den Relay-Prolog auf dem zuerst versuchten Transport (was unter auto jedes Ziel auf Port 6180 bedeutet). |
| Code | Bedeutung |
|---|---|
0 | Kein Ziel war VULNERABLE |
1 | Mindestens ein Ziel ist VULNERABLE |
2 | Verwendungsfehler (ungültige Argumente / nicht lesbare Zieldatei) |
--transport auto; fixieren Sie --transport direct, um den ungetesteten Pfad vollständig
aus einem Sweep herauszuhalten.VULNERABLE-Urteil spricht über den Patch-Zustand, nicht darüber, ob jemand die Konsole
ausgenutzt hat. Ausnutzung hinterlässt ihre eigenen Spuren in den Logs der Konsole sowohl auf gepatchten als auch
auf ungepatchten Builds; suchen Sie separat danach.Upgrade auf Veeam Service Provider Console 9.3.0.35057 oder höher (KB4893). Alle vier Probleme sind in diesem einen Build behoben, und es gibt keinen 9.2.x-Backport, daher ist die Behebung ein Versions-Upgrade und kein Hotfix.
Zwei Dinge, die das Upgrade nicht tut. Es schränkt nicht ein, wer TCP/9999 erreichen kann, das nur die Subnetze beantworten sollte, in denen Ihre Management-Agenten leben. Und es widerruft kein Agentenzertifikat, das die Konsole bereits ausgestellt hat, einschließlich eines, das einem Angreifer ausgestellt wurde, während sie ungepatcht war. Wenn Sie Beweise für Ausnutzung finden, eröffnen Sie einen Veeam-Support-Fall für Anleitung zu kompromittierten Agentenzertifikaten: Deren Rotation ist kein dokumentiertes Verfahren, und die Zertifikate, die Sie im Portal verwalten können, sind nicht die CA, die Agentenzertifikate signiert.
Dieser Code wird unter einer MIT-Lizenz verteilt.
Die Verwendung dieses Tools zum Angriff auf Ziele ohne vorherige gegenseitige Zustimmung ist illegal. Es liegt in der Verantwortung des Endbenutzers, alle geltenden lokalen, staatlichen und bundesstaatlichen Gesetze einzuhalten. Die Entwickler übernehmen keine Haftung und sind nicht verantwortlich für Missbrauch oder Schäden, die durch dieses Programm verursacht werden.