Apache Camel Keycloak CVE-2026-95663

Exploitation requires the KeycloakSecurityPolicy to be configured with useTokenIntrospection=true and the default introspectionCacheEnabled=true; token introspection is not enabled by default, so default deployments are not affected, and the local JWT verification path (introspection disabled) is explicitly unaffected. The caller must hold an access token that the same Camel process introspected and cached while the token was still active; the reuse window after expiry is bounded by introspectionCacheTtl - 60 seconds by default, or 300-600 seconds where the documentation's internal-services recommendation was followed. Limiting factors: the attacker gains nothing beyond what the token already carried (no forgery, no privilege escalation), the window is short, and the condition depends on a token being cached shortly before its exp - lowering introspectionCacheTtl only narrows but does not close the window.

This is a genuine but low-urgency medium-severity issue, and the available signals are mostly weak or absent rather than conflicting. The vendor CVSS is 4.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N): network-reachable but high attack complexity and only low confidentiality/integrity impact. No EPSS score was supplied, there is no CISA KEV listing, and no SSVC decision was provided - the vuln.today Decision label is 'awaiting_data', meaning the prioritization inputs are incomplete rather than pointing to high risk. The real-world risk is constrained by three factors the advisory states plainly: token introspection is NOT enabled by default, so the vulnerable code path is only reached under a deliberate non-default configuration (useTokenIntrospection=true); the issue grants no token forgery and no privilege escalation, only a short extension of access a caller already legitimately held; and the exposure window is bounded by introspectionCacheTtl (60 seconds by default, 300-600 seconds if the internal-service recommendation was followed). One signal to verify: the vendor assigns PR:N (unauthenticated), yet the attack inherently requires possessing an access token that was valid moments earlier and was introspected/cached by the same Camel process while active - i.e. a previously-authenticated credential - so in practice this is closer to a privileged/authenticated prerequisite than a true unauthenticated flaw. Overall this is a correctness/hardening fix (RFC 7662 caching violation) rather than an emergency.

A client application or user holds a bearer access token that camel-keycloak introspected and cached as active shortly before the token's exp time passed. Because the cached introspection result is expired only by insertion-time TTL and never bounded by the token's exp, the caller keeps presenting the same now-expired token in the Authorization header and is still admitted with that token's roles for up to introspectionCacheTtl seconds after expiry. No public exploit identified at time of analysis; the GitHub references are the remediation pull requests, not exploit code, and the high attack complexity reflects the narrow timing window in which a near-expiry token must have been cached.