<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Jwks - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/jwks/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 03 Jul 2026 13:03:14 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/jwks/feed.xml" rel="self" type="application/rss+xml"/><item><title>Sigstore Fulcio Vulnerabilities: OIDC Discovery Redirect Leads to SSRF, JWKS Substitution, and Kubernetes Token Leakage (CVE-2026-49478)</title><link>https://feed.craftedsignal.io/briefs/2026-07-sigstore-fulcio-oidc-ssrf-jwks-cve-2026-49478/</link><pubDate>Fri, 03 Jul 2026 13:03:14 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-sigstore-fulcio-oidc-ssrf-jwks-cve-2026-49478/</guid><description>A high-severity vulnerability (CVE-2026-49478) in Sigstore Fulcio's OIDC discovery client allows blind Server-Side Request Forgery (SSRF) via cross-host redirects, facilitates JWKS substitution for cache poisoning, and causes Kubernetes ServiceAccount token leakage to external attackers, potentially compromising supply chain integrity and cluster resources.</description><content:encoded><![CDATA[<p>Three critical security vulnerabilities (CVE-2026-49478) have been identified in the OIDC Discovery client within Sigstore Fulcio versions up to and including 1.8.5. Fulcio, a certificate authority for Sigstore, is crucial for verifying the authenticity of software artifacts in the supply chain. Prior to this fix, Fulcio's OIDC discovery process could be exploited by a malicious or compromised OIDC issuer. This allowed attackers to redirect Fulcio's internal HTTP requests to internal systems, leading to blind Server-Side Request Forgery (SSRF). Furthermore, attackers could poison Fulcio's verifier cache by substituting legitimate JSON Web Key Sets (JWKS) with attacker-controlled ones, enabling the forging of signatures. Compounding these issues, Fulcio's integration with Kubernetes meant ServiceAccount tokens could be leaked to external hosts during OIDC discovery, granting attackers potential access to Kubernetes cluster resources. These flaws severely undermine the integrity and security guarantees provided by Fulcio.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker either controls a malicious OIDC issuer or compromises a legitimate one configured for Fulcio.</li>
<li>Fulcio, during its OIDC discovery process, initiates a request to fetch metadata (<code>/.well-known/openid-configuration</code>) from the attacker-controlled OIDC issuer.</li>
<li>The malicious OIDC issuer responds with an HTTP 3xx redirect to an internal IP address or hostname within Fulcio's network, such as the Kubernetes API server (<code>https://kubernetes.default.svc</code>), triggering a blind SSRF.</li>
<li>Simultaneously, the attacker-controlled issuer can provide a <code>jwks_uri</code> in its discovery response that points to an endpoint under the attacker's control.</li>
<li>Fulcio, following the malicious <code>jwks_uri</code>, fetches the attacker's JSON Web Key Set (JWKS) and caches it, effectively poisoning its internal verifier cache.</li>
<li>With the poisoned cache, the attacker can now forge signatures for software artifacts that Fulcio will validate as legitimate, bypassing critical integrity checks in the supply chain.</li>
<li>During these redirected HTTP requests and JWKS fetches, Fulcio inappropriately attaches its mounted Kubernetes ServiceAccount token to outbound requests directed towards the external, attacker-controlled hosts.</li>
<li>This leakage exposes the Kubernetes ServiceAccount token to the attacker, potentially enabling further reconnaissance, privilege escalation, and direct access to the Kubernetes cluster API and its resources.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The identified vulnerabilities have severe consequences across several domains. The blind SSRF allows attackers to probe and potentially interact with internal network services and infrastructure that would otherwise be inaccessible, potentially revealing sensitive information or enabling further internal attacks. JWKS substitution directly compromises the integrity verification process, allowing attackers to sign and distribute malicious software that appears legitimate, undermining the trust model of Sigstore and supply chain security. Most critically, the leakage of Kubernetes ServiceAccount tokens provides attackers with credentials that can be used to gain unauthorized access to the Kubernetes cluster. This can lead to full cluster compromise, data exfiltration, resource manipulation, and deployment of malicious workloads, affecting a wide range of organizations using Fulcio for artifact signing and verification, particularly those deployed within Kubernetes environments.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li><strong>Upgrade immediately</strong>: Patch affected Sigstore Fulcio instances to version 1.8.6 or newer to address CVE-2026-49478.</li>
<li><strong>Monitor application logs</strong>: Review application logs for Fulcio's OIDC discovery process for unusual HTTP redirects or fetches from unexpected <code>jwks_uri</code> endpoints, although the SSRF is blind and direct detection may be challenging.</li>
<li><strong>Review Kubernetes ServiceAccount usage</strong>: Audit the permissions granted to the Kubernetes ServiceAccounts used by Fulcio to ensure they adhere to the principle of least privilege, minimizing the impact of potential token leakage as described in CVE-2026-49478.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>supply-chain-security</category><category>kubernetes</category><category>oidc</category><category>ssrf</category><category>jwks</category><category>cve</category></item><item><title>Centrifugo JWKS Cache Authentication Bypass</title><link>https://feed.craftedsignal.io/briefs/2026-07-centrifugo-jwks-auth-bypass/</link><pubDate>Fri, 03 Jul 2026 12:28:16 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-centrifugo-jwks-auth-bypass/</guid><description>A critical authentication bypass vulnerability exists in Centrifugo v6's dynamic JWKS endpoint feature, allowing an attacker to bypass JWT authentication for one tenant by leveraging a valid token from another tenant due to incorrect JWKS key caching indexed only by the `kid`.</description><content:encoded><![CDATA[<p>A severe authentication bypass vulnerability affects Centrifugo v6, a real-time messaging server, specifically within its dynamic JSON Web Key Set (JWKS) endpoint feature. This flaw, not yet assigned a CVE, enables an attacker to gain unauthorized access to one tenant's resources by exploiting a valid token from a separate, distinct tenant. The vulnerability stems from Centrifugo's JWKS key cache and <code>singleflight</code> mechanism, which are keyed solely by the <code>kid</code> (key ID) value from a JWT header, rather than a combination of the <code>kid</code> and the resolved JWKS endpoint, issuer, or audience. This design oversight means that if an attacker can ensure their issuer's key, sharing a <code>kid</code> with another target tenant, is cached first, they can forge JWTs for users within the target tenant. This leads to unauthorized connection and subscription token acceptance, posing a significant risk to multi-tenant Centrifugo deployments using dynamic JWKS configurations.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Token Acquisition</strong>: An attacker obtains or mints a valid JWT for an authorized issuer/tenant (e.g., Tenant A) with a specific <code>kid</code> value in its header. This JWT is signed by Tenant A's private key.</li>
<li><strong>Cache Priming (Tenant A)</strong>: The attacker presents Tenant A's valid JWT to the Centrifugo server, triggering the dynamic JWKS endpoint to fetch Tenant A's public key corresponding to the JWT's <code>kid</code>. This public key is then stored in Centrifugo's JWKS cache, indexed only by the <code>kid</code>.</li>
<li><strong>Token Forgery (Tenant B)</strong>: The attacker crafts a new JWT, claiming to be a user in a different target issuer/tenant (e.g., Tenant B), but importantly, uses the <em>same <code>kid</code></em> value in the header and signs it with <em>Tenant A's private key</em>.</li>
<li><strong>Forged Token Presentation</strong>: The attacker presents this forged Tenant B JWT to the Centrifugo server for authentication (e.g., connection or subscription verification).</li>
<li><strong>Vulnerable Cache Lookup</strong>: Centrifugo attempts to verify the forged Tenant B JWT. When performing the JWKS key lookup, it queries its cache using only the <code>kid</code> from the forged token.</li>
<li><strong>Cross-Tenant Key Reuse</strong>: Because the <code>kid</code> matches the key previously cached for Tenant A, Centrifugo retrieves and uses Tenant A's public key (instead of Tenant B's intended key) to verify the forged Tenant B token.</li>
<li><strong>Authentication Bypass</strong>: Since the forged token was signed by Tenant A's private key and verified by Tenant A's public key (due to the cache hit), the verification succeeds, granting the attacker unauthorized access as the claimed user in Tenant B.</li>
<li><strong>Impact</strong>: The attacker achieves unauthorized connection or subscription to Tenant B's services, leading to data exposure, unauthorized actions, and compromise of integrity or confidentiality within the target tenant.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>This vulnerability results in a cross-issuer/cross-tenant JWT authentication bypass in Centrifugo deployments configured to use dynamic JWKS endpoints. The primary impact is unauthorized access, allowing an attacker who can acquire or forge a token for one tenant to impersonate users in another tenant if both share a <code>kid</code> value and the attacker's key is cached first. This directly compromises the integrity of connection and subscription token verification. Consequences include unauthorized user authentication within a different namespace and potential cross-tenant confidentiality and integrity breaches, as the server incorrectly trusts tokens across isolated trust domains, particularly in multi-tenant environments where <code>iss</code> or <code>aud</code> claims are used to derive dynamic JWKS URLs.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li><strong>Patch Centrifugo</strong>: Immediately apply any available patches or updates from the vendor (Centrifugal) that address this JWKS caching vulnerability.</li>
<li><strong>Review JWKS Configuration</strong>: Reconfigure Centrifugo to avoid dynamic JWKS endpoint templates that rely solely on <code>kid</code> for key identification across different trust domains, if a patch is not immediately available.</li>
<li><strong>Audit JWKS <code>kid</code> Usage</strong>: Review all JWKS documents for Centrifugo deployments to ensure that <code>kid</code> values are unique across all potential issuer/audience configurations, if dynamic JWKS is used.</li>
<li><strong>Segment Multi-Tenant Environments</strong>: Implement network and logical segmentation between tenants to limit the blast radius in case of a successful authentication bypass.</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>authentication-bypass</category><category>jwt</category><category>jwks</category><category>centrifugo</category><category>web-application</category></item></channel></rss>