go-micro: Deaktivierte TLS-Zertifikatsprüfung als Standard

Zusammenfassung

go-micro ist ein Go-Framework für verteilte Systeme. Der gemeinsam genutzte TLS-Helper setzt InsecureSkipVerify standardmässig auf true, sodass die TLS-Zertifikatsprüfung für gRPC-, HTTP-, RabbitMQ-Broker-, Consul- und etcd-Verbindungen deaktiviert ist. Ein Angreifer in einer Man-in-the-Middle-Position kann ein beliebiges Zertifikat vorlegen, den Datenverkehr abfangen oder verändern und Authentifizierungstoken sowie Zugangsdaten erbeuten. Die verwundbare Standardeinstellung betrifft nur betroffene go-micro-Versionen in Diensten, die diesen Helper verwenden.

Betroffen

• go-micro-Versionen vor 6.0.0 (gemäss CVE-Eintrag betroffen: 0 bis < 6.0.0)
• Der Quellcode von v5.30.0 zeigt die unsichere Standardeinstellung in internal/util/tls/tls.go
• Nur Anwendungen, die auf go-micro aufbauen, sind betroffen

Behoben in

• Auf go-micro 6.0.0 oder neuer aktualisieren (der CVE-Eintrag nennt 6.0.0 als korrigierte Version; es existieren neuere v6-Versionen)
• Nicht verifiziert: ob 6.0.0 die Standardeinstellung auf sicher umstellt, und der genaue Fix-Commit. Die Herstellerreferenzen direkt prüfen.

Umgehung

• Für v5-Installationen: die Umgebungsvariable MICRO_TLS_SECURE=true setzen, damit die Zertifikatsprüfung aktiviert wird (vom Hersteller dokumentiert; die Abdeckung aller Codepfade ist nicht bestätigt)
• Netzwerkzugriff zwischen Diensten, Brokern und Registries einschränken, um das Risiko von On-Path-Angriffen zu verringern
• Wo möglich CA-signierte Zertifikate oder gegenseitiges TLS (mTLS) verwenden

Ausnutzung

• CISA SSVC: Ausnutzung keine, automatisierbar nein, technische Auswirkung teilweise
• Keine Hinweise auf Ausnutzung in freier Wildbahn oder einen öffentlichen Proof of Concept gefunden
• EPSS 0.00194 (geringe vorhergesagte Ausnutzungswahrscheinlichkeit)
• Ein Angreifer muss sich im Netzwerkpfad positionieren können

Unsere Empfehlung

• In go.mod und go.sum nach go-micro.dev oder github.com/micro/go-micro suchen, um die Betroffenheit festzustellen
• Ein Update auf go-micro 6.0.0 oder neuer planen und die Änderungen testen
• Bis zur Korrektur MICRO_TLS_SECURE=true auf v5-Installationen setzen und die Netzwerkpfade zwischen Diensten einschränken
• NVD und GitHub-Sicherheitshinweise auf Aktualisierungen überwachen, da der NVD-Status noch Awaiting Analysis lautet
• Priorität: mittel für typische KMU ohne go-micro, hoch für Dienste, die es in nicht vertrauenswürdigen Netzen einsetzen

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• VulnCheck advisory www.vulncheck.com
• go-micro TLS helper source (v5.30.0) github.com
• go-micro fix commit github.com
• go-micro issue #2963 github.com
• go-micro repository github.com
• VulDB CVE entry vuldb.com
• Vulners (EPSS, CVSS 3.1) vulners.com
• go-micro v5 TLS documentation pkg.go.dev

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 31.10.2026 07:34.