CVE-2026-100703

Kyverno w wersjach przed 1.19.1 zawiera lukę pozwalającą na obejście izolacji przestrzeni nazw w wpisie kontekstu apiCall dla zasobów Policy z ograniczeniem do namespace. Wynika to z niespójnej interpretacji ścieżek między walidacją a wykonaniem. Użytkownik o niskich uprawnieniach może użyć procentowo zakodowanych segmentów kropek w urlPath, aby ominąć sprawdzanie przestrzeni nazw i odczytać zasoby z innych namespace przy użyciu poświadczeń ServiceAccount kontrolera Kyverno.

Kyverno to silnik polityk dla Kubernetes. W wersjach od 1.14.0 do 1.19.0 evaluator ImageValidatingPolicy nigdy nie odczytuje pól spec.images i spec.allowedValues z PolicyException. Każdy PolicyException, którego policyRefs i matchConditions pasują do zasobu, powoduje pominięcie weryfikacji podpisu obrazu dla całego zasobu, a nie tylko dla wymienionych obrazów lub wartości. W rezultacie niepodpisane lub niezaufane obrazy mogą być dopuszczone do klastra bez weryfikacji podpisu. Różni się to od ValidatingPolicy, GeneratingPolicy i MutatingPolicy, które traktują to samo pole jako częściowe wyłączenie. Problem naprawiono w wersji 1.19.1.

Kyverno przed wersją 1.19.1 nieprawidłowo waliduje zakodowane w URL segmenty ścieżki w apiCall urlPath polityki, co pozwala tenantom namespace'ów ominąć ograniczenia per-namespace i tworzyć obiekty w innych namespace'ach jako ServiceAccount kontrolera admission. Atakujący mogą wykorzystać percent-encoded sekwencje traversal katalogów do tworzenia obiektów MutatingWebhookConfiguration w całym klastrze lub obiektów PolicyException w namespace kyverno, co umożliwia eskalację uprawnień do administratora klastra.

W Kyverno w wersjach od v1.9.0 do v1.12.7 występuje błąd w obsłudze wyjątków polityk. Gdy polityka w trybie enforce jest połączona z dwoma wyjątkami PolicyExceptions, mniej restrykcyjny wyjątek ma pierwszeństwo, co pozwala atakującemu ominąć politykę poprzez stworzenie nazwy zasobu pasującej do wzorca drugiego wyjątku (np. '*ingress*'). Można to wykorzystać do obejścia polityk takich jak blokowanie wolumenów hostPath. Poprawiono w v1.13.0.

Kyverno, silnik polityk dla platform cloud native, w wersjach od 1.18.0 do 1.18.2, w kompilatorze CEL NamespacedMutatingPolicy udostępnia bibliotekę generatora dla matchConditions, co pozwala polityce o zasięgu przestrzeni nazw na wywołanie generator.apply(namespace, resources) z dowolną docelową przestrzenią nazw. Walidacja w pkg/cel/policies/mpol/validate.go sprawdza, czy polityka się kompiluje, ale nie egzekwuje zakresu przestrzeni nazw, a GenerateResources w pkg/cel/libs/context.go nie odrzuca celu między przestrzeniami nazw. Użytkownik, który może tworzyć obiekty NamespacedMutatingPolicy w jednej przestrzeni nazw, może spowodować, że kontroler przyjęcia, działający z uprawnieniami całego klastra, utworzy ConfigMaps, NetworkPolicies, Secrets, RoleBindings i inne zasoby w innej przestrzeni nazw, umożliwiając nieautoryzowaną modyfikację i potencjalną eskalację uprawnień. Problem został naprawiony w wersji 1.18.2.

Kyverno przed wersją 1.16.2 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji APICall. Pole URL w konfiguracji ServiceCall w polityce nie jest walidowane, więc użytkownik z uprawnieniami do tworzenia polityk na poziomie przestrzeni nazw może skierować Kyverno do wysyłania żądań HTTP do dowolnych zasobów wewnętrznych (np. punktów metadanych chmury takich jak 169.254.169.254 lub zasobów innych dzierżawców). Ponieważ Kyverno wykonuje te żądania przy użyciu swojego konta usługi o wysokich uprawnieniach w całym klastrze (problem Confused Deputy), odpowiedzi – potencjalnie zawierające sekrety innych dzierżawców i poświadczenia IAM chmury – są zwracane w PolicyReport i mogą być odczytane przez atakującego, co łamie izolację wielodostępową.

Kyverno przed wersją 1.18.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w apiCall.service.url, która umożliwia uwierzytelnionym użytkownikom wysyłanie dowolnych żądań HTTP poprzez wstrzykiwanie danych kontrolowanych przez użytkownika przez podstawianie zmiennych. Atakujący mogą celować w usługi wewnętrzne, punkty metadanych chmury i adresy loopback, a dane odpowiedzi są odzwierciedlane w komunikatach błędów przyjęcia, co umożliwia nieślepą eksfiltrację danych.

Kyverno przed wersją 1.16.4 automatycznie dołącza token konta usługi kontrolera przyjęć do wychodzących żądań HTTP w trybie usługi apiCall bez jawnych nagłówków autoryzacji. Atakujący mogą eksfiltrować token, kierując żądania apiCall do zewnętrznych lub kontrolowanych przez atakującego punktów końcowych, uzyskując pełną kontrolę nad politykami Kyverno i zasobami klastra.

Kyverno przed wersją v1.13.4 jest podatny na podrabianie żądań po stronie serwera (SSRF) przez funkcję Service Call. Atakujący z uprawnieniami do tworzenia polityk Kyverno (Cluster)Policies może określić zewnętrzny URL w konfiguracji apiCall/service w polityce; chociaż Service Call jest udokumentowany dla usług w klastrze, rozwiązuje również adresy zewnętrzne, umożliwiając wysyłanie żądań do serwera kontrolowanego przez atakującego. Ponieważ dane kontekstu polityki (w tym zawartość zasobów Kubernetes, takich jak sekrety) są wysyłane w tych żądaniach, atakujący może eksfiltrować wrażliwe dane klastra.

Kyverno w wersjach 1.9.4 i wcześniejszych obsługuje niebezpieczne zestawy szyfrów 3DES (TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA i TLS_RSA_WITH_3DES_EDE_CBC_SHA) na swoich punktach końcowych TLS. Te 64-bitowe szyfry blokowe są podatne na atak Sweet32 (CVE-2016-2183), który przy bardzo długotrwałych połączeniach TLS przesyłających duże ilości danych może pozwolić atakującemu na odzyskanie niewielkich fragmentów tekstu jawnego. Problem został naprawiony w Kyverno 1.9.5 i 1.10.0.