CVE-2026-14540: SSRF in Google MCP Toolbox

CVE-2026-14540 ließ HTTP-Anfragen von MCP Toolbox Weiterleitungen folgen, ohne das endgültige Netzwerkziel zu prüfen. Aktualisieren Sie auf Version 1.5.0 oder neuer.^{[1], [3]}

💡 Einfache Erklärung (ELI5)

Eine Poststelle prüft die erste Adresse eines Pakets und folgt danach jedem Weiterleitungsaufkleber, ohne das neue Ziel zu prüfen. Eine HTTP-Weiterleitung ist so ein Aufkleber: Ohne Prüfung der endgültigen IP kann eine für eine normale Website gedachte Anfrage in einem privaten Netzwerk landen. Die Korrektur prüft das tatsächliche Ziel beim Verbindungsaufbau und auch Weiterleitungsziele.^{[2], [4], [7]}

Kernkonzepte & Begriffe

Server-side request forgery (SSRF): Ein Dienst wird dazu gebracht, eine HTTP-Anfrage an ein vom Angreifer beeinflusstes Ziel zu senden. Da die Anfrage vom Server ausgeht, kann sie Netze erreichen, die dem Aufrufer nicht zugänglich sind.^[6]
HTTP-Weiterleitung: Eine Antwort kann den HTTP-Client anweisen, eine weitere Anfrage an eine andere URL zu senden. Nur die ursprüngliche URL zu prüfen, begrenzt das Ziel dieser Folgeanfrage nicht.^{[4], [7]}
DNS-Rebinding und TOCTOU: Ein Hostname kann bei der Prüfung zu einer Adresse und beim Öffnen des Sockets zu einer anderen aufgelöst werden. Die Prüfung der aufgelösten IP beim Verbinden schließt diese Lücke zwischen Prüfung und Nutzung.^{[2], [7]}
Generic HTTP source und tool: MCP-Toolbox-Komponenten, die HTTP-Anfragen aus konfigurierten Endpunkten und Tool-Parametern erstellen. Die Warnung bezeichnet diesen Pfad als betroffen.^{[1], [2], [4]}
CWE-918: Server-Side Request Forgery (SSRF): Die Anwendung ruft eine URL oder ein Ziel ab, ohne ausreichend zu begrenzen, wohin die Anfrage gehen darf.^[6]

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-918
D3-OTF Filterung des ausgehenden Datenverkehrs — Die in diesem Leitfaden beschriebene Beschränkung des ausgehenden Netzwerkverkehrs begrenzt die für den Dienst oder Host erreichbaren Ziele.

Ursachenanalyse

In betroffenen Versionen erzeugte die generic HTTP source einen Go-http.Client mit Timeout und Transport, jedoch ohne zielbewusste Weiterleitungsrichtlinie und ohne IP-Prüfung an der Socket-Grenze. Go folgte Weiterleitungen standardmäßig. Da konfigurierte HTTP-Tools Parameter in Anfragen übernehmen können, konnte ein manipulierter Wert oder eine Weiterleitung die Anfrage vom vorgesehenen Ziel weglenken. Nur die ursprüngliche URL zu prüfen reicht nicht: Eine Weiterleitung ändert das Ziel, und DNS kann zwischen Prüfung und Verbindung eine andere IP liefern. Die Upstream-Korrektur ergänzt SSRFGuard, weist blockierte Ziele in CheckRedirect zurück und prüft die aufgelöste IP nochmals an der Verbindungsschicht. Private, Loopback-, Link-Local- und andere nicht globale Adressen sind standardmäßig gesperrt; Freigaben für IP-Bereiche oder private Netze sind Konfigurationsausnahmen und müssen eng begrenzt sein.^{[1], [2], [4]}

Schritt-für-Schritt Angriffsablauf

Schritt 1

Erreichbarkeit mit drei Bedingungen prüfen

Diese Kette setzt alle drei Bedingungen voraus: (1) Ein betroffenes Deployment der Version 0.3.0 bis 1.4.0 verwendet generic HTTP source/tool; (2) ein Aufrufer kann diesen Pfad aufrufen und die URL/den Pfad steuern oder eine Weiterleitung auslösen; und (3) der Toolbox-Host kann das Ziel erreichen. Fehlt eine Bedingung, erreicht diese Kette das Ziel über diesen Pfad nicht. Authentifizierung und Zugriffskontrollen des Ziels gelten weiterhin.^[1]

Schritt 2

Ein Tool-Argument beeinflusst eine ausgehende Anfrage

Ein konfiguriertes HTTP-Tool kombiniert seinen Basisendpunkt mit Eingabewerten. Die CVE-Beschreibung besagt, dass präparierte Pfadparameter die HTTP source zu einem anderen Ziel umleiten können. Ein MCP-Benutzer oder Agent ruft das Tool auf; nicht vertrauenswürdige Inhalte beeinflussen diesen Aufruf nur, wenn der umgebende Ablauf dies zulässt.^{[1], [2]}

Schritt 3

Die ursprüngliche URL begrenzt Weiterleitungen nicht

Dem betroffenen Client fehlten ein restriktiver CheckRedirect-Hook und die Prüfung der Ziel-IP. Eine Antwort kann auf eine andere URL verweisen; daher begrenzt die Prüfung nur der Basis- oder ersten Anfrage die Folgeanfrage nicht.^{[1], [2]}

Schritt 4

Toolbox fragt aus der eigenen Netzwerkposition an

