CVE-2026-53714
WysokieCVSS 7.4Streszczenie
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.
Ocena ryzyka
Nieuwierzytelniony pod w klastrze może uzyskać dostęp do kluczy prywatnych TLS i pełnej konfiguracji bramy, co umożliwia podszywanie się, przechwytywanie ruchu i dalszą eskalację w środowisku Kubernetes. Stanowi to krytyczne zagrożenie dla bezpieczeństwa całej infrastruktury.
Rekomendacja
Zaktualizuj Envoy Gateway do wersji 1.7.4 lub 1.8.1 (lub nowszej). Ogranicz dostęp sieciowy do portu 18000 wyłącznie do zaufanych komponentów.
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-53717Średnie
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.
- 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, the xDS gRPC server in GatewayNamespaceMode, configured through provider.kubernetes.deploy.type=GatewayNamespace, installs a JWT StreamInterceptor but no UnaryInterceptor, leaving every unary Fetch RPC unauthenticated. The streaming interceptor also authenticates only discoveryv3.DeltaDiscoveryRequest messages; a discoveryv3.DiscoveryRequest used by the State-of-the-World protocol fails the type assertion and returns success without JWT validation. Any pod that can reach port 18000 can use the unauthenticated unary or State-of-the-World paths to retrieve TLS private keys through StreamSecrets, all xDS resources through StreamAggregatedResources, backend endpoints through StreamClusters or StreamEndpoints, and routing configuration through StreamRoutes or StreamListeners. This issue is fixed in versions 1.7.4 and 1.8.1.