CVE-2026-85313 — camel-jetty: enableCORS grants credentialed any-origin access

Runnable proof-of-concept reproducer for the Apache Camel vulnerability where setting enableCORS=true on a Jetty endpoint installed Jetty's CrossOriginFilter with its stock defaults — which reflect every origin and allow credentials. An operator who merely asked for CORS obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses. A reflected origin together with Access-Control-Allow-Credentials: true is exactly the credentialed any-origin configuration the Fetch standard refuses to let * express — reflection being the usual way around that rule (CWE-942).

Spring Boot only. This reproducer ships a single Camel Spring Boot module. The flaw is in camel-jetty, which embeds a Jetty HTTP server. Camel Quarkus has no camel-quarkus-jetty extension — Quarkus serves HTTP over Vert.x (platform-http) — so there is no Quarkus counterpart to reproduce. (The companion advisory CVE-2026-85316 covers the same defect class in platform-http-vertx.) 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-jetty 4.22.0 (affected; fixed 4.22.1), Jetty 12.1.11

What it demonstrates

Two Jetty servers run in one process: the vulnerable endpoint /protected (port 8081) is declared with enableCORS=true, and a verifier endpoint /exploit/attack (port 8080) plays the attacker's browser. On each call the verifier sends a cross-origin GET to /protected carrying Origin: https://evil.example — an origin the deployment never authorised — and reports the CORS headers that come back.

• Affected: the response reflects Access-Control-Allow-Origin: https://evil.example and returns Access-Control-Allow-Credentials: true — any origin can read credentialed responses.
• Fixed: the origin is still reflected (so CORS keeps working for unauthenticated requests), but Access-Control-Allow-Credentials is no longer sent for an origin the operator did not name.

cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: ACAO reflected + ACAC: true; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85313-jetty-cors-credentials-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: ACAO reflected, ACAC absent; >>> Not exploited

Vulnerability Summary

Property	Value
Component	camel-jetty (JettyHttpComponent, enableCORS)
CWE	CWE-942 (Permissive Cross-domain Policy with Untrusted Domains)
Severity	MEDIUM
Attack vector	A page on any origin issues a credentialed cross-origin request to an endpoint configured only with enableCORS=true
Impact	The endpoint reflects the attacker's origin and grants credentials, so the attacker page can read authenticated responses
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-24450
Credit	Claude Security Scan Tool

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

The fix

JettyHttpComponent now applies its own CORS defaults when enableCORS is set: allowCredentials defaults to false unless the operator configures it explicitly. Origin reflection is left untouched, so enabling CORS keeps working for requests that carry no credentials; an operator who needs credentialed cross-origin requests sets filterInit.allowCredentials=true and is expected to name the origins in filterInit.allowedOrigins (and is warned if they do not).

Mitigation if you cannot upgrade

Configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs — name the allowed origins in filterInit.allowedOrigins and leave filterInit.allowCredentials off unless you have named them.

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 "attacker" origin is a benign placeholder (https://evil.example) and both the endpoint and the probe run inside the reproducer. Do not use this material against systems you do not own or operate.