Die Folgeanfrage geht vom Toolbox-Host aus und erreicht Ziele, die dessen Netzwerk zulässt. Interne Dienste oder andere erreichbare Endpunkte können so Anfragen erhalten, die der MCP-Aufrufer nicht direkt senden könnte. Das CVE belegt weder eine Offenlegung von Cloud-Anmeldedaten in jeder Bereitstellung noch den Erfolg jeder Weiterleitung.^[1]

Schritt 5

Aktualisieren und ausgehende Grenzen prüfen

Aktualisieren Sie MCP Toolbox auf 1.5.0 oder neuer. Der Fix prüft konfigurierte literale IPs und Weiterleitungsziele und blockiert beim Verbinden unzulässige aufgelöste IPs; damit wird auch DNS-Rebinding adressiert. Lassen Sie allowPrivateNetworks deaktiviert, sofern nicht erforderlich, begrenzen Sie explizite Freigaben eng und setzen Sie zusätzlich eine ausgehende Netzwerkrichtlinie durch.^{[2], [3], [4]}

Quellcode: Verwundbar vs. Sicher

Dieser Vergleich zeigt gezielt den Upstream-HTTP-Clientpfad und ersetzt nicht die ganze Datei. Der integrierte Fix ergänzt SSRFGuard: Er prüft Weiterleitungsziele und weist blockierte aufgelöste IPs auch beim Verbindungsaufbau zurück. So wird die DNS-Rebinding-Lücke geschlossen, die eine reine Prüfung bei der Weiterleitung offenließe. Der Guard sperrt private und andere nicht globale Adressen standardmäßig. allowPrivateNetworks, allowedIpRanges und customBlockedIpRanges sind weitreichende Steuerungen; eine Allowlist-Ausnahme darf nur den benötigten Bereich umfassen. Quelldatei: internal/sources/http/http.go.^[2]

Quelltextauszug: Auszug des HTTP-Clients und der Weiterleitungsrichtlinie

VERWUNDBARE IMPLEMENTIERUNG

client := http.Client{
	Timeout: duration,
	Transport: tr,
}

// Ohne CheckRedirect-Richtlinie folgt der Client HTTP-Weiterleitungen gemäß
// der Standardrichtlinie. Auch der Transport schützt nicht vor SSRF-Zielen.

GEHÄRTETER SICHERHEITS-PATCH

client := &http.Client{
	Timeout: duration,
	Transport: tr,
	CheckRedirect: func(req *http.Request, via []*http.Request) error {
		if len(via) >= 10 {
			return fmt.Errorf("stopped after 10 redirects")
		}
		hostname := req.URL.Hostname()
		if ip := net.ParseIP(hostname); ip != nil {
			if guard.IsIPBlocked(ip) {
				return fmt.Errorf("redirect to blocked IP %s denied", ip)
			}
			return nil
		}
		addrs, err := resolver.LookupHost(req.Context(), hostname)
		if err != nil {
			return fmt.Errorf("failed to resolve redirect host %s: %w", hostname, err)
		}
		for _, addr := range addrs {
			if ip := net.ParseIP(addr); ip != nil && guard.IsIPBlocked(ip) {
				return fmt.Errorf("redirect host %s resolves to blocked IP %s", hostname, addr)
			}
		}
		return nil
	},
}
// Derselbe SSRFGuard wird auch beim Öffnen des Sockets angewendet,
// damit eine DNS-Antwort keine erlaubte Adresse durch eine blockierte ersetzt.

Checkliste für Engineering & Systemsicherheit

✓Inventarisieren Sie Google-MCP-Toolbox-Binärdateien, Container und Abhängigkeiten; behandeln Sie 0.3.0 bis 1.4.0 als betroffen und aktualisieren Sie auf 1.5.0 oder neuer.^{[1], [3]}
✓Prüfen Sie die Version des bereitgestellten Toolbox-Prozesses; ein Update des MCP-Clients, Agent-Frameworks oder Hostprogramms aktualisiert diesen Prozess nicht.^{[1], [3]}
✓Verfolgen Sie für jede generic HTTP source/tool, welche Argumente URL, Pfad, Host oder Weiterleitungen beeinflussen können, und entfernen Sie unnötige Zielsteuerung durch nicht vertrauenswürdige Eingaben.^{[1], [2]}
✓Lassen Sie allowPrivateNetworks ohne dokumentierten Bedarf deaktiviert; begrenzen Sie allowedIpRanges bei Aktivierung auf die kleinsten nötigen CIDRs und prüfen Sie die Ausnahme wie eine Firewall-Regel.^{[4], [2]}
✓Nutzen Sie customBlockedIpRanges für sensible Ziele, die auch bei breiterer Freigabe privater Netze unerreichbar bleiben müssen.^{[4], [2]}
✓Ergänzen Sie Regressionstests für direkte private und Loopback-IP-Adressen, auf gesperrte Bereiche aufgelöste Hostnamen, blockierte Weiterleitungen, Schleifen, ungültige CIDRs und wechselnde DNS-Antworten zwischen Prüfung und Verbindung.^[2]
✓Setzen Sie ausgehende Netzwerkrichtlinien auf Host-, Container- oder VPC-Ebene durch, damit eine spätere URL-Prüfregression keine Metadatendienste oder fremde interne Netze erreicht.^[7]
✓FlawOpen-Empfehlung zur Reaktion: Prüfen Sie bei exponierten betroffenen Instanzen HTTP-Protokolle und Netzwerkausgänge auf unerwartete Ziele; das CVE allein belegt keinen Datenzugriff.