Sigstore Fulcio CVE-2026-49478: SSRF, podmiana JWKS i wyciek tokenu K8s

CVE-2026-49478, opublikowane 13 sierpnia 2026 roku, opisuje trzy powiązane błędy w kliencie OIDC projektu Sigstore Fulcio. Wersje do 1.8.5 włącznie mogły podążać za przekierowaniem discovery do innego hosta, zaakceptować podstawiony jwks_uri i wysłać token Kubernetes ServiceAccount do zewnętrznego celu. Fulcio 1.8.6 zamyka wszystkie trzy ścieżki; advisory nie podaje bezpiecznego obejścia i zaleca aktualizację.

Fulcio jest urzędem certyfikacji używanym przez Sigstore do wystawiania krótkotrwałych certyfikatów podpisywania kodu na podstawie tożsamości OIDC. Jego rola czyni błąd szczególnie ciekawym: podatność nie polega na złamaniu algorytmu podpisu. Narusza proces, który ustala, któremu issuerowi i którym kluczom uwierzytelniającym należy ufać. Jeśli discovery zostanie przekierowane, granica zaufania może przesunąć się poza skonfigurowanego hosta.

Advisory GHSA-f5mr-q85p-6hh6 ocenia problem na 8,2 w CVSS 3.1. Wektor zakłada sieć, wysoką złożoność, niskie uprawnienia, brak interakcji i zmianę zakresu. Warunkiem jest złośliwy lub przejęty issuer albo konfiguracja MetaIssuer, która pozwala napastnikowi wpłynąć na docelową ścieżkę discovery. To nie jest anonimowe przejęcie każdej publicznej instancji Fulcio.

Pierwsza luka: blind SSRF przez przekierowanie

Klient OIDC pobiera dokument /.well-known/openid-configuration z adresu issuera. Standardowy klient HTTP może automatycznie podążać za odpowiedzią 3xx. Przed poprawką Fulcio nie blokował przejścia z hosta issuera na inny host. Przejęty issuer mógł więc wskazać adres dostępny tylko z sieci Fulcio: usługę wewnętrzną, endpoint klastra albo panel zarządzający.

Jest to blind SSRF, ponieważ napastnik nie musi zobaczyć pełnej odpowiedzi. Sam fakt wykonania żądania może wywołać skutek lub ujawnić przez różnice czasu, statusu albo dalszego zachowania, że usługa istnieje. Zasięg zależy od egressu poda, DNS, service mesh i sieciowych polityk. Control plane działający w klastrze często widzi więcej niż klient z Internetu.

Poprawka dodaje callback odrzucający przekierowania, które zmieniają host względem pierwotnego issuera. Ważne jest porównanie granicy po każdym redirect, a nie tylko walidacja pierwszego URL. Bez tego bezpieczny adres startowy może prowadzić do prywatnego celu.

Druga luka: podmiana JWKS i zatrucie cache

Dokument discovery wskazuje jwks_uri, z którego klient pobiera publiczne klucze używane do weryfikacji tokenów. Jeżeli napastnik kontrolował wynik przekierowanego discovery, mógł zwrócić URI własnego zestawu kluczy. Fulcio inicjalizował provider i umieszczał verifier w cache. Kolejne tokeny mogły zostać sprawdzone względem klucza atakującego zamiast prawidłowego issuera.

To problem integralności tożsamości, nie wyłącznie SSRF. Zatrucie cache może przetrwać dłużej niż jedno żądanie, zależnie od cyklu życia procesu i wpisu. W systemie wystawiającym certyfikaty podpisywania błędna walidacja OIDC może wpłynąć na to, jaka tożsamość zostanie powiązana z certyfikatem.

Nie należy jednak automatycznie twierdzić, że wszystkie podpisy zostały sfałszowane. Advisory opisuje techniczną możliwość dla określonej konfiguracji issuera. Organizacja musi sprawdzić listę MetaIssuerów, logi inicjalizacji providerów, nietypowe hosty JWKS i certyfikaty wystawione w podejrzanym oknie. Weryfikacja incydentu wymaga dowodów z konkretnej instancji.

Trzecia luka: token Kubernetes trafia do obcego hosta

Fulcio może działać w Kubernetes i używać lokalnego tokenu ServiceAccount podczas discovery względem https://kubernetes.default.svc. Przed poprawką transport dołączał ten bearer token zbyt szeroko. Po przekierowaniu albo przy zewnętrznym jwks_uri token mógł zostać wysłany do innej domeny.

Drugi wariant dotyczył wildcard MetaIssuer typu kubernetes. Jeżeli pasował do zewnętrznego endpointu EKS lub GKE, a konfiguracja zawierała lokalnego issuera Kubernetes, kod mógł załadować lokalny token in-cluster i dołączyć go do żądania wychodzącego. W ten sposób poświadczenie przeznaczone dla lokalnego API serwera przekraczało granicę hosta.

Commit naprawczy ogranicza wstrzykiwanie tokenu do dokładnego hosta skonfigurowanego issuera i ładuje lokalny token tylko dla dokładnego adresu kubernetes.default.svc. To właściwa zasada: poświadczenie powinno być związane z jednym audience i jednym celem, a nie globalnie przyczepiane przez transport HTTP.

Kto powinien reagować najpierw

