Database/Control plane, storage & DevOps

Sigstore Fulcio: OIDC discovery follows cross-host redirects and leaks ServiceAccount tokens
Impact
Fulcio through 1.8.5 follows redirects to other hosts during OIDC discovery and attaches the Kubernetes ServiceAccount token to the redirected request. A malicious or compromised issuer can therefore make Fulcio issue blind SSRF requests from inside the cluster, feed it attacker-controlled JWKS keys that get cached, and receive Fulcio's ServiceAccount token at an external host. Fulcio is the CA that mints code-signing certificates, so poisoned JWKS means signing identities can be forged, and a leaked ServiceAccount token gives an external attacker whatever that identity holds in the cluster - which for a signing service is usually enough to affect what the fleet accepts as a trusted image. For operators whose admission control depends on Sigstore signatures, this undercuts the check that decides which containers land on GPU nodes. The advisory states no workarounds are available.
Who can reach it
Remote and unauthenticated against Fulcio, but it requires an attacker-controlled or compromised OIDC issuer that Fulcio performs discovery against, plus the redirect to be followed - NVD scores attack complexity high. No cluster credentials needed up front.
What to do
Upgrade Fulcio to 1.8.6 and restart the deployment; 1.8.6 blocks cross-host redirects, restricts token injection and restricts local token loading. No workarounds exist, so there is nothing to configure in the meantime beyond limiting the issuer set Fulcio will talk to and egress-filtering the Fulcio pods. Rotate the Fulcio ServiceAccount token after upgrading, and review any certificates issued while an untrusted issuer could have been reached.
References
Related entries
- Loytec L-INX, L-GATE, L-ROC, L-IOB, L-DALI, L-VIS, L-PAD and LIP-ME201C (through 8.4.18, LINX-A64): An out-of-boundsCVE-2026-55732 · Loytec L-INX, L-GATE, L-ROC, L-IOB, L-DALI, L-VIS, L-PAD and LIP-ME201C (through 8.4.18, LINX-A64)High
- Netty: OpenSSL client path silently skips TLS hostname verification on Java 25+CVE-2026-62243 · Netty io.netty:netty-handler (SslProvider.OPENSSL client-side hostname verification)High
- Pure Storage FlashArray Purity (data path information exposure): Insufficient filtering on certain data paths exposesCVE-2026-6445 · Pure Storage FlashArray Purity (data path information exposure)High
- SeaweedFS S3 API: raw OIDC JWT bypasses IAM role trust policy and grants that role's bucket accessCVE-2026-77298 · SeaweedFS S3 API (direct OIDC bearer token to IAM role mapping)High
- OpenNebula: one.vm.exec skips the permission check, letting any user run commands in other tenants' VMsCVE-2026-84165 · OpenNebula (one.vm.exec API authorization)High
- HPE iLO3/4/5: Remote unauthenticated denial of service against the management controllerCVE-2018-7093 · HPE iLO3/4/5High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.