--- title: "NGINX-Schwachstellen: Ursachen, Korrekturen und Produktionsüberprüfung" description: "Überprüfen Sie fünf NGINX-Schwachstellen vom Oktober 2026, ihre Konfigurationsvoraussetzungen, branchenspezifische Korrekturen, Verteilungs-Backports und Produktionsüberprüfung." language: "de" url: "https://keendigit.com/de/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # NGINX-Schwachstellen: Ursachen, Korrekturen und Produktionsüberprüfung Überprüfen Sie fünf NGINX-Schwachstellen vom Oktober 2026, ihre Konfigurationsvoraussetzungen, branchenspezifische Korrekturen, Verteilungs-Backports und Produktionsüberprüfung. Historisches Artikeldatum: 2026-10-14 (Offenlegungs- und Sicherheitsveröffentlichungsdatum). Quellen überprüft und Informationen ergänzt durch 2026-10-27. Dieser Artikel ist nach Veranstaltungsdatum archiviert; Nach dem 14. Oktober veröffentlichte Versions- und Release-Updates sind unten aufgeführt. Zielgruppe: NGINX Open Source / NGINX Plus Website- und Reverse-Proxy-Betriebs- und Wartungspersonal, Sicherheitspersonal, Distributionsbetreuer sowie Ingenieure, die NGINX selbst kompilieren und Module von Drittanbietern warten. Dieser Artikel konzentriert sich auf die fünf NGINX-Kernschwachstellen, die am 14. Oktober 2026 offengelegt und intensiv behoben wurden, und wirft auch einen Rückblick auf die repräsentativen Schwachstellen in den Bereichen Speichersicherheit und Anforderungsintegrität von Mai bis September 2026. Der Inhalt umfasst Auslösebedingungen, Ursachen auf Codeebene, Auswirkungsumfang, Behebungsworkflow, kurzfristige Abhilfemaßnahmen, offizielle Patch-Implementierung, Backports zu älteren Zweigen und Produktionsüberprüfung. Referenzen wie [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1) verweisen auf den Quellanhang. Beispielkonfigurationen werden nur zur Veranschaulichung der Bereitstellungs- und Prüfideen verwendet und sollten vor der Implementierung anhand der tatsächlichen Version, der Konfigurationsvererbung, der Abhängigkeiten und der Geschäftskapazität überprüft werden. ## TL;DR: Vorrangige Aktionen 1. Priorisieren Sie Sicherheitsupgrades. Aktualisieren Sie für nginx.org Open Source-Pakete den Zweig Stable 1.30 auf mindestens 1.30.6 und den Zweig Mainline 1.31 auf mindestens 1.31.7.. Zum Überprüfungsdatum ist 1.31.8 die neueste Version von Mainline. Dabei handelt es sich um separate Branch-Baselines. Vergleichen Sie ihre Zahlen nicht branchenübergreifend. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/nginx-remediation-guide#source-2) 2. Überprüfen Sie die Verteilungsinstallationen anhand der Vollpaketversion. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 verfügen über Hersteller-Backports; Debian 13 (trixie) erfordert mindestens `1.26.3-3+deb13u10`. Bei der Überprüfung ist das Paket Debian 12 (bookworm) `1.22.1-9+deb12u10` immer noch als betroffen gekennzeichnet. Überprüfen Sie jeden CVE; Aus der Empfehlung Debian 13 geht nicht hervor, dass Debian 12 behoben ist. [S13](https://keendigit.com/de/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/de/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/de/insights/nginx-remediation-guide#source-15) 3. Prüfen Sie fünf Konfigurationskombinationen: `alias + rewrite + $request_filename`, `map` + Regex + Variablenauswertung, `aio + ssi + include virtual`, HTTP/3 mit `proxy_request_buffering on` und `ssl_session_cache shared:...` mit automatischer Schlüsselrotation des Sitzungstickets TLS. Das Vorhandensein einer Richtlinie allein begründet noch keine Ausnutzbarkeit; Bewerten Sie den Anforderungspfad und den Konfigurationsumfang. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) 4. Ersetzen Sie alle alten Prozesse und Container. Führen Sie `nginx -t` aus und starten Sie dann den Dienst neu oder führen Sie eine fortlaufende Hochverfügbarkeitsbereitstellung durch. Bestätigen Sie, dass die alten Prozesse master/worker beendet wurden. `nginx -s reload` allein beweist nicht, dass sich die laufende Binärdatei geändert hat. 5. Überprüfen Sie die tatsächlichen Endpunkte: HTTP/1.1, HTTP/2, HTTP/3 (falls aktiviert), Proxy-Uploads und API-Anforderungstexte, mTLS-Zertifikatauthentifizierung, SSI-Seiten und Zugriffsprotokolle. Zeichnen Sie Paketherkunft, Version, Image-Digest, laufende Prozesse und Ergebnisse für jeden Endpunkt auf. 6. Wenn ein sofortiges Upgrade nicht möglich ist, entfernen Sie die entsprechenden Auslöserbedingungen: Deaktivieren Sie unnötige SSI/AIO oder HTTP/3, überprüfen Sie anfällige `alias`/`rewrite`/`map`-Variablenreferenzen und bewerten Sie temporäre `ssl_session_tickets off;` für betroffene mTLS-Dienste. WAF, ASLR, Ratenbegrenzungen und Konfigurationsänderungen decken nur einige Bedingungen ab und können offizielle Patches nicht ersetzen. [S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/de/insights/nginx-remediation-guide#source-12) ## 1. Schwachstellenübersicht und Risikobeurteilung NGINX hat am 14. Oktober 2026 1.30.6 (Stable) und 1.31.7 (Mainline) veröffentlicht und damit fünf Sicherheitsprobleme behoben. Drei beinhalten Heap-Überläufe oder Use-After-Free und erhielten F5 CVSS v4.0-Werte von 9.2 / Kritisch. Die anderen beiden wirken sich auf die Integrität der HTTP/3-Anforderung und die Authentifizierung des TLS-Clientzertifikats aus. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3) Unterscheiden Sie die Bewertungssysteme: nginx.org listet alle fünf Probleme als `medium` auf, während F5 CVSS v4.0 und einige nationale Sicherheitsbehörden die drei Speicherprobleme als kritisch einstufen. Dies bedeutet nicht, dass alle fünf eine bedingungslose Remotecodeausführung ermöglichen. Konfiguration, Erreichbarkeit des Datenverkehrs und Bedingungen, die außerhalb der Kontrolle eines Angreifers liegen, sind von Bedeutung. Speicherbeschädigung und zuverlässiges RCE sind unterschiedliche Beweisniveaus. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) | CVE | Technische Probleme und typische Auslösebedingungen | Kernwirkung | Bewertung und Entsorgung | | -------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | CVE-2026-15176 | `alias` Pfadzuordnung + `rewrite` Änderung URI + Auswertung `$request_filename` | Heap-Pufferüberlauf, Worker-Absturz; Potenzial RCE unter bestimmten Bedingungen | F5 CVSS v4.0 9.2; Priorisieren Sie die Fehlerbehebung | | CVE-2026-93479 | HTTP/Stream-Skriptauswertung, insbesondere `map`-Regex-Erfassung und root-Verzeichnis, Protokollvariablen-Querverweis | Der reservierte Puffer wird überschrieben und der Heap läuft über; potenzielles RCE unter bestimmten Bedingungen | F5 CVSS v4.0 9.2; Es besteht ein Rückbildungsrisiko nach vorangegangenen Reparaturen | | CVE-2026-97205 | SSI virtuelle Includes und AIO/asynchroner Betrieb; Überlauf der Anzahl der ausstehenden Vorgänge | Use-After-Free, Worker-Absturz, Speicherbeschädigung; Potenzial RCE | F5 CVSS v4.0 9.2; erfordert eine nicht standardmäßige Konfiguration | | CVE-2026-95101 | HTTP/3 Unbekannter Frame ist über Puffer fragmentiert, die Pufferung des Proxy-Anforderungstexts ist aktiviert | Falsches Einfügen von Nicht-DATA-Bytes in den Upstream-Anforderungstext, möglicherweise unter Umgehung der Größenbeschränkung des Anforderungstexts | Diese Sicherheitslücke beeinträchtigt die Anforderungsintegrität. Es bietet selbst keine Remote-Codeausführung (RCE). | | CVE-2026-97629 | Gemeinsamer TLS-Sitzungscache, automatische Schlüsselrotation und Worker-Schlüsselspiegelung | Fälschung von Sitzungstickets; Für den betroffenen mTLS-Dienst kann es zu einer Umgehung der Clientzertifikatauthentifizierung kommen | Besonderes Augenmerk muss auf die geschäftlichen Auswirkungen des Zertifikatauthentifizierungstyps API gelegt werden | Der obige CVSS-Score wird durch F5 unter Verwendung von v4.0 ermittelt; Die gleiche Schwachstelle kann in den eigenen Schweregraden und Verteilungsschweregraden von CVSS, 3.1 und nginx.org einen unterschiedlichen Schweregrad aufweisen. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) ### 1.1 Priorisieren Sie die Bereitstellungspräsenz gegenüber CVE-Scores allein | Bereitstellungsformular | Wichtige Untersuchungspunkte | Empfehlungen zur vorrangigen Entsorgung | | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Reverse-Proxy für öffentliche Netzwerke, einschließlich angepasster `rewrite`, `alias` und komplexer `map` | CVE-2026-15176, CVE-2026-93479 und Rewrite/Mapping-Schwachstellen von Mai bis Juli | P0: Sofort prüfen und aktualisieren | | API / Verwaltungsebene, die das Client-Zertifikat als einzige oder Haupteingangsauthentifizierung verwendet | Sitzungsticket und gemeinsame Cache-Konfiguration von CVE-2026-97629 | P0: Bestätigen Sie sofort die Authentifizierungsgrenze und aktualisieren Sie sie | | Stellen Sie einen externen HTTP/3-Upload, eine Statusänderungsschnittstelle und die Transaktionsklasse API bereit | CVE-2026-95101, insbesondere der Anforderungstext, wird per Proxy an das Backend weitergeleitet | P0/P1: Nach geschäftlicher Bedeutung ordnen | | SSI Dynamische Seite oder asynchrone Datei-E/A | CVE-2026-97205 | P1: Bestätigen Sie die Kombinationsbedingungen und reparieren Sie so schnell wie möglich | | Nur statische Seiten + einfacher Reverse-Proxy HTTP/1.1/2 | Konfiguration und Version müssen noch geprüft werden, einige CVE-Bedingungen fehlen jedoch möglicherweise | P1: Im Notfall-Sicherheits-Upgrade-Fenster enthalten | | Verwenden Sie die ausgemusterte Kubernetes-Community ingress-nginx | Das Projekt stoppt die Sicherheitswartung und die Risiken sind nicht auf diese fünf CVEs beschränkt | Erstellen Sie einen individuellen Controller-Migrationsplan | P0/P1 sind die in diesem Artikel gegebenen Betriebs- und Wartungsempfehlungen für die Exposition gegenüber öffentlichen Netzwerken und die Zertifizierungsempfindlichkeit. Es handelt sich nicht um eine offizielle CVSS-Klassifizierung, noch sollte sie die unternehmensinterne Vermögens- und Änderungsrisikobewertung ersetzen. ### 1.2 Auswirkungsgrenze und Angriffsberechtigungen Die Hauptschwachstellen in diesem Stapel liegen hauptsächlich in der Datenebene NGINX: Der Angriffseintrittspunkt ist die Clientverbindung und -anforderung, und die eigentliche Auswirkung tritt normalerweise im Worker-Prozess auf. Wenn die ausnutzbaren Bedingungen für eine Speicherbeschädigung erfüllt sind, wird die Codeausführungsberechtigung im Allgemeinen durch den laufenden Benutzer, Containereinschränkungen, Linux-Fähigkeit, Bereitstellungs- und Netzwerkberechtigungen des Worker eingeschränkt; Ein mögliches RCE bedeutet nicht automatisch root-Berechtigungen oder eine Host-Kompromittierung. [S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) Aber selbst wenn der Prozess nicht privilegiert ist, hat er möglicherweise dennoch Zugriff auf Proxy-Anmeldeinformationen, lesbare Dateien mit privaten Schlüsseln des Zertifikats, Upstream-Service-Tokens, temporäre Dateien, internes API und erreichbare Netzwerke. Für mTLS kann die Umgehung der Authentifizierung selbst schwerwiegende geschäftliche Folgen haben und muss nicht unbedingt mit der Codeausführung einhergehen. ## 2. Ursachenanalyse ### 2.1 Verstehen Sie die drei fehleranfälligen Grenzen in NGINX Ein NGINX worker ist ein langlebiger, ereignisgesteuerter Prozess, der den Anforderungsstatus, asynchrone Vorgänge und Protokollparser verwaltet. Diese Schwachstelle beinhaltet Einschränkungen auf drei technischen Ebenen: 1. Variablenauswertung und Speichergröße müssen konsistent sein: `rewrite` Nach Änderung der Anforderung URI muss die Pfadzuordnung mit der aktuell gültigen `location` konsistent sein; Wenn der Skriptinterpreter die Variablenlänge berechnet, muss der Schreibraum die tatsächlichen Ausgabe- und reservierten Bereiche abdecken. 2. Asynchrone Vorgänge müssen den Lebenszyklus des angeforderten Speichers verlängern: Wenn das Lesen und Schreiben von Dateien, das Warten auf den Cache oder Thread-Aufgaben noch nicht abgeschlossen sind, kann der entsprechende Anforderungsspeicherpool nicht im Voraus freigegeben werden. 3. Protokollstatus und Sicherheitsstatus können nicht gemischt oder weggelassen werden: HTTP/3 Die Länge des unbekannten Frame-Überspringens kann nicht als DATA-Anforderungskörperlänge betrachtet werden. TLS Alle Schlüsselslots, die an der Signaturüberprüfung teilnehmen, müssen während der Sitzungsticketrotation korrekt initialisiert und synchronisiert werden. Der folgende Inhalt basiert auf dem Upstream-Fix-Commit NGINX und der Herstellerankündigung, um den Fehlermechanismus zu erläutern, der ausgelöst werden kann; Das Beispielfragment dient der Analyse und stellt nicht den vollständigen Code dar, der direkt zum Reparieren der Produktionsumgebung verwendet werden kann. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/de/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/de/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: Die Pfadzuordnung zwischen `alias` und dem neu geschriebenen URI ist ungültig. In NGINX bestimmen der übereinstimmende `location` und sein `alias` den Dateipfad. `rewrite` kann die aktuelle Anfrage URI ändern. Nach dem Umschreiben gelten die Annahmen der ursprünglichen `location`-Zuordnung möglicherweise nicht mehr. Der betroffene Verarbeitungspfad hat bei der Überprüfung des `alias`-Status in `ngx_http_map_uri_to_path()` nicht ausreichend geprüft, ob die Anforderung neu geschrieben wurde. Wenn die Konfiguration nach dem Neuschreiben weiterhin `$request_filename` auswertet, wird der Pfad möglicherweise mit Annahmen erstellt, die nicht dem aktuellen URI-Status entsprechen, was schließlich einen Schreibvorgang außerhalb der Grenzen des Heap-Speichers auslöst. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5) Typische Kombination (wird nur als Gegenbeispiel für die Konfigurationsprüfung verwendet, die Bereitstellung wird nicht empfohlen): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` Die Gefahr ist nicht auf `return` beschränkt: `set`, `if`, `add_header`, `log_format` usw. müssen auch geprüft werden, wenn die `$request_filename`-Auswertung im selben Anforderungsprozess ausgelöst wird. `return` im Beispiel macht diesen Statuspfad nur leicht erkennbar, er kann nicht verwendet werden, um zu schließen, dass alle Produktionskonfigurationen Überläufe erzeugen. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/de/insights/nginx-remediation-guide#source-10) Folgen des Angriffs: Das Erstellen einer Anfrage kann zu einem Neustart von Worker oder einer Dienstunterbrechung führen. Unter Bedingungen wie ASLR, das geschlossen ist oder umgangen werden kann, besteht ein potenzielles RCE. Der Kern des Upstream-Patches besteht darin, die Fertigstellung der neu geschriebenen URI-Pfadzuordnung im nicht mehr gültigen `alias`-Kontext zu verweigern, anstatt einfach einen bestimmten Puffer zu erweitern. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/de/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: Nichtübereinstimmung zwischen „reserviertem Speicherplatz“ und tatsächlicher Variablenlänge bei der Skriptauswertung Die HTTP- und Stream-Module von NGINX verfügen über Skriptauswertungen, die Literalzeichenfolgen und Variablenwerte in der Ergebniszeichenfolge verketten. Zu den Anwendungsbeispielen gehören HTTP-Dokument-root-Pfade, Zugriffsprotokollpfade und Variablenausdrücke in Stream. Bestimmte Konfigurationen von `map` + regulären Ausdrücken ermöglichen das Lesen erfasster Werte durch andere Ausdrücke, bevor die Ergebnisvariable `map` ausgewertet wird. In Kombination mit der Skriptausführungsmethode mit reservierter Länge zählt die alte Implementierung den reservierten Speicherplatz `len` im Voraus in den Akkumulator der ausgewerteten Länge, sodass nachfolgende Schreibzeigerberechnungen nicht mehr mit der Puffergrenze konsistent sind. In einer bestimmten Variablenauswertungssequenz können nachfolgende Zeichenfolgenschreibvorgänge den reservierten Bereich überschreiben und einen Heap-Überlauf verursachen. [S6](https://keendigit.com/de/insights/nginx-remediation-guide#source-6) | partizipative Elemente | Warum es sich lohnt, darauf zu achten | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Regex in `map` | Die Auswertung der Erfassungsvariablen kann einen unabhängigen Lebenszyklus und ein unabhängiges Caching-Verhalten aufweisen | | Anonyme Erfassungen wie `$1`, `$2` usw. | Wird leicht durch andere reguläre Ausdrücke oder Ausdrücke überschrieben, was die Nachverfolgung des Besitzes erschwert | | Variablen in `root` | Skriptausführung und Pufferreservierung beim Auslösen der Pfaderstellung | | `log_format`/Dynamischer Protokollpfad | Die gleiche Art der Bewertung kann später in der Anfrage ausgelöst werden | | Skriptausdrücke in `stream` | Der Upstream-Fix ändert auch `ngx_stream_script_run()`. Sie können nicht nur das HTTP-Modul überprüfen. | Wichtige Regressionsbeziehung: Der Code im Zusammenhang mit dieser Sicherheitslücke steht im Zusammenhang mit den vorherigen Änderungen, mit denen CVE-2026-42533 behoben wurde. Im offiziellen DSA für Debian 13 heißt es eindeutig, dass der betroffene Code über einen früheren Sicherheits-Backport in das trixie-Paket eingeführt wurde. Daher bedeutet „`map`-Schwachstellenpatch vom Juli wurde installiert“ nicht, dass der CVE-2026-93479-Schwachstellenpatch vom Oktober abgedeckt wurde; Die gesamte Sicherheits-Fix-Kette sollte überprüft werden. [S6](https://keendigit.com/de/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/de/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/de/insights/nginx-remediation-guide#source-17) Das potenzielle Risiko von RCE hängt hier mit der Speicherschutzumgebung zusammen, und es sollte nicht behauptet werden, dass der reguläre Ausdruck `map` allein von anonymen Angreifern ausgenutzt werden kann. [S11](https://keendigit.com/de/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO Unvollendeter Vorgangszähler-Wraparound verursacht Use-After-Free Diese Sicherheitslücke besteht nicht einfach darin, „SSI einzuschalten, und Sie erhalten UAF“. Der Schlüssel liegt im Referenzzähler für asynchrone Vorgänge, der von der Hauptanforderung gehalten wird. NGINX Verwenden Sie `r->main->blocked`, um die asynchrone Verarbeitung zu verfolgen, die noch nicht abgeschlossen ist. In der alten Implementierung war dies eine 8-Bit-Zählung. Einige Pfade führten vor dem Erhöhen der Anzahl keine Überprüfung der Obergrenze durch. Wenn die gleiche Hauptanforderung 256 ausstehende Vorgänge akkumuliert, kann der Zählerstand von 255 auf 0 steigen. Nachfolgende Prozesse gehen fälschlicherweise davon aus, dass es keinen asynchronen Vorgang gibt, der die Freigabe der Anforderung verhindert, wodurch der Anforderungsspeicherpool freigegeben wird, auf den die Aufgabe noch verweist. [S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7) Der Fehlerprozess kann unterteilt werden in: 1. Wenn der zugehörige asynchrone E/A-/Thread-Pfad aktiviert ist, führt die Seite SSI mehrere Unteranforderungen oder Lesevorgänge über `include virtual` ein. 2. Die ausstehenden Vorgänge einer bestimmten Hauptanforderung werden bis zur durch das Zählfeld dargestellten Obergrenze aufsummiert. 3. Die 8-Bit-Zählung läuft umher und wird fälschlicherweise als „keine ausstehenden Vorgänge“ ausgedrückt. 4. Der Anforderungsspeicherpool wird freigegeben, während Dateilesevorgänge, Cache-Wartevorgänge oder Rückrufe von Thread-Aufgaben weiterhin Verweise darauf behalten. 5. Nachfolgende asynchrone Abschlussrückrufe greifen auf den freigegebenen Speicher zu, was zu Abstürzen von UAF, Worker oder einer möglichen Speicherbeschädigung führt. Der offizielle Fix fügt `NGX_HTTP_MAX_BLOCKED 250` zur Anforderungsheaderdatei hinzu und fügt Einschränkungen für den Ausgabefilter, den Cache-Lesevorgang und den Upstream-Thread-Pfad hinzu; Wenn der Schwellenwert erreicht ist, werden Vorgänge mit synchronisierten Pfaden synchron abgeschlossen. Wenn sie nicht sicher verarbeitet werden können, wird das weitere Hinzufügen ausstehender Aufgaben abgelehnt. [S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7) Beurteilung der Anwendbarkeit: Es muss bewertet werden, ob SSI, AIO, virtuelle Inklusion, Unteranforderungen und verwandte asynchrone Vorgänge in derselben Anforderungskette kombiniert auftreten können. Dies sind normalerweise nicht die standardmäßigen einfachen statischen Proxy-Konfigurationen. `aio off;` oder `ssi off;` können bestimmte Triggerelemente entfernen, Geschäftsfunktionsabhängigkeiten sollten jedoch zuerst bestätigt werden. [S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/de/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: Der unbekannte Frame HTTP/3 ist mit dem Status des Anfragetexts DATA verwechselt Der HTTP/3-Frame-Parser muss zwischen `DATA`-Frames (die an die Verarbeitung des HTTP-Anforderungstexts übergeben werden müssen) und unbekannten Frames, die übersprungen werden sollten, unterscheiden. Auch die Länge unbekannter Frames muss bei der Fragmentierung über Netzwerkpuffer genau erhalten bleiben. Die alte Implementierung von `ngx_http_v3_parse_data()` verwendete das Feld `st->length`, um die „verbleibende Anzahl zu überspringender Bytes“ beim Überspringen unbekannter Frames zu speichern, während der Anforderungstextfilter dasselbe Feld als „verbleibende DATA-Nutzlastlänge“ interpretierte. Wenn sich der unbekannte Frame zufällig über mehrere Parse-Aufrufe erstreckt, kann der nächste Byte-Batch nach der Unterbrechung des Parsings fälschlicherweise als Teil des Anforderungstexts verwechselt werden. [S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8) Es entstehen zwei Arten von Risiken: - Anforderungskörperinjektion: Die vom Client übermittelte Nicht-DATA-Frame-Nutzlast kann an die Upstream-Anwendung übertragen werden, wodurch sich die tatsächlich vom Backend empfangenen Daten ändern. - Größenbeschränkung umgeht: `client_max_body_size` und andere Einschränkungen. Die erwarteten Prüfungen konzentrieren sich auf den Pfad DATA, und falsch konvertierte Inhalte können die entsprechende Überprüfung umgehen. Das vom Beamten beschriebene typische Auslöseszenario besteht darin, dass `ngx_http_v3_module` die Anfrage HTTP/3 empfängt und `proxy_request_buffering on` weiterleitet. Die Pufferung des Proxy-Anfragetexts ist in `ngx_http_proxy_module` standardmäßig aktiviert. Daher sollte zuerst der Reverse-Proxy überprüft werden, der HTTP/3 aktiviert. Es ist nicht angemessen anzunehmen, dass es keine Auslösebedingung gibt, nur weil `proxy_request_buffering on;` nicht explizit geschrieben wird. [S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/de/insights/nginx-remediation-guide#source-18) Die direkte Folge dieser Sicherheitsanfälligkeit ist die Änderung der Back-End-Anforderungsintegrität und der Sicherheitsgrenzen. Dies ist nicht der äquivalente Ausdruck von RCE, der direkt im NGINX-Kern vervollständigt wird. Die letztendlichen geschäftlichen Auswirkungen hängen davon ab, wie diese Bytes im Upstream analysiert und als vertrauenswürdig eingestuft werden. [S24](https://keendigit.com/de/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS Bei der Ticketrotation fehlt der dritte Schlüsselschlitz In betroffenen Konfigurationen kann NGINX automatisch TLS-Sitzungsticketschlüssel über den gemeinsamen Speichercache generieren und rotieren, sodass mehrere Worker denselben Ticketstapel verarbeiten können. Die entsprechende Synchronisationslogik weist jedem Worker drei Schlüsselslots zu, und der Entschlüsselungsrückruf durchläuft diese Slots ebenfalls. Die alte Implementierung kopiert jedoch jedes Mal nur zwei Schlüsselsteckplätze aus dem gemeinsam genutzten Speicher, was zum Schlüsselnamen, HMAC-Schlüssel und AES des dritten Steckplatzes führt. Der Schlüssel bleibt möglicherweise nicht initialisiert. Wenn die Schlüsselkennung eines Tickets mit diesem Status übereinstimmt, kann nicht initialisiertes Schlüsselmaterial zur Signaturüberprüfung und -entschlüsselung verwendet werden und so einen Pfad zur Fälschung der TLS-Sitzung bilden. [S9](https://keendigit.com/de/insights/nginx-remediation-guide#source-9) Einsatzkombinationen mit hohem Risiko sind typischerweise: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` Die schwerwiegendste geschäftliche Konsequenz dieser Sicherheitslücke besteht darin, dass bei Diensten, die die Client-Zertifikatauthentifizierung (mTLS) in `ssl_verify_client on;` und auf andere Weise verwenden, gefälschte Wiederherstellungssitzungen möglicherweise die Überprüfung des Client-Zertifikats umgehen. Auch der Erfolg des Angriffs unterliegt unkontrollierbaren Bedingungen; Eine Site, die nur ein normales serverseitiges HTTPS-Zertifikat und keine Client-Zertifikatauthentifizierung verwendet, sollte nicht fälschlicherweise als „der Angreifer kann die gesamte Website-Anmeldung umgehen“ bezeichnet werden. [S9](https://keendigit.com/de/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/de/insights/nginx-remediation-guide#source-12) Hierbei handelt es sich um ein Problem mit dem Status der TLS-Sitzungsauthentifizierung und hat nichts damit zu tun, ob der private Schlüssel TLS des Servers geknackt ist oder ob das öffentliche CA-Zertifikat root betroffen ist. [S24](https://keendigit.com/de/insights/nginx-remediation-guide#source-24) ### 2.7 Erläuterungen zu DoS, RCE, Authentifizierungsumgehung und bekannten Exploits - DoS: Ein Speicherfehler führt dazu, dass Worker abstürzt oder massiv neu startet. Ob es zu einer allgemeinen Nichtverfügbarkeit kommt, hängt vom Verkehrsdruck, der Fähigkeit zum Prozessneustart, der Verbindungswartungszeit und der Hochverfügbarkeitsarchitektur ab. - potenziell RCE: Einige Ankündigungen deuten darauf hin, dass die Möglichkeit einer Codeausführung besteht, wenn ASLR geschlossen oder umgangen wird. Dies bedeutet nicht, dass eine öffentliche Angriffskette offengelegt wurde, die Befehle stabil und universell ausführen kann. [S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) - Anforderungsinjektion/Authentifizierungsumgehung: Es kann den geschützten Geschäftsstatus oder Anforderungsinhalt direkt ändern und kann nicht ignoriert werden, nur weil es die Shell nicht direkt abruft. - hat Angriffsversuche entdeckt: CVE-2026-42945 im Mai 2026 hat Berichte über In-the-Wild-Ausbeutungsaktivitäten; Diese historische Tatsache sollte nicht direkt darauf schließen lassen, dass alle fünf CVEs im Oktober erfolgreich in großem Maßstab genutzt wurden. [S23](https://keendigit.com/de/insights/nginx-remediation-guide#source-23) ## 3. Reparaturversion und Patchauswahl ### 3.1 NGINX Open Source offizielle Patch-Basislinie | vorgelagerter Zweig | Die erste offizielle Version, die fünf Schwachstellen abdeckt, erschien im Oktober | Empfehlungen ab 2026-10-27 | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | Installieren Sie mindestens 1.30.6 und führen Sie nachfolgende Sicherheitsversionen durch. | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | Der frühere NGINX Open Source-Zweig | Es kann nicht allein aufgrund der Tatsache beurteilt werden, dass „alte Schwachstellen-Patches angewendet wurden“. | Migrieren Sie zuerst zum verwalteten Zweig. andernfalls ist der Verkäufer verpflichtet, einen formellen Nachweis der Unterstützung auf CVE-by-CVE-Basis vorzulegen. | Dies sind die Versionsschlussfolgerungen des nginx.org-Upstream-Quellcodes/offiziellen Zweigs und sollten nicht dazu verwendet werden, das Sicherheitspaket direkt mit vom Distributionsanbieter bereitgestellten Backport-Fixes zu verweigern. Selbst wenn der Wert von `1.31.6` größer als `1.30.6` ist, ist er immer noch niedriger als die Patch-Basislinie des Hauptzweigs. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/nginx-remediation-guide#source-2) ### 3.2 Der Upstream-Auswirkungsbereich von fünf CVEs Die folgenden Bereiche sind gemäß dem Originaltext des Sicherheitsbulletins nginx.org aufgeführt und müssen in Verbindung mit dem „aktuell ausgeführten Zweig“ und dem „tatsächlichen Konfigurationspfad“ verstanden werden: | CVE | Von Upstream-Tags betroffene Versionen | Offiziell gekennzeichnete feste Version | | -------------- | -------------------------------------- | ---------------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` oder `1.31.7+` in ihren jeweiligen Zweigen | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | Das Gleiche wie oben | | CVE-2026-97205 | `0.8.11–1.31.6` | Das Gleiche wie oben | | CVE-2026-95101 | `1.25.0–1.31.6` | Das Gleiche wie oben | | CVE-2026-97629 | `1.23.2–1.31.6` | Das Gleiche wie oben | Für CVE-2026-93479 gelten bestimmte Einschränkungen für die Einführungsversion. Nicht jede alte NGINX-Version ist von dieser Regression betroffen. Ältere Versionen außerhalb dieser Bereiche sind möglicherweise immer noch von der früheren `map`-Regex-Schwachstelle CVE-2026-42533 betroffen. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: Verteilungs-Backports (USN-8955-1) Canonical USN-8955-1 vom 26. Oktober 2026 stellt ein Sicherheitsupdate für vier Ubuntu-Builds bereit: [S13](https://keendigit.com/de/insights/nginx-remediation-guide#source-13) | Ubuntu-Version | `nginx` und die gleiche feste Version des Quellpakets | Beschreibung | | -------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | Es handelt sich um einen Anbieter-Backport. Die Upstream-Versionsnummer zeigt immer noch 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | Das Gleiche wie oben | | 26.04 LTS | `1.28.3-2ubuntu1.12` | Das Gleiche wie oben | | 26.10 | `1.30.4-7ubuntu1.1` | Das Gleiche wie oben | Die Ankündigung enthält entsprechende feste Versionen homologer Pakete wie `nginx-core`, `nginx-extras`, `nginx-full` und `nginx-light`. Ziehen Sie keine Schlussfolgerungen darüber, ob das Problem behoben werden muss, aus dem Upstream-Teil, der nur durch `nginx -v` angezeigt wird. wie Ubuntu 24.04 und `1.24.0-2ubuntu7.19` wurden von diesem Anbieter gepatcht, aber `1.24.0` aus jeglicher Quelle ist nicht grundsätzlich sicher. Ubuntu hat offiziell auch deutlich darauf hingewiesen, dass CVE-2026-95101 nur Ubuntu 26.04 / 26.10 betrifft und CVE-2026-97629 nur Ubuntu 24.04 / 26.04 /26.10. Hier ist die eigene Verpackung und der Funktionsumfang von Ubuntu, die nicht direkt auf andere Distributionen übertragen werden können. [S13](https://keendigit.com/de/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: Unterschiede zwischen Versionen müssen separat geprüft werden Die Debian-Beratung DSA-6575-1 (2026-10-21) deckt diese fünf CVEs ab und identifiziert das feste `nginx`-Paket für Debian 13 / trixie als: ```text 1.26.3-3+deb13u10 ``` Zum Zeitpunkt der Überprüfung dieses Berichts wurde `1.22.1-9+deb12u10` für Debian 12 / bookworm jedoch vom Debian Security Tracker immer noch als anfällig gekennzeichnet. Deshalb: - Debian 13 Einfach gemäß DSA-6575-1 aktualisieren und akzeptieren. - Debian 12 muss die vom aktuellen Security Tracker oder ELTS-Anbieter bereitgestellten Sicherheitsfixes einzeln überprüfen; Bevor der Fix in der Ankündigung bestätigt wird, erklären Sie nicht, dass alle fünf Punkte aufgrund des Erfolgs von `apt upgrade` behoben wurden. - Das Quellpaket Debian enthält möglicherweise einen Patchsatz, der von der Versionsnummer nginx.org unabhängig ist. Bei benutzerdefinierten Builds müssen Sie den vollständigen Fixsatz für das Quellcodepaket überprüfen, und Sie können nicht einfach einen einzelnen Upstream-Commit kopieren und ihn als vollständig betrachten. Die obige Unterscheidung basiert auf DSA- und CVE-Tracking-Datensätzen. [S14](https://keendigit.com/de/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/de/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/de/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs und Ingress Controller | Produkte/Komponenten | Wichtige Punkte bei der Auswahl und Überprüfung von Wertpapieren | | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus (kommerzielle Version) | Bitte beachten Sie die Ankündigung und Upgrade-Anweisungen des Plus-Zweigs entsprechend F5. Die neueste CR zum Zeitpunkt der Überprüfung ist `PLS.37.2.0.1`, und der Sicherheits-Build von LTS ist `PLS.37.0.7.1`; Die Plus-Version und der enthaltene Backport können nicht direkt durch den Open Source-Schwellenwert 1.30/1.31 ersetzt werden. [S19](https://keendigit.com/de/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 gibt `njs 1.0.2` frei und behebt CVE-2026-101019 und CVE-2026-101025; Wenn Sie njs verwenden, müssen Sie auch die Kompatibilität des Moduls mit NGINX prüfen. [S20](https://keendigit.com/de/insights/nginx-remediation-guide#source-20) | | F5 NGINX Ingress-Controller/Gateway-Fabric | Der NGINX-Kern ist eine verwandte, aber unabhängige Software-Vertriebskette. Beheben Sie die relevanten Schwachstellen mit den entsprechenden Controllern, Bildern und Versionshinweisen. Sie können nicht einfach eine NGINX-Binärdatei im Pod ersetzen. | | Kubernetes Gemeinschaft `kubernetes/ingress-nginx` | Das Projekt wird im März 2026 stillgelegt und wird keine neuen Sicherheitswartungen mehr durchführen. Sie sollten die Migration auf einen gewarteten Controller oder Gateway API planen, anstatt dessen Versionsnummer mit dem Ingress-Controller F5 NGINX zu verwechseln. [S21](https://keendigit.com/de/insights/nginx-remediation-guide#source-21) | ### 3.6 Welchen Patch sollte man eigentlich wählen? | Bereitstellungsformular | Empfohlene Praktiken | Reparaturnachweis | | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | nginx.org offizielles DEB/RPM-Paket | Upgrade auf die feste Version des Upstream-Zweigs | `nginx -v/-V`, Paketquelle, offizielle Sicherheitsmitteilung | | Offizielles Repository Ubuntu/Debian | Installieren Sie Sicherheitspakete des Herstellers | Vollständige Paketversion + USN/DSA des Anbieters + CVE-Status | | RHEL/Alma/Rocky/SUSE/Andere Distributionen | Aktualisieren Sie entsprechend den spezifischen Sicherheitsbulletins und Paketversionen der Distribution | Die entsprechende CSAF/Ankündigung des Anbieters, Version Ubuntu/Debian, kann nicht angewendet werden | | Offizielle oder benutzerdefinierte Containerbilder | Erstellen Sie das verifizierte Reparatur-Image neu oder ziehen Sie es herunter und ersetzen Sie es fortlaufend | Image-Digest, SBOM erstellen, Pod-/Container-Image-ID ausführen | | Selbstkompilierte NGINX, OpenResty, Tengine oder mit Modulen von Drittanbietern gepatchte Versionen | Priorisieren Sie die Verwendung der vollständigen Sicherheitsversion des Betreuers. Führen Sie bei Bedarf überprüfte Patch-Backports für den Zielquellbaum durch | Fünf Schwachstellenkorrekturen, ABI-/Modulkompatibilität, Einheiten- und Geschäftsregression | OpenResty und Tengine sind unterschiedliche Freigabesysteme; In dieser Tabelle wird nur die Überprüfungsmethode beschrieben. bedeutet nicht, dass alle seine Versionen gleichzeitig betroffen sind wie der Standard NGINX, noch kann der Upstream-Code-Patch bedingungslos angewendet werden. ## 4. Formaler Reparaturprozess ### 4.1 Inventar der tatsächlichen Fälle, in denen externer Datenverkehr empfangen wurde Sortieren Sie für jeden Eintrag mindestens Folgendes: - Domänenname, Lastausgleich/CDN/Edge-Proxy-Link, Ursprungsstandort-Offenlegungsmethode und verwendetes Netzwerkprotokoll. - NGINX-Produkte (Open Source, Plus, Ingress usw.), Vollversion, Paket-Repository-Quelle, Image-Digest. - `nginx -V` zeigt die Baumodule und Kompilierungsparameter an; ob es njs-, Lua-, OpenResty- und dynamische Module von Drittanbietern gibt. - Echt laufender master/worker PID, Serviceeinheit/Container/Pod, Replikat und Worker-Knoten. - Die tatsächlich wirksamen Konfigurationen `http`/`stream`, `server`, `location`, `include`. - Ob HTTP/3, mTLS, SSI/AIO, dynamischer Protokollpfad, komplexe `map` und Regex-Erfassung aktiviert werden sollen. Überprüfen Sie nicht nur den Standardwert `/etc/nginx/nginx.conf`. Die Produktionsumgebung lädt häufig mehrere Standorte, TLS und Modulkonfigurationen über `include`. Möglicherweise gibt es auch mehrere NGINX-Installationspfade oder mehrere Proxy-Ebenen. ### 4.2 Überprüfen Sie die Versions- und Kompilierungsinformationen ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` meldet den Build der im Befehlszeilenpfad gefundenen Binärdatei. es beweist nicht, dass der laufende worker es geladen hat. Bei `nginx -v` fehlt möglicherweise das vollständige Paketsuffix der Distribution. Überprüfen Sie daher auch den Paketmanager oder die Lieferkettenaufzeichnungen. ### 4.3 Exportieren Sie die effektive Konfiguration und führen Sie die erste Runde der statischen Überprüfung durch `nginx -T` testet die Konfiguration und gibt die zusammengeführte Konfiguration aus. Die Ausgabe kann vertrauliche Informationen wie Authentifizierungsdaten, Schlüsselpfade, interne Hostnamen usw. enthalten. Es wird empfohlen, das kontrollierte Terminal mit root-Berechtigungen und privaten Dateiberechtigungen zu speichern und die Originaldateien nicht in öffentlichen Arbeitsaufträgen zu veröffentlichen: ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` Dies ist nur der Kandidatenpfad-Locator, kein zuverlässiges automatisches CVE-Ermittlungstool: 1. `grep` kann nicht feststellen, ob sich die Variablen in derselben `location` oder derselben Anforderungsauswertungskette befinden, und kann auch nicht auf die Konfigurationsvererbungsbeziehung schließen. 2. `proxy_request_buffering on`, einige Cache- und Ticketkonfigurationen haben Standardwerte und das Nichtschreiben der entsprechenden Anweisungen bedeutet nicht, dass das Risiko verschwindet. 3. Von Reverse-Proxys, CDN, Container-Sidecars oder Controllern generierte Konfigurationen können von manuell überprüften Dateien abweichen. 4. Die Eigenschaften von `NGINX Plus` und dynamischen Modulen müssen möglicherweise mit ihren jeweiligen offiziellen Verwaltungstools bestätigt werden. ### 4.4 Fix über vertrauenswürdige Kanäle bereitstellen Debian/Ubuntu (offizielles Distributions-Repository): ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` Dieser Befehlssatz kann keine Sicherheitsfixes aus dem Nichts generieren, die noch nicht verfügbar sind. Insbesondere für Debian 12 sind zusätzliche Reparatur-, Isolierungs- oder Migrationsmaßnahmen des Anbieters erforderlich, wenn das aktualisierte Paket vom Sicherheitsverfolgungssystem immer noch als anfällig eingestuft wird. [S13](https://keendigit.com/de/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/de/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/de/insights/nginx-remediation-guide#source-15) Offizielles nginx.org-Paket: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` Wenn Sie selbstkompilierte OpenResty-, Tengine- oder NGINX Plus-Pakete verwenden, verwenden Sie die vom entsprechenden Betreuer unterstützte Fixversion und mischen Sie nicht nginx.org-, Distributions- und Drittanbieter-Repository-Pakete. Die ursprünglichen Binärdateien/Images, Konfigurationen, Signaturen und Rollback-Bereitstellungsmanifeste sollten erhalten bleiben. Container/Kubernetes: Aktualisieren Sie das unveränderliche Image, zeichnen Sie seinen Digest auf und ersetzen Sie alle alten Replikate durch einen gestaffelten Rollout. `kubectl rollout status` bestätigt nur, dass der Deployment Controller abgeschlossen ist; Überprüfen Sie außerdem Image-Digests, Ingress-Routing und fehlerhafte Replikate. ### 4.5 Überprüfen Sie die Konfiguration und ersetzen Sie das alte Worker ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` Betrachten Sie `nginx -s reload` nicht als Beweis dafür, dass eine neue Binärdatei ausgeführt wird: Durch normales Neuladen der Konfiguration kann der alte master neue Worker starten, ohne die ausführbare Datei zu ersetzen. NGINX unterstützt ein dediziertes Online-Binär-Upgrade-Verfahren, erfordert jedoch zusätzliche Schritte und Überprüfung. Ohne ein etabliertes Verfahren verwenden Sie einen hochverfügbaren Datenverkehrsschalter mit anschließendem Neustart des Dienstes oder führen Sie Ersatzcontainer ein. [S22](https://keendigit.com/de/insights/nginx-remediation-guide#source-22) Wenn Sie NGINX über den `systemd`-Socket, ein Container-Eintragsskript oder mehrere Installationen verwalten, sollten Sie das tatsächliche Startziel und den Prozesspfad überprüfen, anstatt direkt davon auszugehen, dass `systemctl restart nginx` alle Instanzen abdeckt. ### 4.6 Akzeptieren und führen Sie geschäftliche Regressionen vom echten externen Eingang aus durch Es wird empfohlen, mindestens Folgendes durchzuführen: - Sind normales HTTPS, neu geschriebene Routen, statische Ressourcen und `alias`-Zuordnungsseiten korrekt? - Sind die reguläre `map`-Verteilung, der variable root-Pfad, der Zugriffsprotokollpfad, das SNI/Zertifikat-Routing und der Stream-Proxy korrekt? - Entsprechen normale Uploads, Chunked-Uploads, API-Anfragen und Upstream-Volumenlimits für HTTP/3 (sofern aktiviert) weiterhin den Erwartungen? - mTLS: Legitime Zertifikatsanfragen sollten erfolgreich sein; Fehlende, abgelaufene oder nicht autorisierte Zertifikate sollten weiterhin abgelehnt werden und die Wiederaufnahme/Wiederverbindung von TLS sollte die Berechtigungen nicht versehentlich ändern. - Ob die SSI-Seite und der asynchrone Dateizugriff normal sind; Das Fehlerprotokoll zeigt keine ungewöhnlichen Anforderungen für Speicherreferenzen oder wiederholte Worker-Abstürze. - Nach der Verkehrsumschaltung sollten der alte Versionsprozess und die alte Image-Replik beendet sein. Die Tests müssen in einer eigenen oder autorisierten Umgebung durchgeführt werden. Ein normaler Anforderungsrauchtest allein kann nicht beweisen, dass die Speicherschwachstelle behoben wurde. Letztendlich müssen die feste Version, der Quellcode-Patch und der Laufzeittest des Lieferanten gemeinsam zur Abnahme akzeptiert werden. ## 5. Abhilfemaßnahmen, wenn ein sofortiges Upgrade nicht möglich ist Bei diesem Abschnitt handelt es sich um eine Option zur Risikominderung, nicht um einen Patch-Ersatz. Alle temporären Konfigurationsänderungen sollten gesichert, `nginx -t` ausgeführt, stapelweise freigegeben und bei Bedarf schnell zurückgesetzt werden. [S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) ### 5.1 Kontrollieren Sie die Verkehrspriorität basierend auf der externen Exposition Priorisieren Sie die Reduzierung der Angriffsfläche von Diensten, die nicht rechtzeitig aktualisiert werden können: auf der Verwaltungsoberfläche und intern API Fügen Sie vertrauenswürdige Quellzugriffskontrolle, Upstream-Netzwerkisolierung oder kurzfristige Offline-Verbindungen hinzu; Hinzufügen von Verbindungs-, Anforderungstext- und Ratenbeschränkungen zu Hochrisikoeingängen; Stellen Sie sicher, dass die Quellenauthentifizierung am eintragsbezogenen NGINX vor der Anforderungsverarbeitungskette erfolgt. Es ist zu beachten, dass sich die meisten Schwachstellen selbst in NGINX befinden. Auf der Datenebene können herkömmliche WAF-Regeln die Auslösebedingungen für benutzerdefinierte Konfigurationen möglicherweise nicht genau bestimmen. ### 5.2 `alias` / `rewrite`: Vermeiden Sie die Auswertung von `$request_filename` nach dem Umschreiben Es wird empfohlen, Folgendes zu überprüfen und anzupassen: - Versuchen Sie, `rewrite`, das URI ändert, nicht gleichzeitig mit `location` unter Verwendung von `alias` auszuführen. - Vermeiden Sie die Verwendung von `$request_filename`, wenn URI neu geschrieben wurde, die korrekte Positionsübereinstimmung jedoch noch nicht abgeschlossen ist. - Suchen Sie nach indirekten Variablenverweisen in `return`, `set`, `if`, `add_header`, im Zugriffsprotokollformat und in den Include-Dateien. - Verwenden Sie klares `root`/`try_files`/unabhängiges `location`, wenn das Geschäft dies zulässt, ändern Sie `alias` jedoch nur in `root`. Es kann auch die Semantik des Dateipfads ändern, die einzeln überprüft werden muss. Kopieren Sie nicht direkt die gängige „Safe Rewrite-Vorlage“ im Internet, um die vorhandene Konfiguration zu überschreiben. Unterschiedliche `location`-Präfixe und Rewrite-Ziele führen zu Pfadspleißungen mit völlig unterschiedlichen Bedeutungen. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: Reduzieren Sie das Mischen von Erfassungsvariablenzuständen Es wird empfohlen, benannte Captures zu priorisieren und ihren Verbreitungsbereich zu begrenzen, anstatt zuzulassen, dass anonyme Captures wie `$1` im Laufe der Zeit über verschiedene Regex-Auswertungspfade hinweg wiederverwendet werden. Zum Beispiel: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` Dieses Snippet zeigt lediglich eine einfacher zu prüfende Struktur des Variableneigentums; bedeutet nicht, dass nachgewiesen wurde, dass alle CVE-2026-93479-Triggerpfade unabhängig voneinander eliminiert werden. Überprüfen Sie insbesondere, ob Erfassungsvariablen vorab von anderen `root` oder `log_format` referenziert werden und ob `volatile`, dynamische Pfade und voneinander abhängige Auswertungsketten vorhanden sind. Als kurzfristige Erleichterung empfiehlt F5/CERT, die benannte Erfassung zu verwenden und den Nutzungsumfang auf die entsprechende reguläre Matching-Konfiguration zu beschränken. [S3](https://keendigit.com/de/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/de/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: Beenden Sie nicht benötigte Funktionskombinationen Für Server/Pfade, die weder SSI noch asynchrone Datei-E/A erfordern, verwenden Sie: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` Aus der Perspektive der Bedingungen, die eine Sicherheitslücke auslösen, reicht es in der Regel aus, eine der beiden zu schließen, um die beschriebene spezifische Kette zu entfernen; Das gleichzeitige Schließen ist nur auf Szenarien anwendbar, in denen das Unternehmen nicht auf diese Funktion angewiesen ist. Überprüfen Sie das Verhalten von `include virtual`, Unteranforderungen, Cache und Thread-Pool. Wenn die Reverse-Proxy-Last hoch ist, kann das Herunterfahren von AIO die Latenz und die E/A-Leistung verändern. [S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 Körperinjektion anfordern: Bei Bedarf den Eingang vorübergehend schließen Deaktivieren Sie den `quic`-Listener, der HTTP/3 einbezieht, löschen Sie den `Alt-Svc`-Antwortheader, der HTTP/3 ankündigt, und prüfen Sie, ob der Edge-Layer/Load-Balancer weiterhin QUIC-Anfragen direkt an den nicht reparierten NGINX sendet: ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` Das Obige ist lediglich eine Beschreibung des Änderungsunterschieds und keine vollständige Serverkonfiguration, die einzeln aktiviert werden kann. Die Einstellungssyntax von HTTP/2 bezieht sich auf die Version NGINX; Wenn Sie HTTP/2 beibehalten müssen, sollten Sie `http2 on;` oder die vorhandene gültige Syntax entsprechend der entsprechenden Version verwenden und mit `nginx -t` prüfen. muss vor der Bereitstellung mit der vorhandenen Serverkonfiguration zusammengeführt werden, anstatt den gesamten Abschnitt durch diesen Abschnitt zu ersetzen. Überprüft außerdem die UDP 443-Firewall, den Terminierungsstandort HTTP/3 und den Client-Fallback-Pfad von CDN/Front-Proxy. Eine andere Art der kurzfristigen Abhilfe besteht darin, `proxy_request_buffering off;` auf dem betroffenen Proxy-Pfad zu verwenden. Dies ändert jedoch das Verhalten des Upstream-Anfragetext-Streamings, der Wiederholungsversuche bei Fehlern und einiger Upload-Workflows. darf nur nach ausreichenden Tests und der Bestätigung verwendet werden, dass die Direktive den betroffenen HTTP/3-Proxy-Pfad erreicht. [S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/de/insights/nginx-remediation-guide#source-18) ### 5.6 TLS Sitzungsticket: Prioritätsschutz mTLS Authentifizierungsgrenze Wenn ein Upgrade nicht möglich ist und die Instanz auf den gemeinsamen Sitzungscache + automatische Ticketschlüsselrotation angewiesen ist, prüfen Sie Folgendes: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` Dadurch kann der TLS-Sitzungsticketmechanismus deaktiviert werden, wodurch der in dieser Schwachstelle beschriebene Ticketfälschungspfad entfernt wird. Dies kann sich jedoch auf die Leistung bei der Sitzungswiederaufnahme auswirken. Sie können die Überprüfung des mTLS-Clientzertifikats nicht einfach deaktivieren, um „Schwachstellen zu vermeiden“, da dadurch die ursprüngliche Authentifizierungsgrenze direkt gelöscht wird. [S9](https://keendigit.com/de/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/de/insights/nginx-remediation-guide#source-12) Explizite `ssl_session_ticket_key`-Dateien und sichere Rotation können auch von professionellen TLS-Verwaltungsprozessen verwendet werden, um automatisch generierte Bedingungen zu umgehen, aber Schlüsselverwahrung, vollständige Knotenverteilung, Rotation und alte Ticket-Lebenszyklen müssen alle sorgfältig geprüft werden. Es wird nicht empfohlen, einen langfristig wiederverwendbaren Schlüssel in der normalen Webkonfiguration oder in Skripten für vorübergehende Notfälle fest zu codieren. Kritische Dienste, die mTLS verwenden, sollten zusätzlich auf das Sitzungswiederaufnahmeverhalten von TLS und die Ablehnung von Anforderungen ohne gültiges Client-Zertifikat überwacht werden. [S12](https://keendigit.com/de/insights/nginx-remediation-guide#source-12) ### 5.7 Die Rolle des Betriebssystems und des Grenzschutzes ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR, Nicht-root-Worker, schreibgeschützte Containerdateisysteme, minimale Dateiberechtigungen und Netzwerkisolation können die Auswirkungen potenzieller RCE verringern. ASLR behebt keine Heap-Überläufe oder UAF und kann nicht garantieren, dass Worker nicht abstürzen. WAF, Ratenbeschränkungen und Größenbeschränkungen für Anforderungstexte beheben nicht die Ticketschlüsselsynchronisierung TLS. [S4](https://keendigit.com/de/insights/nginx-remediation-guide#source-4) ### 5.8 Häufiges Missverständnis: Diese Vorgänge reichen nicht aus, um die Reparatur abzuschließen | Gemeinsame Operationen | Warum reicht es nicht aus? | | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | „nginx -v sieht relativ neu aus“ | Der Zweig, zu dem es gehört, die vollständige zurückportierte Paketversion der Release-Version und der Online-Prozess werden nicht überprüft. | | „Nur eines der Intranets wurde aktualisiert“ | Die alte Ursprungsinstanz Worker/alter Container/alte CDN empfängt weiterhin Anfragen | | „Site verwendet keine PHP/dynamischen Tags“ | Der Fehler tritt beim NGINX-Kernpfad oder beim Parsen des Protokolls auf und hängt nicht von der PHP-Ausführung ab. | | „Es reicht aus, WAF/Cloudflare zu öffnen“ | Es kann nicht nachgewiesen werden, dass WAF alle konfigurationsabhängigen Speicherfehler NGINX oder alle Wiederaufnahmefehler TLS blockiert | | „Bereits geöffnet ASLR“ | Einfach die Schwierigkeitsminderung ausnutzen; DoS mit Request-Injection ist weiterhin möglich | | „HTTP/3 ist nicht dem öffentlichen Netzwerk ausgesetzt, daher ist überhaupt kein Upgrade erforderlich.“ | Die anderen vier CVEs bedürfen noch einer unabhängigen Bewertung; und es kann direkte Verbindungen zu verborgenen Ursprüngen geben | | „Die Schwachstelle `map` vom Juli wurde behoben“ | Oktober CVE-2026-93479 beinhaltet nachfolgende Regressionsprobleme bei der Skriptauswertung | | „Das Deaktivieren des Cachings löst alle Probleme“ | Betrifft nur einige TLS-Cache- oder AIO-Szenarien und deckt Alias, Skript und HTTP/3 nicht ab | ## 6. Offizielle Ideen zur Patch-Implementierung und Überprüfungspunkte In diesem Abschnitt werden die Upstream-Fixes NGINX vom Oktober 2026 behandelt. Die Ausschnitte veranschaulichen repräsentative Änderungen für die Patch-Überprüfung; Es handelt sich nicht um vollständige, unabhängig kompilierbare Korrekturen. Überprüfen Sie bei benutzerdefinierten Builds die vollständigen Commits, den umgebenden Code und die Tests und bevorzugen Sie eine vollständig unterstützte Version. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/de/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/de/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI wurde umgeschrieben, um die Ablehnungsbedingungen für die Pfadzuordnung `alias` einzuschließen Der Upstream-Commit hat `ngx_http_map_uri_to_path()` in `src/http/ngx_http_core_module.c` geändert: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` Überprüfungsschwerpunkt: Der Dateisystempfad kann nicht weiter berechnet werden, wenn sich URI geändert hat, die entsprechende Standortsemantik von `alias` jedoch nicht mehr zuverlässig ist. Dies ist eine Erweiterung der Vorzustandsbeschränkung. Es handelt sich nicht um eine einfache Prüfung, ob die Anfrage URI unzulässige Zeichen enthält. [S5](https://keendigit.com/de/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: Korrekte Unterscheidung zwischen Ausgabedatenlänge und reservierter Länge Der Upstream-Commit aktualisiert `src/http/ngx_http_script.c` und `src/stream/ngx_stream_script.c` gleichzeitig. Die Kernabsicht lässt sich wie folgt zusammenfassen: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` Hier ist `pool` ein beispielhafter Parametername: Die tatsächlichen HTTP- und Stream-Zuordnungsausdrücke unterscheiden sich. Die Änderung berechnet zunächst die Länge der Skriptausgabe und fügt dann die reservierte Länge zur endgültigen Zuweisung hinzu, sodass die Ausgabe den reservierten Speicherplatz nicht überschreibt. [S6](https://keendigit.com/de/insights/nginx-remediation-guide#source-6) Beim Auditing und Backporting muss auch der entsprechende Evaluator von HTTP/Stream abgedeckt werden; Nur die Überprüfung der Konfigurationssyntaxdatei von `map` kann nicht beweisen, dass der Fehler behoben wurde. ### 6.3 CVE-2026-97205: Sicherheitsschwelle für die asynchrone 8-Bit-Vorgangszählung festlegen Upstream hinzugefügt bei `src/http/ngx_http_request.h`: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` Und fügen Sie ähnliche Einträge zum asynchronen Lesen von Dateien, zum Warten im Cache, zur Ausgabefilterung und zum Thread-Betrieb hinzu: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` Überprüfungsschwerpunkt: Alle tatsächlichen Codepfade, die `r->main->blocked` hinzufügen, müssen abgedeckt werden. Sie können die Schwellenwertkonstante nicht einfach in die Header-Datei schreiben. Backport muss außerdem die vollständige Koordination von synchronem Fallback, asynchronem Rückruf und Fehlerrückgabe überprüfen, um sicherzustellen, dass durch die direkte Ablehnung von Aufgaben kein Deadlock oder Referenzverlust verursacht wird. [S7](https://keendigit.com/de/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: Behalten Sie den Status `skip` für unbekannte Frames separat bei Der Upstream fügt das Feld `skip` in der Parser-Statusstruktur HTTP/3 hinzu und führt eine Statustrennung durch: ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` Der Schlüssel besteht nicht darin, „unbekannte HTTP/3-Frames zu deaktivieren“, sondern sicherzustellen, dass bei mehreren Lesevorgängen die Anzahl der übersprungenen Bytes und die Länge der DATA-Nutzdaten immer von unabhängigen Zuständen verwaltet werden. Die Überprüfungen sollten sich auf unbekanntes Frame-Cross-Buffer-Sharding und die eventuelle Konsistenz von `client_max_body_size` konzentrieren. [S8](https://keendigit.com/de/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: Synchronisieren Sie das gesamte TLS-Schlüsselsteckplatz-Array Die Upstream-Änderungen befinden sich unter `src/event/ngx_event_openssl.c`: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` Das Originalbild enthielt drei Schlüsselsteckplätze, aber nur die ersten beiden wurden kopiert. Führen Sie stattdessen eine Synchronisierung basierend auf der tatsächlichen Anzahl von Array-Elementen durch, um sicherzustellen, dass der Abstimmungsschlüsselsatz von Worker mit dem gemeinsam genutzten Speicher übereinstimmt. Stellen Sie bei der Überprüfung außerdem sicher, dass die Array-Zuweisung, die Initialisierung, die gemeinsame Sperre und die Rotationslogik konsistent sind, anstatt die Längenänderung `memcpy` nur einmal zu überprüfen. [S9](https://keendigit.com/de/insights/nginx-remediation-guide#source-9) ### 6.6 Warum wird nicht empfohlen, nur verstreute Patch-Fragmente anzuwenden? Diese fünf Modifikationen umfassen jeweils `src/http`, `src/stream`, `src/http/v3` und `src/event`. Ältere Versionen verfügen möglicherweise über Sicherheits-Backports und inoffizielle Erweiterungen. Die Rückportierung sollte die folgende Prüfmatrix bilden: | Objekt prüfen | Was muss bestätigt werden | | ----------------------- | ------------------------------------------------------------------------------------------------------ | | Patch-Quelle | Offizielle Einreichung, passende Zielversion, vollständige Patch- und Signaturüberprüfung | | Original-Patch-Set | Kein Konflikt mit historischen Modifikationen wie CVE-2026-42533, Distributions-Backport usw. | | Codepfad | HTTP + Stream-Skript, AIO/Thread, HTTP/3, OpenSSL-Ticket werden alle abgedeckt | | Kompatibel kompiliert | OpenSSL, PCRE, Modul-ABI, dynamische Modul- und Linkabhängigkeiten sind konsistent | | funktionelle Regression | `alias`-Umschreibung, dynamisches Protokoll, SSI/AIO, HTTP/3-Upload, mTLS-Sitzungswiederaufnahme | | Laufzeit | Auf allen Worker/Pods werden neue verifizierte Builds ausgeführt, es bleiben keine Legacy-Images übrig | Für Teams, die ihre eigenen Releases verwalten, wird empfohlen, überprüfbare Patch-IDs, Paketversionen, Build-Protokolle und Regressionsberichte für jedes CVE aufzubewahren. Für den normalen Betrieb und die Wartung besteht die sicherste Lösung darin, die vollständigen Sicherheitsupdates des Anbieters zu installieren. ## 7. Rückverfolgung historischer Schwachstellen, alte Zweige und andere Produkte ### Die zentrale Schwachstelle 7.1 NGINX verdient eine gleichzeitige Bestätigung von Mai bis September 2026 Viele NGINX-Instanzen, die lange Zeit nicht aktualisiert wurden, sind nicht erst im Oktober von der neuen Ausgabe betroffen. Im Folgenden sind die repräsentativen Reparaturknoten in naher Zukunft aufgeführt: [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/nginx-remediation-guide#source-2) | CVE | Erste Fix-Veröffentlichung | Wichtige Risiken und Bedingungen, die einer Prüfung bedürfen | | -------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, 13. Mai | `rewrite` Anonyme Regex-Erfassungs- und Ersetzungslogik löst Heap-Überlauf aus, potenziell RCE; Es gibt öffentliche Berichte über Angriffsversuche in freier Wildbahn | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1, 22. Mai | Überlappende Regex-Erfassung und Längenschätzung in `rewrite` führen zu einem Überlauf | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 17. Juni | HTTP/2 Spezifische Konfiguration für Upstream oder gRPC, große Anforderungsheaderbedingung löst Pufferüberlauf aus | | CVE-2026-42530 | Mainline 1.31.2, 17. Juni | HTTP/3 Kostenlose Nutzung nach dem Gebrauch; Offizielles Markenzeichen betroffener Bereich `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15. Juli | Die Auswertung der `map` + Regex-Erfassungsvariablen führt zu einem Heap-Überlauf, und nachfolgende Patches weisen eine Regressionskorrelation mit CVE-2026-93479 im Oktober auf | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 15. Juli | `ngx_http_slice_module` Speicherinhalt ist unter bestimmten Variablen- und Cache-Aktualisierungsbedingungen verloren gegangen | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 15. Juli | SSI ist mit UAF verwandt; nicht die gleiche root-Ursache wie die AIO-Zählschwachstelle im Oktober | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 15. September | Begrenzter Heap-Überlauf der Kombination HTTP/3 + spezifischer OpenSSL-Version, der sich hauptsächlich in einem Absturz/eingeschränkter Speicherbeschädigung äußert | Andere im Jahr 2026 angekündigte Schwachstellen wie NGINX Core, HTTP/2, charset und SMTP sollten laut offiziellen Sicherheitsbulletins ebenfalls untersucht werden; Diese Tabelle konzentriert sich absichtlich auf typische Ereignisse, die für die aktuellen öffentlich zugänglichen Reverse-Proxy-Bereitstellungen NGINX am relevantesten sind und Auswirkungen auf die Speichersicherheit oder die Anforderungsintegrität haben. sind nicht alle CVEs im Jahr 2026. Liste. [S1](https://keendigit.com/de/insights/nginx-remediation-guide#source-1) #### Warum CVE-2026-42945 besondere Aufmerksamkeit schenken? Es gibt Sicherheitsbulletins von Regierungsbehörden, die im Mai aktive Ausnutzungsaktivitäten und öffentliche Exploit-Code-Informationen für diese Schwachstelle `rewrite` aufzeichnen. Daher sollten für Instanzen, die von Mai bis heute lange Zeit nicht gepatcht wurden und über offene komplexe Umschreibungen regulärer Ausdrücke im öffentlichen Netzwerk verfügen, zusätzlich zum Abschluss der Reparatur zusätzlich der abnormale Worker-Absturz, Zugriffsprotokolle und verdächtige Änderungen zu diesem Zeitpunkt überprüft werden. [S23](https://keendigit.com/de/insights/nginx-remediation-guide#source-23) „Ein Angriffsversuch erfolgte“ beweist nicht automatisch, dass der Angreifer bei jedem Ziel Befehle zuverlässig ausgeführt hat; Wenn es um die Reaktion auf Vorfälle geht, sollten Kompromittierungsindikatoren und Prozessabstürze getrennt von echten Beweisen für eine Rechteausweitung oder -persistenz untersucht werden. ### 7.2 Behebung für ältere Versionen und Distributions-Backports NGINX Verschiedene Branchen haben ihre eigenen Supportzyklen und unterschiedliche Zeiten für die Einführung von Schwachstellen. Die fünf neuen Patches können ohne Überprüfung nicht für alle frühen Quellbäume bereitgestellt werden. | Szene | Empfohlene Strategie | | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Die Release-Version hat vollständige Sicherheitspatches angekündigt | Verwenden Sie Anbieterpakete und dokumentieren Sie vollständige Paketversionen. Vermeiden Sie den Austausch durch inkompatible Upstream-Bare-Binärdateien | | Debian 12 und andere betroffene Versionen, die noch nicht von allen CVEs in diesem Batch abgedeckt werden | Senden Sie Risiko-Arbeitsaufträge, begrenzen Sie die externe Belastung und prüfen Sie den Lieferanten-/ELTS-Status. Bei Bedarf können Sie migrieren oder eine überprüfbare Wartungs-Release-Kette verwenden | | Historische Zweige, deren Upstream-Unterstützung eingestellt wurde | Priorisieren Sie die Migration auf unterstützte Versionen; Wenn eine kurzfristige Rückportierung erforderlich ist, bewerten die Betreuer die Abhängigkeiten und die Patch-Kompatibilität und schreiben vollständige Tests. | | Kommt mit NGINX-Gabel (OpenResty, Tengine, angepasstes Gateway) | Stellen Sie zunächst fest, ob der entsprechende Codepfad enthalten ist, und verwenden Sie dann die Sicherheitserklärung des Fork-Betreuers. Es kann nicht direkt mit der Upstream-Version äquivalent sein. | | Sicherheitspatches führen zu Änderungen der Geschäftsfunktionalität | Einführung gestaffelter Rollouts, Traffic-Umschaltung zwischen Versionen und Konfigurationsanpassungen; Es ist nicht angebracht, die nicht reparierte Version des öffentlichen Netzwerks ohne Isolierung wiederherzustellen. | ### 7.3 Separate Behebung für njs, Ingress und NGINX Core - njs: Zusätzlich zum Hauptprogramm NGINX müssen Sie auch die Version des JavaScript-Moduls NGINX selbst überprüfen. `njs 1.0.2` behebt ein im Oktober 2026 aufgetretenes Problem mit der Erschöpfung des XML-Parsing-Speichers und der Inkonsistenz der XML-Validierung mit Entitätsreferenzattributen. Für Bereitstellungen im Zusammenhang mit der XML-Signaturüberprüfung mithilfe von `nginx-saml` sollten Sie die offiziellen njs-Anweisungen für Plug-in-Szenarien weiter lesen. [S20](https://keendigit.com/de/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Ingress Controller: Darüber hinaus können Controller und Gateway Fabric jeweils zusätzliche Sicherheitsbulletins, unterschiedliche Paketversionen und einzigartige Richtlinienschwachstellen aufweisen. Das Aktualisieren einer Ebene bedeutet nicht, dass automatisch eine andere Ebene aktualisiert wird. [S19](https://keendigit.com/de/insights/nginx-remediation-guide#source-19) - Kubernetes-Community ingress-nginx: Beamte von Kubernetes haben bereits angekündigt, dass die Wartung des Controllers im März 2026 eingestellt wurde und sein Lager nicht mit dem F5-Controller verwechselt werden kann. Betroffene Unternehmen sollten eine reibungslose Migration planen und Ingress-Annotationen sowie semantische Unterschiede zwischen Gateway API überprüfen, anstatt auf eine neue Sicherheitsversion zu warten. [S21](https://keendigit.com/de/insights/nginx-remediation-guide#source-21) ## 8. Abnahmekriterien und Nachkontrollen Es wird empfohlen, die folgende Liste als Annahmebedingungen für Änderungsaufträge zu verwenden: | Projekt | Qualifikationsstandards | Beweise, die aufbewahrt werden können | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Asset- und Portalabdeckung | Alle externen und direkt verbundenen Instanzen, die CDN umgehen können, wurden inventarisiert. | Domänenname, LB, IP, Pod-/Containerliste | | Paketquelle und Reparaturumfang | Verwenden Sie Versionen, die alle anwendbaren CVEs abdecken | Upstream-Sicherheitshinweis, USN/DSA, Paketversion, Image-Digest | | Der alte Prozess wird beendet | Alle alten master/worker/Container wurden ersetzt | PID/Startzeit, fortlaufender Bereitstellungsstatus, ausgeführtes Image | | Konfigurationsaudit | Hochrisikokombinationen wurden eliminiert oder durch Patches abgedeckt und Vererbungsbeziehungen wurden überprüft | redigierte Zusammenfassung und Prüfprotokoll von `nginx -T` | | TLS/mTLS | Vertrauenswürdige Zertifikate bestehen; ungültige oder fehlende Zertifikate werden abgelehnt; Bei der Wiederaufnahme der Sitzung wird die Authentifizierung nicht umgangen | Negativer/positiver Autorisierungstest, kontrollierte TLS-Testergebnisse | | HTTP/3-Anfragetext | Aktivierungspfad behoben; Upstream-Anfragetext und Drosselung verhalten sich korrekt | HTTP/3, Proxy-Upload, Volumenlimit-Regressionstest | | SSI/AIO | Die Funktion erfüllt die Anforderungen, Worker weist keinen abnormalen Abbruch auf | Geschäftsregressions-, Absturz- und Fehlerratenüberwachung | | Betriebs- und Wartungsüberwachung | Keine offensichtliche Ausnahme 5xx, SIGSEGV, Prozess wird wiederholt beendet | Serviceindikatoren und Protokolle vor und nach Änderungen | | Rollback-Strategie | Wenn ein Rollback erforderlich ist, begrenzen Sie zunächst die Gefährdung und wahren Sie die Sicherheitsgrenzen | Änderungsbefehle, Notfallabläufe und Quarantänepläne | | anschließenden Lebenszyklus | Bestimmen Sie Security Bulletin-Abonnements, die Häufigkeit von Containeraktualisierungen und Zweigstellenmigrationspläne | Upgrade-Ledger, verantwortliche Person und nächstes Auditdatum | ### 8.1 Worauf sollten Sie sich in den Protokollen und im Ausführungsstatus konzentrieren? Beheben Sie Anomalien auf Servern, die über einen längeren Zeitraum exponiert waren `worker process exited on signal` 、 `SIGSEGV` , Anforderungsfehlerspitzen, abnormale Quellenzugriffsaggregation, unerwartete TLS Sitzungswiederaufnahme/Authentifizierungserfolg und abnormales Backend-Anforderungskörperverhalten. Diese Indikatoren können nur als Anhaltspunkte für Ermittlungen verwendet werden und sind kein ausreichender Beweis, um direkt zu beweisen, dass ein bestimmtes CVE ausgenutzt wurde. ;Das Fehlen relevanter Protokolle beweist nicht, dass kein Angriff stattgefunden hat. ### 8.2 Empfohlener endgültiger Wortlaut der Risikoschlussfolgerung Der Abnahmebericht für die Produktionsumgebung sollte den folgenden präzisen Ausdruck verwenden: > NGINX externer Serviceeingang und Softwarepaketquelle wurden identifiziert. Alle anwendbaren Instanzen wurden auf die offizielle Upstream-Sicherheitsversion aktualisiert oder der vom Release-Anbieter bestätigte Backport wurde abgeschlossen; Der alte Worker und alte Container wurden ersetzt. Die Alias/Rewrite/Map-, AIO/SSI-, HTTP/3-Anfragetext- und TLS-Sitzungsticket/mTLS-bezogenen Konfigurationen wurden geprüft und haben Funktions-, Authentifizierungs- und Anforderungsintegritäts-Regressionstests bestanden. Für Instanzen, bei denen die Modernisierung noch nicht abgeschlossen ist, erfassen Sie zusätzlich Gefährdungsbereiche, Ausgleichsmaßnahmen, Verantwortliche und Fertigstellungstermine. Wenn der Patch für Debian 12 oder andere Releases noch unvollständig ist, ist es nicht angemessen, das gesamte Annahmeformular als „abgeschlossen“ zu beurteilen; Das ungelöste CVE, ob eine entsprechende Triggerkonfiguration vorliegt, der Isolationsstatus und die endgültige Upgrade-Route sollten klar aufgezeichnet werden. *** ## Anhang: Zitierte Quellen und Links Beschreibung: Die `[Sx]`-Nummern im Text entsprechen einheitlich diesem Abschnitt. Im Folgenden werden Upstream-Projektsicherheitsankündigungen, Code-Commits, Ankündigungen von Lieferantenfreigaben und Informationen der nationalen Sicherheitsbehörden priorisiert. Der Schweregrad der genannten Schwachstellen wird anhand der Bewertungskriterien der jeweiligen ausstellenden Organisation beschrieben; Das Datum der Datenüberprüfung ist der 27. Oktober 2026. ### S1 – NGINX Open Source Offizielles Sicherheitsbulletin - Enthält die betroffenen Upstream-Versionen, Fixzweige und offiziellen Schweregrade von fünf CVEs vom Oktober und deckt auch historische Schwachstellen bis 2026 ab. ### S2 – NGINX offizieller Versionsveröffentlichungsdatensatz - - Bestätigen Sie 1.30.6 / 1.31.7 von 2026-10-14, 1.31.8 von 2026-10-21 und wichtige Meilensteine der Sicherheitsveröffentlichung von Mai bis September. ### S3 – Cyber Security Agency of Singapore: F5 NGINX Drei kritische Schwachstellen - Beschreibung der CVSS v4.0 9.2-Scores, erforderlichen Konfigurationsbedingungen und vorläufigen Abhilfeempfehlungen für CVE-2026-15176, CVE-2026-93479 und CVE-2026-97205. ### S4 – NHS England: F5 NGINX Hinweis zu hohem Risiko - Beschreibt die DoS / potenziellen RCE-Auswirkungen von Speichersicherheitsproblemen und Einschränkungen wie ASLR, die deaktiviert oder umgangen werden. ### S5 – Offizielles Quell-Commit: CVE-2026-15176 - Entspricht der Statusprüfung von `alias` und `r->uri_changed` in `ngx_http_map_uri_to_path()`. ### S6 – Offizielles Quell-Commit: CVE-2026-93479 - Entspricht der HTTP/Stream-Skriptlänge und der reservierten Pufferzuordnungslogik. ### S7 – Offizielles Quell-Commit: CVE-2026-97205 - Entspricht dem Zählschwellenwert `r->main->blocked` `NGX_HTTP_MAX_BLOCKED 250` und dem asynchronen Pfad-Fallback. ### S8 – Offizielles Quell-Commit: CVE-2026-95101 - Die Statustrennung entspricht der verbleibenden Länge des unbekannten Rahmens HTTP/3 und der Länge des Anforderungskörpers DATA. ### S9 – Offizielles Quell-Commit: CVE-2026-97629 - Entspricht allen Schlüsselslots während der Synchronisierung der Sitzungsticketrotation TLS. ### S10 – F5: Ankündigung des Anbieters CVE-2026-15176 - Listen Sie Triggerfaktoren wie `alias`, `rewrite`, `$request_filename` und Zugriffsprotokolle auf. ### S11 – F5: CVE-2026-93479 Anbieterankündigung - Listen Sie die Regex-Erfassung der Zuordnung, den root-Pfad und die Auswertungsbedingungen für Protokollvariablen auf. ### S12 – Offizielle NGINX-Moduldokumentation TLS/SSL - Beschreibung `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` und Client-Zertifikatauthentifizierung und andere Anweisungen. ### S13 — Sicherheitshinweis: Ubuntu USN-8955-1 (2026-10-26) - Stellen Sie das vollständige Softwarepaket mit fester Version und Vertriebsumfang von Ubuntu 22.04 / 24.04 / 26.04 / 26.10. bereit ### S14 — Sicherheitshinweis: Debian DSA-6575-1 (2026-10-21) - Bestätigen Sie das Sicherheitsfixpaket `1.26.3-3+deb13u10` für Debian 13 / trixie und notieren Sie die Backport-Zuordnung für CVE-2026-93479. ### S15 — Schwachstellenverfolgung: Debian Security Tracker: CVE-2026-15176 - Wird verwendet, um den Distributionsfixstatus von Debian 12 / bookworm und Debian 13 / trixie zu überprüfen. Dieser Status kann sich mit zukünftigen Sicherheitsupdates ändern. ### S16 — Schwachstellenverfolgung: Debian Security Tracker: CVE-2026-95101 - Ergänzende Bestätigung des Sicherheitsstatus der HTTP/3-Schwachstelle in verschiedenen Debian-Zweigen. ### S17 — Sicherheitshinweis: Red Hat: CVE-2026-93479 - Ergänzendes Verständnis der Korrelation zwischen der Regressionsschwachstelle im Oktober und dem Fix für CVE-2026-42533 im Juli. ### S18 – Offizielles Reverse-Proxy-Moduldokument NGINX - - Fragen Sie die Semantik und Standardwerte von Konfigurationen wie `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio` usw. ab. ### S19 – NGINX Plus Offizielle Versionshinweise - Liste Plus CR/LTS-Zweige, Versionen, Patches und Upgrade-Kompatibilitätserinnerungen. ### S20 – NGINX JavaScript / njs Offizielles Sicherheitsbulletin - - Enthält njs 1.0.2 vom Oktober 2026 und zugehörige Probleme bei der XML-Validierung und Speicherauslastung. ### S21 – Kubernetes: Offizielle Anweisungen zur Stilllegung der Community ingress-nginx - - Beachten Sie, dass das Projekt im März 2026 neue Versionen und Sicherheitsfixes eingestellt hat und es empfohlen wird, den gewarteten Controller oder Gateway API zu migrieren. ### S22 – NGINX offizielle Servicekontrolle und Online-Binär-Upgrade-Anweisungen - Unterscheiden Sie zwischen den Methoden zum Neuladen der Konfiguration, Neustart und Online-Aktualisierung ausführbarer Dateien für die Akzeptanz des Prozesswechsels. ### S23 – Sicherheitshinweis der Regierung: Schwachstelle NGINX beim Umschreiben vom Mai 2026 - - Bereitstellung eines historischen Risikohintergrunds und Vorschläge für Sicherheitsaktualisierungen für CVE-2026-42945; Urteile im Zusammenhang mit Ausbeutung in freier Wildbahn sollten auf der damaligen Ankündigung der Behörde und weiteren Beweisen für den Vorfall basieren. ### S24 – F5: CVE-2026-95101 und CVE-2026-97629 Anbieterankündigungen - - Deckt die Risiken der HTTP/3-Anforderungskörperinjektion bzw. der automatischen TLS-Ticketschlüsselrotation ab. ### S25 – F5: Ankündigung des Anbieters CVE-2026-97205 - Beschreibung SSI/AIO Auslösebedingungen und potenzielle Risiken einer Speicherbeschädigung. [NGINX-Sicherheitsupdate: Konfigurationsprüfungen, Upgrades und Überprüfung](https://keendigit.com/de/news/nginx-security-update) ## Beratung zur Sicherheitswartung Sie sind sich nicht sicher, wie sich Änderungen an der Zertifikatsvertrauenswürdigkeit auf Ihre Systeme auswirken? Wir können dabei helfen, betroffene Clients zu beurteilen und Sicherheitsupdates zu planen. [Besprechen Sie Sicherheitsupdates]() [Originalseite]() · [Inhaltsindex]() KeenDigit LLC · Wyoming-Einreichungs-ID: 2026-002106155 [Erkundigen Sie sich beim Außenminister von Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, USA · Alle Rechte vorbehalten.