Eine neu entdeckte Schwachstelle in Traefiks experimentellem ingress-nginx-Provider deaktivierte fünf Monate lang unbemerkt die Verifizierung von TLS-Zertifikaten – obwohl Betreiber sie in der Konfiguration aktiviert hatten.
Der Fehler kehrte eine wichtige Sicherheitsannotation um und setzte nachgelagerte HTTPS-Dienste in Kubernetes-Umgebungen Angriffen durch Man-in-the-Middle aus.
Die Schwachstelle setzte „… HTTPS-Backends Man-in-the-Middle-Angriffen aus“, sagte AISLE-Forscher.
Stanislav Fort, Mitgründer und Chief Scientist bei AISLE, ergänzte: „Herkömmliche Scanner übersehen dies vollständig, weil der Code korrekt aussieht und alle Tests besteht. Der Fehler liegt nicht in der Syntax, sondern in der semantischen Beziehung zwischen zwei Systemen. Es handelt sich um eine logische Diskrepanz, die ein Verständnis der Absicht erfordert, nicht nur den Abgleich von Mustern.“
Eine kleine Fehlkonfiguration mit großen Folgen
Traefik ist einer der weltweit am weitesten verbreiteten cloudnativen Ingress-Controller mit mehr als 60.000 GitHub-Sternen und über 3 Milliarden Downloads.
Er leitet den Datenverkehr für Finanzdienstleister, SaaS-Plattformen, Gesundheitssysteme und Kubernetes-Cluster von Unternehmen über AWS, Azure, GCP und On-Premises-Umgebungen.
Da Annotationen in Kubernetes im großen Maßstab als Richtlinien fungieren, kann eine einzige umgekehrte Sicherheitseinstellung den Schutz über Tausende von Routen hinweg schwächen.
Viele Teams setzten Traefiks ingress-nginx-Provider gezielt ein, um Sicherheitskonfigurationen nach NGINX-Art zu bewahren – einschließlich der Zertifikatsverifizierung von Backends. Stattdessen wurde die Verifizierung ohne Warnung deaktiviert.
Wie der TLS-Verifizierungsfehler in Traefik entstand
Die Schwachstelle (CVE-2025-66491) entstand durch eine semantische Diskrepanz zwischen NGINXs proxy-ssl-verify-Annotation und Gos InsecureSkipVerify-Feld.
In NGINX aktiviert die Einstellung proxy-ssl-verify: “on” die Verifizierung von Backend-Zertifikaten, während die Einstellung InsecureSkipVerify: true in Gos TLS-Implementierung die Verifizierung deaktiviert.
Traefiks ingress-nginx-Provider ordnete dieses Verhalten fälschlicherweise zu und verwendete folgende Logik: InsecureSkipVerify: strings.ToLower(ptr.Deref(cfg.ProxySSLVerify, “off”)) == “on”.
Dadurch deaktivierte das Setzen der Annotation auf „on“ unbeabsichtigt die Verifizierung, während das Setzen auf „off“ sie aktivierte.
Die Unit-Test-Suite verstärkte diese Umkehrung, indem sie das umgekehrte Verhalten als erwartetes Ergebnis definierte und den Fehler so unbemerkt die CI passieren ließ.
Das Problem wird gefährlich, wenn ein Angreifer sich im Netzwerkpfad zwischen Traefik und einem Backend-Dienst positionieren kann – etwa durch ARP-Spoofing, ein kompromittiertes Sidecar oder falsch konfigurierte Netzwerkrichtlinien.
Bei übersprungener Verifizierung konnte ein Angreifer ein gefälschtes Zertifikat vorlegen, den Datenverkehr abfangen und entschlüsseln, Anmeldedaten oder Sitzungstoken stehlen, Antworten verändern oder den Datenverkehr eines Dienstes umleiten – und das alles, während die verschlüsselte Verbindung für die Betreiber normal aussah.
Dies stellt ein besonderes Risiko in mandantenfähigen Clustern, hybriden Umgebungen oder Architekturen ohne durchgängig durchgesetztes mTLS dar.
Der Fehler betraf die Traefik-Versionen v3.5.0 bis v3.6.2 und wurde in Version v3.6.3 behoben.
Risiken durch den TLS-Verifizierungsfehler in Traefik mindern
Um diese Schwachstelle zu beheben, müssen Unternehmen sowohl auf die korrigierte Traefik-Version aktualisieren als auch die Anwendung, Validierung und Überwachung von TLS-Richtlinien in der gesamten Umgebung verbessern.
- Führen Sie ein Upgrade auf Traefik v3.6.3 für die vollständige Behebung durch, oder setzen Sie vorübergehend proxy-ssl-verify: “off” oder entfernen Sie die Annotation, um eine ordnungsgemäße TLS-Verifizierung aufrechtzuerhalten.
- Prüfen Sie Ingress-Ressourcen und Annotationen auf umgekehrte oder unsichere TLS-Einstellungen, und schränken Sie durch strengere RBAC-Kontrollen ein, wer die Ingress-Konfiguration ändern darf.
- Verwenden Sie Admission Controller oder Policy-Engines wie OPA/Gatekeeper oder Kyverno, um sichere TLS-Konfigurationen durchzusetzen und unsichere Annotationswerte zu blockieren.
- Setzen Sie eine starke dienstübergreifende Verschlüsselung durch, um die Abhängigkeit von der TLS-Verifizierung auf Ingress-Ebene allein zu verringern.
- Überwachen Sie den Backend-Datenverkehr auf Anomalien wie unerwartete Zertifikatsketten, Routing-Änderungen oder ungewöhnliche Muster in der Dienstkommunikation.
- Prüfen Sie CI-Tests und Konfigurationspipelines auf semantische Diskrepanzen und implementieren Sie eine Drift-Erkennung, um das erneute Auftreten unsicherer TLS-Einstellungen zu verhindern.
Mit diesen Maßnahmen können Unternehmen einen zuverlässigeren TLS-Schutz aufrechterhalten und die Wahrscheinlichkeit verringern, dass Konfigurationsprobleme unbemerkt bleiben.
Unsichtbare Fehlkonfigurationen in cloudnativen Architekturen
CVE-2025-66491 verdeutlicht eine größere Herausforderung in cloudnativen Systemen: sicherzustellen, dass die Absicht einer Konfiguration korrekt über die verschiedenen Komponenten hinweg übertragen wird, die Sicherheitsrichtlinien durchsetzen.
Obwohl der zugrunde liegende Fehler nur aus wenigen Zeichen bestand, trat er in weit verbreiteter Infrastruktur auf und führte zu einem Verhalten, das von den Erwartungen der Betreiber abwich.
Derartige Probleme können in komplexen, mehrschichtigen Architekturen entstehen, in denen Einstellungen, die in einem System definiert sind – etwa NGINX-Annotationen –, einem anderen System zugeordnet werden müssen, beispielsweise Gos TLS-Konfiguration.
Solche Abweichungen sind schwer zu erkennen, weil sie CI-Tests bestehen und von herkömmlichen Scan-Tools unbemerkt bleiben können und erst bei einer gründlicheren oder systembewussten Analyse sichtbar werden.
wie Zero Trust hervorheben, die auf eine explizite Validierung auf jeder Ebene setzen.