Sigstore Fulcio CVE-2026-49478: SSRF, JWKS substitution and K8s token leakage

CVE-2026-49478, published on 13 August 2026, describes three connected flaws in the OIDC client used by Sigstore Fulcio. Versions through 1.8.5 could follow discovery redirects to another host, accept a substituted jwks_uri, and send a Kubernetes ServiceAccount token to an external destination. Fulcio 1.8.6 closes all three paths. The advisory lists no safe workaround and directs operators to upgrade.

Fulcio is the certificate authority Sigstore uses to issue short-lived code-signing certificates from OIDC identities. That role makes the issue particularly instructive: no signature algorithm was broken. The vulnerable process decided which issuer and verification keys to trust. When discovery crosses a host boundary, the trust decision can silently move away from the configured issuer.

GHSA-f5mr-q85p-6hh6 scores the issue 8.2 under CVSS 3.1. Its vector has network access, high complexity, low privileges, no user interaction and changed scope. A malicious or compromised issuer, or a MetaIssuer configuration that gives an attacker influence over discovery, is required. This is not anonymous takeover of every public Fulcio instance.

First flaw: blind SSRF through redirects

An OIDC client fetches /.well-known/openid-configuration from the issuer. A standard HTTP client may follow a 3xx automatically. Before the fix, Fulcio did not reject a move from the issuer host to another host. A compromised issuer could point discovery toward something visible only from Fulcio’s network: an internal service, cluster endpoint or management plane.

This is blind SSRF because the attacker does not necessarily receive the complete response. Making the request may itself have an effect, while timing, status or later behaviour can reveal whether a service exists. Reach depends on pod egress, DNS, service mesh and network policy. A control plane in a cluster commonly sees more than an Internet client.

The patch adds a redirect callback that rejects host changes relative to the original issuer. The boundary has to be checked after every redirect, not only on the first URL. Otherwise an approved starting address can still lead to a private destination.

Second flaw: JWKS substitution and cache poisoning

The discovery document names a jwks_uri from which the client retrieves public keys for token verification. An attacker controlling redirected discovery could return their own key endpoint. Fulcio initialised the provider and cached its verifier. Later tokens could then be checked against attacker-controlled keys rather than the genuine issuer.

This is an identity-integrity failure, not merely SSRF. A poisoned cache may survive beyond a single request depending on process and cache lifetime. In a certificate issuer, incorrect OIDC verification can affect which identity is bound to a signing certificate.

It does not follow that every signature was forged. The advisory establishes a technical path under specific issuer conditions. Operators need MetaIssuer configuration, provider initialisation logs, unusual JWKS hosts and certificates issued during a suspect window. Incident conclusions require evidence from the deployment.

Third flaw: Kubernetes token sent to another host

Fulcio can run in Kubernetes and use a local ServiceAccount token for discovery against https://kubernetes.default.svc. Before 1.8.6, its transport attached that bearer token too broadly. A redirect or external jwks_uri could cause the credential to be sent to another domain.

Another variant involved wildcard Kubernetes MetaIssuers. If a wildcard matched an external EKS or GKE endpoint while a local Kubernetes issuer existed, code could load the in-cluster token and attach it to the external request. A credential intended for the local API server crossed the host boundary.

The fixing commit limits token injection to an exact issuer-host match and loads the local token only for exact kubernetes.default.svc. That is the correct principle: credentials bind to an audience and destination rather than being attached globally by an HTTP transport.

Who should respond first

Self-hosted Fulcio operators running through 1.8.5 have the highest priority, particularly those using MetaIssuers, Kubernetes and multi-tenant issuer administration. Users of a public Sigstore service or managed deployment should review the operator’s notice, while self-hosters must not assume another party’s rollout fixes their image.

Distinguish the signing client from the Fulcio server. Using cosign to verify artifacts does not mean an organisation hosts the vulnerable component. Inventory should look for a Fulcio image, the github.com/sigstore/fulcio module, deployments, Helm releases and issuer configuration.

Impact increases when the ServiceAccount has broad rights, the pod can reach the whole cluster and network policy permits unrestricted egress. A default account with minimal rights limits blast radius, but token disclosure still compromises a credential and can expose cluster information.

Response plan

1. Find every Fulcio instance and effective image and module version, including Helm releases, GitOps manifests and environment copies.
2. Upgrade to 1.8.6 or later and replace every pod. Pin the fixed digest so autoscaling cannot restore the old image.
3. Review issuer and MetaIssuer configuration, especially Kubernetes wildcards and external EKS or GKE hosts.
4. Reduce ServiceAccount rights, disable token automount where unnecessary, and use short-lived audience-bound tokens.
5. Apply default-deny egress, permitting only approved OIDC, JWKS, transparency-log and required service hosts.
6. Search proxy, DNS, service-mesh and cloud logs for discovery, redirects and JWKS requests to unfamiliar hosts.
7. If a token may have leaked, replace the pod and investigate that identity in Kubernetes audit logs.

Restarting before the update is insufficient. A new token can be disclosed by the same vulnerable transport. Deploy the fixed image or block risky egress, then replace pods and assess the old credential. Bound ServiceAccount Token Volumes normally make tokens short-lived, but actions performed during validity may persist.

Assessing trust in issued signatures

Build a timeline of provider configuration, Fulcio restarts and cache entries. Collect discovery and JWKS requests, DNS records, redirect destinations and certificate metadata. Look for unexpected issuers and subjects, unusual issuance volume and verification keys fetched from external domains.

Where verifier poisoning is plausible, identify artifacts signed with certificates issued in that window. Do not revoke every signature without analysis, but do not rely on valid cryptography alone: a mathematically correct signature can use a certificate bound to an incorrectly verified identity. Correlate Rekor, CI workflows, OIDC claims and approved commits.

Inspect Kubernetes as well. Audit logs should show requests made by Fulcio’s ServiceAccount, unusual resources, new credentials and actions outside its baseline. If the account could read secrets, rotation scope comes from effective permissions and evidence rather than the CVE name alone.

Architectural lesson

OIDC discovery is an active trust-building process. URL, redirect, jwks_uri, cache and transport credentials form one chain. Checking one element is insufficient if a redirect changes the host without a new policy decision. HTTP credentials should bind to an exact destination, while a cache key should preserve the validated issuer identity.

A code-signing service also deserves minimum egress, a dedicated workload identity, external logging and an alert on new discovery or JWKS hosts. These controls contain both this CVE and future OIDC library flaws. Software supply-chain trust depends on protecting identity issuance, not only signature algorithms.

The three flaws, affected versions and transport changes are facts from the Fulcio advisory and commit. The sources do not report mass exploitation. Egress policy, certificate analysis and rotation are Breachroad recommendations. We connect these layers in our cybersecurity training for organisations, while a cloud security assessment can examine workload identity and signing pipelines.