Zwei Advisories für Nginx Proxy Manager: 2.16.0 betroffen, und es gibt keinen Patch

Der Nginx Proxy Manager ist die Abkürzung, mit der tausende Selbsthoster und kleine Firmenbetriebe TLS, Vhosts und Weiterleitungen ohne nginx-Handwerk hinbekommen. Am 29. September 2026 um 00:31 UTC sind dazu zwei Sicherheitsmeldungen über die GitHub-Advisories veröffentlicht worden, im selben Zug: GHSA-pm9h-p429-j8c5 führt als Schwere kritisch und beschreibt die fehlende Rateneingrenzung an den Token-Endpunkten, GHSA-886j-w36h-wmx2 hoch mit der Direktiven-Injection über advanced_config. Beide nennen als betroffene Stände „through 2.16.0", über die Registry-API nachgeprüft am 29.09. Die Version, die als Fix wirken würde, fehlt. Es gibt nichts, worauf man aktualisieren könnte.

Warum die Kombination nervt

Die kritische Meldung ist ein Problem der Erreichbarkeit: Ein Frontdoor-Proxy, dessen Verwaltungs-API Token-Raten ungegrenzt durchprobieren lässt, ist so gut wie ein offenstehender Verwaltungszugang, sobald ein Angreifer die Konsole im Netz findet. Die Injection-Meldung braucht einen angemeldeten Nutzer, wirkt dann aber tiefer: wer Direktiven in die generierte nginx-Konfiguration schreiben kann, führt Code im Container aus, und die wenigsten Setups geben diesem Container weniger als den Docker-Socket. Zusammen heißt das: ein erratener Zugang reicht für die Maschine, und die Maschine hält private Schlüssel und die Lastverteilung für alles dahinter.

Was bleibt, bis oben ein Release kommt

Erreichbarkeit der Konsole ist der Hebel. Die Verwaltungsseite braucht kein WLAN-Gast, kein VPN-zu-viel und sicher keinen öffentlichen DNS-Namen. Härtet zuerst die Netzseite: interner Adressbereich, eigene VLAN-Strecke oder Zugriff über VPN mit Klarnamen-Rechnung, kein Port-Forward auf die Konsole.
Wer Admin ist, entscheidet über alles. Mit dem Stand ohne Fix ist jeder Account mit Vollzugriff faktisch root im Proxy. Totale Admin-Listen kurz halten, geteilte Logins streichen, API-Tokens nur mit dem nötigen Scope und benannt nach dem Verwendungszweck.
Sichtbarkeit einschalten. Die Login- und Token-Endpunkte protokollieren lassen oder vorgelagert zählen. Ein Brute-Force gegen eine API ohne Rate-Limit ist in den Logs eine schräge Zeilenlawine, früher war sie das nicht.
Änderungsplan für den Tag X. Solange kein Patch draußen ist, sagt der Image-Tag „latest" über diese CVEs nichts aus. Merken, wann das Repo sich bewegt, und für den Fix-Tag ein Update-Fenster eintragen statt im Notfall zu improvisieren.

Bei uns nachgemessen

Unsere Instanz steht auf 2.16.0 und liegt damit mitten in der betroffenen Spanne, Stand des Containers am 29.09. gemessen. Ob die Konsole öffentlich zu erreichen wäre, haben wir von außen geprüft: Die üblichen DNS-Kandidaten auf npm- und proxy-Namen unter unseren Domains laufen alle ins NXDOMAIN, die Konsole hängt an der internen Adresse. Den Fix, den es nicht gibt, können wir nicht spielen, deshalb bleiben die Punkte oben bei uns Betriebsalltag. Wenn ihr eure Instanz prüft, ist die erste Frage dieselbe: Wo ist die Konsole erreichbar, und wer steht auf der Admin-Liste?

Weiterführende Quellen

Fragen?

Können wir auf eine neue Version wechseln?+

Nein. Stand 29.09.2026 ist 2.16.0 die letzte Veröffentlichung im Repo, beide Meldungen nennen die Spanne durch 2.16.0. Ein Update als Antwort auf diese CVEs gibt es schlicht nicht, das Projekt publiziert gerade keine neue Version.

Was ist der Mechanismus der kritischen Meldung?+

Die Endpunkte rund um /api/tokens antworten ohne Rate-Limit. Wer die Konsole erreichen kann, kann Token-Raten durchprobieren, ohne dass die Schnittstelle nach ein paar Fehlversuchen zumacht. Der Gegenwert ist ein gültiges API-Token, mit ihm die ganze Verwaltung.

Und die zweite Meldung?+

Injection von Nginx-Direktiven über die advanced_config-Felder. Ein angemeldeter Nutzer mit Zugriff auf Proxy-Hosts bringt dort Direktiven unter, die der Renderer ungeprüft übernimmt. Auf dem Standard-Images heißt das: Codeausführung im Container, mit dem Docker-Socket daneben typischerweise mehr.