CVE-2026-84200

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.

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, silnik polityk zaprojektowany dla Kubernetes, w wersjach przed 1.10.0 pozwalał zasobom zdefiniowanym z polem `deletionTimestamp` na obejście polityk walidacji, generowania lub modyfikacji. Zasoby oczekujące na usunięcie były świadomie zwolnione z przetwarzania, co mogło umożliwić złośliwym użytkownikom manipulację politykami.

Kyverno to silnik polityk zaprojektowany dla Kubernetes. Kontrola seccomp w Kyverno może być obejściem, co dotyczy użytkowników subreguły `validate.podSecurity` w wersjach 1.9.2 i 1.9.3. Problem został naprawiony w wersji 1.9.4.