CVE-2026-49478: 
Podman vulnerability analysis and mitigation

CVE-2026-49478 is a set of three chained security vulnerabilities in the OIDC Discovery client of Sigstore Fulcio, a certificate authority used in software supply chain security. The flaws enable Blind Server-Side Request Forgery (SSRF) via cross-host redirect following, JWKS substitution and verifier cache poisoning, and Kubernetes ServiceAccount token leakage. All versions of github.com/sigstore/fulcio up to and including v1.8.5 are affected; the issue was patched in v1.8.6. The vulnerability was originally published on May 26, 2026, and added to the GitHub Advisory Database on June 30, 2026, with a CVSS v3.1 base score of 8.7 (High) (GitHub Advisory, Fulcio Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery), stemming from insufficient validation of HTTP redirects during OIDC discovery metadata fetching (/.well-known/openid-configuration). Three distinct attack surfaces exist: (1) Fulcio's HTTP client followed cross-host redirects by default, allowing a malicious or compromised issuer to redirect discovery requests to internal systems; (2) the permissive redirect behavior enabled an attacker to supply a malicious jwks_uri, poisoning Fulcio's verifier cache with attacker-controlled signing keys; and (3) the Kubernetes ServiceAccount token, used to authenticate requests to the local control plane (https://kubernetes.default.svc), was attached globally by the transport layer and could be leaked to third-party hosts via redirects, or to external EKS/GKE endpoints when a wildcard MetaIssuer of type kubernetes was matched (GitHub Advisory, Fulcio Advisory).

Successful exploitation can result in high confidentiality and integrity impact with a changed scope, affecting components beyond Fulcio itself. An attacker controlling a configured OIDC issuer could probe internal network infrastructure via blind SSRF, forge code-signing certificate issuance by poisoning the JWKS verifier cache with their own keys (allowing signatures validated against attacker-controlled keys), and exfiltrate the Kubernetes ServiceAccount token to gain unauthorized access to the Kubernetes API server. In Kubernetes-deployed environments, token leakage could enable lateral movement within the cluster (GitHub Advisory, Fulcio Advisory).

1. Control or Compromise an OIDC Issuer: Gain control of a domain configured as an OIDC issuer in the target Fulcio deployment, or position yourself as a man-in-the-middle for an existing issuer's discovery endpoint.
2. Serve a Malicious Discovery Document: When Fulcio fetches /.well-known/openid-configuration from the issuer, respond with an HTTP redirect to an internal target (e.g., http://169.254.169.254/ for cloud metadata, or an internal service) to trigger blind SSRF.
3. JWKS Cache Poisoning: Alternatively, serve a discovery document with a jwks_uri pointing to an attacker-controlled host containing attacker-generated public keys. Fulcio will fetch and cache these keys in its verifier cache.
4. Forge Signatures: Present OIDC tokens signed with the attacker's private keys (corresponding to the poisoned JWKS). Fulcio will validate them against the cached attacker keys and issue certificates for attacker-controlled identities.
5. Harvest Kubernetes ServiceAccount Token: If Fulcio is deployed in-cluster and a wildcard MetaIssuer of type kubernetes is configured, trigger a redirect or jwks_uri pointing to an external host. The transport will attach the in-cluster ServiceAccount token to the outbound request, leaking it to the attacker's server.
6. Leverage Token for Cluster Access: Use the harvested ServiceAccount token to authenticate to the Kubernetes API server and perform actions permitted by the token's RBAC bindings (GitHub Advisory, Fulcio Advisory).

• Network: Unexpected outbound HTTP requests from the Fulcio service to internal IP ranges (e.g., RFC 1918 addresses, cloud metadata endpoints like 169.254.169.254) during OIDC discovery; outbound requests to unknown external hosts for JWKS fetching (jwks_uri resolution).
• Network: HTTP requests from Fulcio carrying a Authorization: Bearer <token> header to external or unexpected hosts (indicating ServiceAccount token leakage).
• Logs: Fulcio application logs showing OIDC discovery requests being redirected to unexpected hosts or IP addresses; errors or anomalies in verifier cache initialization.
• Logs: Kubernetes API server audit logs showing authentication attempts using the Fulcio pod's ServiceAccount token from unexpected source IPs or at unusual times.
• File System / Config: Presence of wildcard MetaIssuer entries of type kubernetes in Fulcio configuration that match external endpoints (e.g., EKS/GKE API server URLs) alongside a local Kubernetes issuer.

The vendor has released Fulcio v1.8.6 as the patched version, which applies three mitigations: (1) a custom redirect callback that blocks cross-host redirects during OIDC discovery; (2) restricts ServiceAccount token injection to requests whose host exactly matches the configured issuer host; and (3) constrains local ServiceAccount token loading to requests targeting exactly https://kubernetes.default.svc. There are no workarounds — upgrading to v1.8.6 is the only remediation. Organizations running Fulcio in Kubernetes environments should treat this as high priority due to the potential for cluster credential exposure (GitHub Advisory, Fulcio Advisory).