CVE-2026-53717
ŚrednieCVSS 6.5Streszczenie
Envoy Gateway przed wersjami 1.7.4 i 1.8.1 ma podatność w wewnętrznym module imagefetcher, który pobiera obrazy Wasm na podstawie kontrolowanych przez dzierżawcę adresów URL. Podczas wyodrębniania binarnego pliku Wasm, niezweryfikowana wartość rozmiaru w nagłówku tar może prowadzić do ogromnej alokacji pamięci, co może spowodować nieodwracalny błąd braku pamięci w Go i zapętlenie się kontrolera.
Ocena ryzyka
Pojedyncze żądanie może doprowadzić do wyczerpania pamięci i awarii współdzielonego kontrolera, co skutkuje odmową usługi na poziomie całego klastra, bez konieczności dużej liczby żądań.
Rekomendacja
Zaktualizuj Envoy Gateway do wersji 1.7.4 lub 1.8.1. Dodatkowo ogranicz dostęp do rejestrów OCI i rozważ walidację rozmiarów wpisów w archiwach tar.
Inne podatności w Envoy Gateway
Zobacz wszystkie- CVE-2026-53719Średnie
Envoy Gateway przed wersjami 1.7.4 i 1.8.1 zawiera podatność na panikę (nil dereference) w funkcji translateSecurityPolicyForRoute, gdy dzierżawca z ograniczeniem do przestrzeni nazw tworzy SecurityPolicy dla TCPRoute bez spec.authorization. Obiekt trwały wywołuje panikę przy każdym reconcile, co powoduje zatrzymanie publikacji konfiguracji dla całego kontrolera, dopóki administrator nie usunie obiektu.
- CVE-2026-53718Średnie
Envoy Gateway przed wersjami 1.7.4 i 1.8.1 umożliwia HTTPRoute użycie rozszerzonego backendRef do odwołania się do zasobu backendu w innej przestrzeni nazw bez wymaganego ReferenceGrant. Pominięcie walidacji validateBackendNamespace narusza model autoryzacji cross-namespace Gateway API.
- CVE-2026-53716Średnie
Envoy Gateway przed wersjami 1.7.4 i 1.8.1 zawiera podatność na nieograniczoną dekompresję w funkcji getFileFromGZ, gdy tenant kontroluje URL do skompresowanego Wasm payload. Mały plik gzip może wymusić wielogigabajtową alokację pamięci w kontrolerze, prowadząc do jego restartu i potencjalnej trwałej awarii kontrolera.
- CVE-2026-53715Średnie
Envoy Gateway przed wersjami 1.7.4 i 1.8.1 zawiera podatność na wyścig (race condition) w HTTPServer.ServeHTTP, gdzie niesynchronizowany odczyt mapy mappingPath2Cache może kolidować z zapisem, powodując przerwanie procesu kontrolera i prowadząc do czasowej awarii płaszczyzny sterowania.
- CVE-2026-53714Wysokie
Envoy Gateway w trybie GatewayNamespaceMode ma nieuwierzytelniony serwer xDS gRPC — zainstalowany jest tylko JWT StreamInterceptor, bez UnaryInterceptor, a strumieniowy interceptor weryfikuje jedynie komunikaty DeltaDiscoveryRequest. Każdy pod, który może połączyć się z portem 18000, może pobrać klucze prywatne TLS, zasoby xDS, endpointy backendu i konfigurację routingu. Luka została naprawiona w wersjach 1.7.4 i 1.8.1.
- CVE-2026-53713Krytyczne
Envoy Gateway przed wersjami 1.7.4 i 1.8.1 nie zwija nadmiarowych separatorów w to_absolute_normalized_path w pliku internal/gatewayapi/luavalidator/security.lua przed oceną is_critical_path dla Lua przesyłanego przez EnvoyExtensionPolicy podczas domyślnej walidacji Strict. Linux traktuje podwójny ukośnik jako pojedynczy, ale walidator nie dopasowuje tej formy, co pozwala przesłanemu Lua na odczyt dowolnych plików z podu kontrolera gateway. Ujawnione pliki mogą zawierać tokeny konta usługi Kubernetes, certyfikaty TLS i dane środowiskowe procesu, a ujawnione poświadczenia mogą zapewnić dostęp do wrażliwych informacji z Kubernetes API Server lub Gateway xDS server. Luka została naprawiona w wersjach 1.7.4 i 1.8.1.
- CVE-2026-22771Wysokie
Podatność w Envoy Gateway przed wersjami 1.5.7 i 1.6.2 umożliwia wyciek poświadczeń proxy przez skrypty Lua w EnvoyExtensionPolicy. Wycieknięte poświadczenia mogą zostać użyte do komunikacji z płaszczyzną sterowania i uzyskania dostępu do wszystkich sekretów używanych przez proxy, w tym kluczy prywatnych TLS i poświadczeń komunikacji.
Oryginalny opis (angielski, źródło NVD)
Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, internal/wasm/imagefetcher.go follows tenant-controlled EnvoyExtensionPolicy spec.wasm[].code.image.url values to Docker or OCI Wasm layers, and extractWasmPluginBinary uses the untrusted tar-header h.Size value to allocate memory before validating the entry name or declared size. A small PAX or GNU tar header can therefore claim a multi-terabyte entry even though the surrounding LimitReader restricts only the bytes read from the stream, and no registry allowlist prevents a permitted tenant from selecting an attacker-controlled registry that the controller can reach. The allocation is attempted for every tar entry and can cause an unrecoverable Go runtime out-of-memory failure; because the custom resource persists, reconciliation repeatedly crash-loops the shared controller and causes a single-request, non-volumetric, cluster-wide control-plane denial of service. This issue is fixed in versions 1.7.4 and 1.8.1.