Authlib: Manipulation von Discovery-Metadaten durch fehlende Issuer-Origin-Bindung

Zusammenfassung

Authlib 1.7.2 und frühere Versionen speichern OpenID-Connect-Discovery-Metadaten ohne Validierung zwischen und binden die zurückgegebenen Endpunkt-URLs nicht an den Origin der konfigurierten Metadaten-URL. Eine manipulierte oder vergiftete Discovery-Antwort kann daher Token-, Userinfo-, JWKS- und Logout-Endpunkte durch vom Angreifer kontrollierte URLs ersetzen. Authlib sendet anschliessend Autorisierungscodes, Client-Secrets und Bearer-Token an diese Endpunkte, ohne sie abzulehnen. Ausnutzung setzt voraus, dass die Discovery-Antwort oder der Cache manipuliert werden kann, zum Beispiel über ein kompromittiertes CDN, einen kompromittierten Upstream oder eine Netzwerkposition.

Betroffen

• Authlib 1.7.2 und frühere Versionen (gemäss CVE-Eintrag und Forschungsbericht des Herstellers)
• Versionen 1.8.0 und neuer: unbestätigt; ein Drittbericht behauptet, 1.8.0 sei betroffen, dies ist nicht verifiziert

Behoben in

Unbekannt. VulDB empfiehlt 1.7.3 oder neuer, dies ist jedoch nicht durch eine Authlib-Release-Notiz oder ein Advisory bestätigt. Es darf nicht davon ausgegangen werden, dass 1.7.3, 1.8.x oder 1.9.x behoben sind, bis das Authlib-Advisory dies bestätigt.

Umgehung

• Kein vom Hersteller veröffentlichter Workaround.
• Discovery-URL und erwarteten Issuer in der Konfiguration fest hinterlegen.
• Sicherstellen, dass Discovery-Anfragen HTTPS mit Zertifikatsprüfung verwenden.
• Die Gültigkeitsdauer des Metadaten-Caches kurz halten.
• Wenn eine eigene Anwendung auf Authlib basiert, bis zu einer bestätigten Korrektur eine Prüfung des Issuers in den Discovery-Metadaten ergänzen.

Ausnutzung

• CISA SSVC: Ausnutzungsstatus 'poc', automatisierbar: ja, technische Auswirkung: total.
• Nicht als aktiv ausgenutzt gelistet; kein Eintrag im CISA-KEV-Katalog gefunden.
• Öffentlicher Proof of Concept: unbestätigt. Der verlinkte Blog-Beitrag ist mit 'exploit' markiert, konnte aber nicht überprüft werden.
• Voraussetzungen gemäss VulDB: Der Angreifer muss die initiale Discovery-Antwort manipulieren oder Cache-Aktualisierungen abfangen können. Dies könnte im Widerspruch zum CVSS-Vektor 9.8 stehen, der keine Rechte und keine Benutzerinteraktion voraussetzt.

Unsere Empfehlung

• Authlib in allen Python-Projekten inventarisieren, einschliesslich transitiver Abhängigkeiten (Lockfiles, SBOM).
• Öffentlich erreichbare Dienste priorisieren, die OIDC-Discovery-Dokumente von externen Identity Providern abrufen.
• Die oben genannten Härtungsmassnahmen für Discovery jetzt anwenden.
• Die Authlib-GitHub-Advisories und NVD auf eine offizielle Korrekturversion überwachen und diese vor dem Upgrade verifizieren.
• Nicht mit CVE-2026-96760 verwechseln, einer separaten JWS-Signaturumgehung, die dieselben Versionen betrifft.

Ö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

• Researcher write-up (uziii2208) uziii2208.github.io
• VulDB vuldb.com
• OpenCVE record app.opencve.io
• Ubuntu security tracker ubuntu.com
• OSV (Debian) osv.dev
• Hol Guard CVE entry hol.org
• Authlib changelog docs.authlib.org
• CERT/CC VU#762428 (CVE-2026-96760) kb.cert.org

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 30.10.2026 21:34.