{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/jwks/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Fulcio (\u003c= 1.8.5)"],"_cs_severities":["high"],"_cs_tags":["supply-chain-security","kubernetes","oidc","ssrf","jwks","cve"],"_cs_type":"advisory","_cs_vendors":["Sigstore"],"content_html":"\u003cp\u003eThree 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker either controls a malicious OIDC issuer or compromises a legitimate one configured for Fulcio.\u003c/li\u003e\n\u003cli\u003eFulcio, during its OIDC discovery process, initiates a request to fetch metadata (\u003ccode\u003e/.well-known/openid-configuration\u003c/code\u003e) from the attacker-controlled OIDC issuer.\u003c/li\u003e\n\u003cli\u003eThe 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 (\u003ccode\u003ehttps://kubernetes.default.svc\u003c/code\u003e), triggering a blind SSRF.\u003c/li\u003e\n\u003cli\u003eSimultaneously, the attacker-controlled issuer can provide a \u003ccode\u003ejwks_uri\u003c/code\u003e in its discovery response that points to an endpoint under the attacker's control.\u003c/li\u003e\n\u003cli\u003eFulcio, following the malicious \u003ccode\u003ejwks_uri\u003c/code\u003e, fetches the attacker's JSON Web Key Set (JWKS) and caches it, effectively poisoning its internal verifier cache.\u003c/li\u003e\n\u003cli\u003eWith 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.\u003c/li\u003e\n\u003cli\u003eDuring 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.\u003c/li\u003e\n\u003cli\u003eThis 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUpgrade immediately\u003c/strong\u003e: Patch affected Sigstore Fulcio instances to version 1.8.6 or newer to address CVE-2026-49478.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMonitor application logs\u003c/strong\u003e: Review application logs for Fulcio's OIDC discovery process for unusual HTTP redirects or fetches from unexpected \u003ccode\u003ejwks_uri\u003c/code\u003e endpoints, although the SSRF is blind and direct detection may be challenging.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReview Kubernetes ServiceAccount usage\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-03T13:03:14Z","date_published":"2026-07-03T13:03:14Z","id":"https://feed.craftedsignal.io/briefs/2026-07-sigstore-fulcio-oidc-ssrf-jwks-cve-2026-49478/","summary":"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.","title":"Sigstore Fulcio Vulnerabilities: OIDC Discovery Redirect Leads to SSRF, JWKS Substitution, and Kubernetes Token Leakage (CVE-2026-49478)","url":"https://feed.craftedsignal.io/briefs/2026-07-sigstore-fulcio-oidc-ssrf-jwks-cve-2026-49478/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Centrifugo v6"],"_cs_severities":["critical"],"_cs_tags":["authentication-bypass","jwt","jwks","centrifugo","web-application"],"_cs_type":"advisory","_cs_vendors":["Centrifugal"],"content_html":"\u003cp\u003eA 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 \u003ccode\u003esingleflight\u003c/code\u003e mechanism, which are keyed solely by the \u003ccode\u003ekid\u003c/code\u003e (key ID) value from a JWT header, rather than a combination of the \u003ccode\u003ekid\u003c/code\u003e and the resolved JWKS endpoint, issuer, or audience. This design oversight means that if an attacker can ensure their issuer's key, sharing a \u003ccode\u003ekid\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Token Acquisition\u003c/strong\u003e: An attacker obtains or mints a valid JWT for an authorized issuer/tenant (e.g., Tenant A) with a specific \u003ccode\u003ekid\u003c/code\u003e value in its header. This JWT is signed by Tenant A's private key.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCache Priming (Tenant A)\u003c/strong\u003e: 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 \u003ccode\u003ekid\u003c/code\u003e. This public key is then stored in Centrifugo's JWKS cache, indexed only by the \u003ccode\u003ekid\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eToken Forgery (Tenant B)\u003c/strong\u003e: 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 \u003cem\u003esame \u003ccode\u003ekid\u003c/code\u003e\u003c/em\u003e value in the header and signs it with \u003cem\u003eTenant A's private key\u003c/em\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eForged Token Presentation\u003c/strong\u003e: The attacker presents this forged Tenant B JWT to the Centrifugo server for authentication (e.g., connection or subscription verification).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerable Cache Lookup\u003c/strong\u003e: Centrifugo attempts to verify the forged Tenant B JWT. When performing the JWKS key lookup, it queries its cache using only the \u003ccode\u003ekid\u003c/code\u003e from the forged token.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCross-Tenant Key Reuse\u003c/strong\u003e: Because the \u003ccode\u003ekid\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Bypass\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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 \u003ccode\u003ekid\u003c/code\u003e 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 \u003ccode\u003eiss\u003c/code\u003e or \u003ccode\u003eaud\u003c/code\u003e claims are used to derive dynamic JWKS URLs.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePatch Centrifugo\u003c/strong\u003e: Immediately apply any available patches or updates from the vendor (Centrifugal) that address this JWKS caching vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReview JWKS Configuration\u003c/strong\u003e: Reconfigure Centrifugo to avoid dynamic JWKS endpoint templates that rely solely on \u003ccode\u003ekid\u003c/code\u003e for key identification across different trust domains, if a patch is not immediately available.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAudit JWKS \u003ccode\u003ekid\u003c/code\u003e Usage\u003c/strong\u003e: Review all JWKS documents for Centrifugo deployments to ensure that \u003ccode\u003ekid\u003c/code\u003e values are unique across all potential issuer/audience configurations, if dynamic JWKS is used.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSegment Multi-Tenant Environments\u003c/strong\u003e: Implement network and logical segmentation between tenants to limit the blast radius in case of a successful authentication bypass.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-03T12:28:16Z","date_published":"2026-07-03T12:28:16Z","id":"https://feed.craftedsignal.io/briefs/2026-07-centrifugo-jwks-auth-bypass/","summary":"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`.","title":"Centrifugo JWKS Cache Authentication Bypass","url":"https://feed.craftedsignal.io/briefs/2026-07-centrifugo-jwks-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Jwks","version":"https://jsonfeed.org/version/1.1"}