CVE-2026-42055 ist ein Heap-basierter Pufferüberlauf in den NGINX-Modulen, die für Upstream-HTTP/2- und gRPC-Proxying verwendet werden. Es handelt sich um eine bedingte und nicht um eine pauschale Schwachstelle in jeder NGINX-Bereitstellung: Das betroffene Proxy-Verhalten, die deaktivierte Filterung ungültiger Header und übergroße, nicht standardmäßige Client-Header-Puffer müssen alle vorhanden sein. [S1][S4].
Betroffene Konfigurationen und Versionen
Der Anbieterdatensatz deckt NGINX Open Source und NGINX Plus nur ab, wenn alle dokumentierten Konfigurationsvoraussetzungen mit [S1][S4] übereinstimmen. Für NGINX Open Source sind die betroffenen veröffentlichten Versionen 1.13.10 bis 1.30.2 sowie 1.31.0 und 1.31.1; nginx.org identifiziert 1.30.3+ Stable und 1.31.2+ Mainline als nicht anfällig [S2][S3]. Im CNA-Datensatz von F5 sind auch NGINX Plus R37 37.0-Versionen vor 37.0.2.1 und R36-Versionen vor R36 P6 als betroffen aufgeführt; Versionen nach dem Ende des technischen Supports wurden nicht ausgewertet [S1][S4].
Auswirkung und Schwere
Ein nicht authentifizierter Remote-Angreifer könnte unter den erforderlichen Konfigurationsbedingungen einen Heap-Überlauf in einem NGINX-Worker auslösen, der einen Neustart des Workers und möglicherweise eine Unterbrechung des Dienstes zur Folge hätte. Die Codeausführung ist außerdem davon abhängig, dass die Adressraum-Layout-Randomisierung (ASLR) deaktiviert oder umgangen wird. [S1][S4].
F5 weist CVSS v3.1 8.1 (Hoch) die Angriffskomplexität „Hoch“ zu, während nginx.org die Empfehlung als „Mittel“ [S1][S2][S4] bezeichnet. Da es sich hierbei um separate veröffentlichte Bewertungssysteme handelt, präsentiert FixVibe beide mit Namensnennung, anstatt beide Bezeichnungen als universell zu behandeln.
Wie FixVibe es abdeckt
FixVibe GitHub-Repository-Scans melden ein wahrscheinliches Problem mit mittlerer Sicherheit, wenn im Repository sichtbare Beweise eine genau betroffene Version des offiziellen NGINX Open Source-Container-Images mit der ungewöhnlichen Upstream-Proxy-Konfiguration verknüpfen, die vom Anbieter [S1][S4] beschrieben wird. Das Ergebnis identifiziert die relevanten Image-/Versions- und Konfigurationsspeicherorte, bietet Anleitungen für feste Versionen und unterscheidet verifizierte Repository-Beweise vom nicht verifizierten Laufzeitstatus.
Die Berichterstattung ist bewusst konservativ. Der Schwerpunkt liegt derzeit auf Dockerfile-basierten Komponenten, die das offizielle NGINX Open Source-Image und die vom Repository bereitgestellte Konfiguration verwenden. Es besteht kein Anspruch auf Abdeckung für NGINX Plus, Distributionspakete, benutzerdefinierte oder private Images, Floating-Version-Tags, außerhalb des Repositorys zusammengestellte Konfigurationen oder die bereitgestellte Laufzeit. Ein Befund beweist nicht, dass das Artefakt bereitgestellt, erreichbar oder ausnutzbar ist, und kein Befund ist keine Garantie dafür, dass jede Laufzeit unberührt bleibt.
FixVibe führt kein NGINX aus, sendet keinen gefährlichen Header-Verkehr, führt keine Absturztests durch, überprüft ASLR nicht und versucht keine Speicherbeschädigung oder Codeausführung. Die Bestätigung dieser Verhaltensweisen würde eine sichere Scan-Grenze überschreiten.
Sanierung
Upgrade auf eine feste, unterstützte Version. Verwenden Sie für NGINX Open Source 1.30.3 oder 1.31.2 oder eine neuere unterstützte Version; NGINX Plus-Benutzer sollten den entsprechenden von F5 unterstützten Patch-Level [S1][S2][S3][S4] anwenden. Fixieren Sie die korrigierte Image-Version, erstellen Sie sie neu und stellen Sie alle betroffenen Komponenten erneut bereit.
Überprüfen Sie auch die vollständige effektive Konfiguration. Lassen Sie die Validierung ungültiger Header aktiviert, vermeiden Sie übergroße Client-Header-Puffereinstellungen, es sei denn, sie sind betriebsbedingt erforderlich, und verwenden Sie Upstream-HTTP/2- oder gRPC-Proxy nicht mehr, wenn dies nicht erforderlich ist. Überprüfen Sie die laufende Version mit nginx -v, überprüfen Sie die effektive Konfiguration mit nginx -T, führen Sie nginx -t aus und führen Sie nur harmlose HTTP/2- und gRPC-Rauchtests durch, bevor Sie den FixVibe-Repository-Scan erneut ausführen. Validieren Sie den Fix nicht bei absturzverursachendem oder speicherbeschädigendem Datenverkehr.