CVE-2026-46617
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 12 - wyżej niż 12% wszystkich znanych CVE
Streszczenie
Fission, framework serverless dla Kubernetes, przed wersją 1.23.0, tworzył pody runtime z ServiceAccountName: fission-fetcher, który miał uprawnienia do odczytu sekretów i configmap w całym namespace. Umożliwiało to kodowi funkcji dostarczonemu przez użytkownika dostęp do tokena API Kubernetes, co pozwalało na odczyt dowolnych sekretów i configmap w namespace funkcji.
Ocena ryzyka
Organizacja może być narażona na nieautoryzowany dostęp do wrażliwych danych, co może prowadzić do wycieku informacji lub naruszenia bezpieczeństwa aplikacji. Użytkownicy mogą uzyskać dostęp do danych, które nie powinny być im udostępnione.
Rekomendacja
Zaleca się aktualizację Fission do wersji 1.23.0 lub nowszej, aby usunąć tę podatność. Dodatkowo, warto przeanalizować i ograniczyć uprawnienia ServiceAccount dla funkcji w celu minimalizacji ryzyka.
Inne podatności w Fission framework
Zobacz wszystkie- CVE-2026-50566Krytyczne
Fission to framework serverless, natywny dla Kubernetes, który upraszcza wdrażanie funkcji i aplikacji. W wersjach przed 1.24.0, użytkownik z odpowiednimi uprawnieniami RBAC mógł uruchomić kontenery z podwyższonymi uprawnieniami, co prowadziło do możliwości ucieczki z piaskownicy kontenera oraz dostępu do systemu plików i sieci hosta.
- CVE-2026-49823Wysokie
Fission to framework serverless, natywny dla Kubernetes, który upraszcza wdrażanie funkcji i aplikacji. W wersjach przed 1.24.0 specyfikacja funkcji Fission nie walidowała przestrzeni nazw dla odniesienia do pakietu, co mogło prowadzić do nieautoryzowanego dostępu.
Oryginalny opis (angielski, źródło NVD)
Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests. This issue has been patched in version 1.23.0.