OAuth2 Proxy: Kritische Umgehung der Authentifizierung über X-Forwarded-Uri

Kurzfassung

Eine als kritisch eingestufte Schwachstelle in OAuth2 Proxy kann dazu führen, dass sich Authentifizierung für bestimmte Anfragen umgehen lässt. Auslöser ist ein manipuliert übergebener Header, den die Software in einer typischen Reverse-Proxy-Konfiguration als vertrauenswürdig behandelt.

Für Betreiber im DACH-Raum ist das vor allem dann relevant, wenn OAuth2 Proxy vor internen Webanwendungen, Admin-Oberflächen oder APIs hängt und der Reverse-Proxy-Modus ohne sauber gesetzte Trusted-Proxy-IP-Listen läuft. Dann kann ein externer Angreifer unter Umständen an geschützte Inhalte gelangen, obwohl die Anwendung eigentlich Login erzwingen soll.

Was ist passiert?

OAuth2 Proxy prüft bei bestimmten Pfaden, ob eine Anfrage ohne Anmeldung durchgelassen werden darf. Dabei verlässt sich die Komponente auf den Wert eines Header-Felds namens X-Forwarded-Uri, wenn sie den Absender als vertrauenswürdig einstuft. Genau hier liegt das Problem.

In der Standardkonfiguration für Reverse Proxy ist die Schutzlogik offenbar wirkungslos, weil jede eingehende Adresse faktisch als vertrauenswürdig behandelt werden kann, solange keine expliziten Trusted-Proxy-Adressen gesetzt sind. Der Folgefehler: Die Prüfung läuft gegen einen vom Angreifer gesetzten Wert, während die eigentliche Anfrage an die Zielanwendung unverändert weitergereicht wird.

Technische Details

Die Schwachstelle trägt die Kennung CVE-2026-76835 und ist mit Critical bewertet. Laut Beschreibung nutzt die Funktion zur Ermittlung der Request-URI bevorzugt den Header X-Forwarded-Uri, sofern die Logik für weitergereichte Header greift. Danach vergleicht die Allowlist-Funktion diesen manipulierten Pfad mit den Regeln für skip_auth_routes und skip_auth_regex.

Die Vertrauensentscheidung hängt davon ab, ob die Quelladresse als Teil eines Trusted-Proxy-Sets gilt. Fehlt eine sauber konfigurierte Liste vertrauenswürdiger Proxy-IP-Adressen, fällt die Software in Standardwerte zurück, die faktisch alle Adressen einschließen. Damit wird aus einem Schutzmechanismus ein Einfallstor.

Angreifer können dann eine Anfrage auf einen eigentlich geschützten Pfad senden und im Header einen erlaubten Pfad vortäuschen. Die Authentifizierungsprüfung sieht den harmlosen Scheinpfad, das Backend bekommt aber den echten, geschützten Aufruf. Genau das macht den Fehler so heikel.

Wer ist betroffen?

Betroffen sind Betreiber von OAuth2 Proxy, die den Reverse-Proxy-Modus nutzen und keine expliziten trusted_proxy_ip-Werte gesetzt haben. Aus der Quellenlage geht hervor, dass in dieser Konstellation die Default-Vertrauensliste zu weit gefasst ist. Wer die Komponente vor internen Anwendungen, Dashboards, Self-Service-Portalen oder Verwaltungsoberflächen einsetzt, sollte sofort prüfen.

Für Endnutzer ist die Lage anders: Die Schwachstelle trifft sie nur indirekt, wenn sie gegen Dienste arbeiten, die hinter OAuth2 Proxy abgesichert sind. Im Fokus stehen also klar Serverbetreiber, nicht private Heimnutzer.

Empfohlene Maßnahmen

Wer OAuth2 Proxy betreibt, sollte zuerst die Konfiguration prüfen. Wichtig ist, dass im Reverse-Proxy-Betrieb eine enge Liste vertrauenswürdiger Proxy-Adressen gesetzt ist. Ohne diese Härtung sollte man nicht davon ausgehen, dass die Standardwerte sicher sind.

Danach gehört die Allowlist für skip_auth_routes und skip_auth_regex auf den Prüfstand. Jede Regel, die einen Login-Bypass erlaubt, sollte so knapp wie möglich gefasst sein. Wenn die Funktionalität nicht zwingend gebraucht wird, besser abschalten.

Admins sollten außerdem Logs auf ungewöhnliche Header-Werte und Zugriffe auf geschützte Pfade prüfen. Wer verdächtige Muster sieht, muss davon ausgehen, dass bereits jemand getestet hat, ob die Umgehung greift. Ein Patch oder eine Herstellerkorrektur sollte zeitnah eingespielt werden, sobald verfügbar.

Einschätzung von CyberSecurity-News.de

Der Fehler ist ernst. Nicht wegen eines spektakulären Exploits, sondern weil ein Kernmechanismus der Absicherung in einer verbreiteten Proxy-Architektur auf falsche Vertrauensannahmen baut. Das ist genau die Art Schwachstelle, die in der Praxis schnell unterschätzt wird.

Die Informationslage ist aber noch dünn. Ob alle Versionen betroffen sind, nennt die Quelle nicht, und auch ein konkreter Fix-Stand fehlt in den vorliegenden Angaben. Wer die Software produktiv einsetzt, sollte deshalb nicht auf weitere Detailmeldungen warten, sondern die eigene Konfiguration jetzt absichern.

Kritisch sehen wir auch die Rolle der Standardkonfiguration. Wenn ein Sicherheitsprodukt ohne explizite Zusatzkonfiguration praktisch jedem Client vertraut, ist das kein Randproblem, sondern ein Designfehler mit Ansage.

Fazit

CVE-2026-76835 kann in OAuth2 Proxy dazu führen, dass geschützte Pfade ohne Anmeldung erreichbar werden. Der Angriff braucht keine Anmeldung und keine komplizierte Ausnutzung lokaler Rechte, sondern nur einen manipulierten Header und eine zu lockere Proxy-Konfiguration.

Für Unternehmen mit OAuth2-gestützten Webzugängen ist das priorisiert zu prüfen. Wer den Reverse-Proxy-Modus nutzt, sollte die Trusted-Proxy-Konfiguration sofort härten und die eigenen Skip-Auth-Regeln auf das Nötigste reduzieren.