Najwyższy priorytet mają operatorzy własnych instancji Fulcio do 1.8.5, szczególnie z MetaIssuerami, Kubernetes i możliwością dodawania lub modyfikowania issuerów przez wielu tenantów. Publiczna usługa Sigstore i wdrożenia zarządzane wymagają sprawdzenia komunikatu operatora, ale użytkownik biblioteki lub własnej instancji nie powinien zakładać, że cudza aktualizacja naprawi jego obraz.

Trzeba odróżnić klienta podpisującego od serwera Fulcio. Samo używanie cosign do weryfikacji artefaktów nie oznacza, że organizacja hostuje podatny komponent. Inwentaryzacja powinna znaleźć obraz fulcio, moduł github.com/sigstore/fulcio, deployment, Helm release i konfigurację issuerów.

Ryzyko rośnie, gdy ServiceAccount ma szerokie prawa, pod może łączyć się z całym klastrem, a network policy zezwala na dowolny egress. Token domyślnego konta z minimalnymi prawami ogranicza wpływ, ale jego wyciek nadal narusza poświadczenie i może ujawnić informacje o klastrze.

Plan reakcji

1. Ustal wszystkie instancje Fulcio oraz wersję działającego obrazu i modułu. Wyszukaj release’y Helm, manifesty GitOps i kopie środowiskowe.
2. Zaktualizuj do 1.8.6 lub nowszego i wymień wszystkie pody. Przypnij poprawiony digest, aby autoscaler nie odtworzył starego obrazu.
3. Przejrzyj konfigurację issuerów i MetaIssuerów, zwłaszcza wildcardy typu Kubernetes oraz zewnętrzne hosty EKS/GKE.
4. Ogranicz ServiceAccount do minimalnych praw, wyłącz automatyczny mount tokenu tam, gdzie nie jest potrzebny, i zastosuj tokeny krótkotrwałe z właściwym audience.
5. Ustaw domyślnie blokowany egress; zezwól wyłącznie na zatwierdzone hosty OIDC, JWKS, log transparency i wymagane usługi.
6. Przeszukaj logi proxy, DNS, service mesh i chmury pod kątem discovery, redirectów oraz JWKS na nieznanych hostach.
7. Jeżeli token mógł wyciec, unieważnij go przez wymianę poda i zbadaj działania jego tożsamości w Kubernetes audit log.

Nie wystarczy zrestartować poda przed aktualizacją. Nowy token może zostać ponownie wysłany przez podatny transport. Najpierw wdroż poprawiony obraz lub zablokuj ryzykowny egress, następnie wymień pody i oceń stare poświadczenia. Bound ServiceAccount Token Volume zwykle zapewnia token krótkotrwały, ale w jego okresie ważności napastnik mógł wykonać operacje, które pozostają.

Jak zbadać wpływ na zaufanie do podpisów

Utwórz oś czasu konfiguracji providerów, restartów Fulcio i wpisów w cache. Zbierz logi żądań discovery i JWKS, rekordy DNS, adresy redirectów oraz metadane wystawionych certyfikatów. Szukaj issuerów i subjectów niepasujących do oczekiwanych workflow, nienaturalnego wzrostu certyfikatów oraz kluczy JWKS pobranych z obcych domen.

Jeżeli istnieje wiarygodny okres zatrucia verifiera, określ artefakty podpisane certyfikatami wystawionymi wtedy. Nie usuwaj automatycznie wszystkich podpisów bez analizy, ale nie ufaj wyłącznie poprawnej kryptografii: podpis matematycznie prawidłowy może opierać się na certyfikacie powiązanym z błędnie zweryfikowaną tożsamością. Potrzebna jest korelacja z Rekor, workflow CI, OIDC claims i zatwierdzonym commitem.

Monitoruj również Kubernetes. Audit log powinien wskazać żądania wykonane przez ServiceAccount Fulcio, nietypowe zasoby, nowe tokeny lub sekrety oraz działania poza zwykłym profilem. Jeśli konto mogło odczytać sekrety, zakres rotacji wynika z faktycznych uprawnień i logów, nie z samej nazwy CVE.

Lekcja architektoniczna

OIDC discovery jest aktywnym procesem budowania zaufania. URL, redirect, jwks_uri, cache i token transportu tworzą jeden łańcuch. Walidacja jednego elementu nie wystarczy, jeśli po redirect granica hosta zmienia się bez ponownej decyzji. Poświadczenia HTTP powinny być wiązane z dokładnym celem, a cache zawierać klucz uwzględniający prawidłową tożsamość issuera.

System podpisywania kodu powinien dodatkowo mieć minimalny egress, oddzielną tożsamość workloadu, zewnętrzne logi i alert na nowy host discovery lub JWKS. To ogranicza zarówno znane CVE, jak i błędy przyszłej biblioteki OIDC. Zaufanie do łańcucha dostaw wymaga ochrony mechanizmu wystawiania tożsamości, nie tylko algorytmu podpisu.

Fakty o trzech podatnościach, wersjach i zmianach transportu pochodzą z advisory Fulcio i commitu projektu. Źródła nie potwierdzają masowego wykorzystania. Polityka egressu, analiza certyfikatów i rotacja są rekomendacjami Breachroad. Takie przypadki łączymy z praktyką na szkoleniach cyberbezpieczeństwa dla organizacji, a tożsamości workloadów i pipeline podpisywania można ocenić w ramach audytu bezpieczeństwa chmury.