CVE-2026-85317 — camel-http: OAuth2 token cache confusion

Runnable proof-of-concept reproducer for the Apache Camel vulnerability where camel-http's OAuth2 client token cache — a JVM-global static map — keyed its entries on only (uri, clientId, clientSecret), omitting the fields that actually shape the token: the requested scope, the resource indicator, and the token endpoint. Two endpoints differing only in those fields therefore shared a cache entry, so an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server — a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for (CWE-524).

Spring Boot only. This reproducer ships a single Camel Spring Boot module. The flaw is in camel-http's OAuth2 client, which also has a camel-quarkus-http extension; but in that extension's JVM packaging the endpoint-level oauth2* client options are not applied the way they are under Spring Boot (the OAuth2 request interceptor that owns the token cache is never wired, so the token endpoint is never called) — the same limitation documented for CVE-2026-85251. The Spring Boot module demonstrates the affected and the fixed behaviour.

Runtime	Directory	Stack
Camel Spring Boot	`camel-spring-boot/`	Spring Boot 3.5.13 + camel-http 4.22.0 (affected; fixed 4.22.1)

What it demonstrates

The driver mirrors the fix's own regression test (HttpOAuth2TokenCachingTest). Two throwaway HTTP servers run inside the process: a token endpoint that mints a bearer token, and a target that requires it. The verifier (/exploit/attack):

makes a first request to the target with oauth2CacheTokens=true&oauth2Scope=read — a token is minted and cached;
shuts the token endpoint down;
makes a second request, identical but for oauth2Scope=read+write.

Affected: the cache key ignores scope, so the second request gets a cache hit and reuses the read token — it succeeds even though the token endpoint is gone (no fresh token could possibly be minted).
Fixed: scope is part of the key, so the second request misses the cache and tries to mint a fresh token; with the token endpoint down it fails to connect (HttpHostConnectException).

cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: 2nd request 200 (reused read token); >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85317-http-oauth2-token-cache-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: 2nd request HttpHostConnectException; >>> Not exploited

Vulnerability Summary

Property	Value
Component	`camel-http` (`OAuth2ClientConfigurer`, token cache)
CWE	CWE-524 (Use of Cache Containing Sensitive Information)
Severity	MEDIUM
Attack vector	A deployment configures more than one OAuth2 endpoint differing only in scope, resource indicator or token endpoint; they share the JVM-global token cache
Impact	An endpoint is served a token minted for a different scope/resource/authorization server — broader authority than configured, or a token presented to the wrong party
Affected Versions	From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1
Fixed Versions	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24456
Credit	Claude Security Scan Tool

Advisory: https://camel.apache.org/security/CVE-2026-85317.html

The fix

OAuth2ClientConfigurer extends the cache key record OAuth2URIAndCredentials to include the token endpoint, scope and resource indicator, so entries are no longer shared between endpoints that differ in any of those fields.

Mitigation if you cannot upgrade

Run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so they do not share the static cache.

Disclaimer

This repository is published for educational and defensive purposes: to help Apache Camel users understand the vulnerability, verify whether they are affected, and confirm that upgrading resolves it. The token (xxx.yyy.zzz), client id and secret are benign placeholders and both HTTP servers run in-process. Do not use this material against systems you do not own or operate.

CVE-2026-85317