The CVSS 5.8 rating for CVE-2024-10302 significantly understates the actual risk. This is a claim-injection vulnerability in WSO2's self-signup flow where user-controlled strings are accepted into claim tokens without validation. The injection point lives in the self-signup endpoint, but the attack surface extends to every service that consumes those claims as authoritative. If an attacker registers with a forged role, tenant context, or scope permission, they are not exploiting a signup bug—they are rewriting their authorization identity after the fact.
The CVE description states that impact depends on how the compromised data is consumed, which is analytically significant: it signals WSO2 couldn't bound the blast radius themselves. In typical WSO2 deployments, claims carry roles, tenant context, and scope permissions that govern API access across the Control Plane and dependent services.
Your immediate priorities: First, determine exactly which claim fields the patch validates. If it only sanitizes display output, downstream services still receive tokens with attacker-authored payloads. Second, audit every service that consumes WSO2-issued tokens and ask whether it revalidates claims or accepts them as-is—this includes API gateways forwarding tokens to backend microservices. Third, check whether token exchange or claim forwarding exposes these payloads to services outside your WSO2 deployment.
The deeper concern is architectural: WSO2's claim-issuance API accepts arbitrary user strings because that's how the integration flexibility was designed. This is a trust-chain failure, not merely an injection point. Any downstream service that treats WSO2 claims as authoritative is relying on a trust assumption WSO2's API never explicitly validated. Assume attacker-authored claims are already circulating in your environment until you've verified otherwise.