CVE-2026-78164
Camel HTTP producers: property placeholders were resolved on the message-supplied endpoint-URI override headers, so an unauthenticated sender able to influence those headers could have configuration values and vault secrets expanded into the outbound request and no-argument registry bean methods invoked
Description
The Camel HTTP producer families let an inbound message override the endpoint URI through the CamelHttpUri and CamelRestHttpUri headers, and then passed that message-supplied string through CamelContext.resolvePropertyPlaceholders() before using it. Property-placeholder resolution is a configuration-resolution facility, not a URI-parsing step: it reaches operating-system environment variables, JVM system properties, every PropertiesFunction registered on the classpath - including the AWS, Azure, GCP, HashiCorp, IBM, CyberArk and Kubernetes secret functions - and, through camel-bean, the invocation of a no-argument method on any bean in the registry. Applying it to Exchange content therefore turned a URI string into a configuration- and bean-evaluation context. A route author opted into none of this: a plain static to("http://backend/api") was sufficient. Seven call sites were affected: HttpHelper.createURL and HttpHelper.createMethod in camel-http-common, HttpMethodHelper.createMethod in camel-http, VertxHttpHelper.resolveHttpURI in camel-vertx-http, UndertowHelper.createURL and UndertowHelper.createMethod in camel-undertow, and NettyHttpHelper.createURL in camel-netty-http. The bridgeEndpoint option did not bound the exposure: it suppresses the CamelHttpUri override in the createURL family but not in the createMethod family, so a route using the documented bridging configuration still resolved placeholders taken from the header, and CamelRestHttpUri was consumed before any bridgeEndpoint check in all four components. Only camel-http offered an opt-out, skipControlHeaders, which defaults to false. Reaching the headers did not always require header injection, because several Camel HTTP consumers populate CamelHttpUri from the request line themselves as a documented reverse-proxy feature. An unresolvable placeholder additionally produced a RuntimeExchangeException whose message echoed the URI, which distinguishes a set from an unset configuration key even where no outbound request is made. The behaviour predates the 4.x line; it dates back to the camel-http4 and camel-netty4 components. This advisory continues the alignment CAMEL-24282 applied to the toD and enrich dynamic-URI EIPs in 4.22.0, extending the same build-time-resolution contract to the HTTP producer components.
Mitigation
Credit
This issue was reported by 1428265354@qq.com
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24418 refers to the various commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25571 (commit ba5aced7f6a1c38a963020575676ad4c76b492cf) and backported to camel-4.22.x in https://github.com/apache/camel/pull/26033 (commit 9f8a185e315ce9e120889c4106be3dbf4688e507) and to camel-4.18.x in https://github.com/apache/camel/pull/26034 (commit 7cec534c66969015d85e56631143174dd150ed94).
The fix removes the per-message call to resolvePropertyPlaceholders() at every affected site, so a {{…}} token that appears only in CamelHttpUri or CamelRestHttpUri is now treated as a literal part of the URI. Placeholders written in the route’s own endpoint URI are unaffected: those are resolved once, at build time, when the endpoint is created, which is where the contract documented for toD and enrich in the 4.22 upgrade guide already placed them. Because the value carried by these headers came from the message rather than from route or configuration text, no route that resolves placeholders in the way the project documents is affected by the change; only a route that relied on a placeholder arriving inside a message header needs to resolve that value before it reaches the header.
The camel-4.18.x backport additionally removes a site that does not exist on main: VertxHttpHelper.resolveQueryString() on that branch also resolved placeholders on the CamelHttpUri header value, so a straight cherry-pick would have left the defect reachable on the maintenance line.
The issue is classified as CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine), with the resulting exposure of configuration values corresponding to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). It belongs to the same family as the property-placeholder alignment performed for the dynamic-URI EIPs in CAMEL-24282, and is separate from the Camel header-injection advisories, which concern consumers admitting the Camel namespace from the wire rather than what the framework then does with those values.
Releases before 4.15.0 are affected as well, since the behaviour dates back to the camel-http4 and camel-netty4 components, but those release lines reached end of life before this issue was resolved and no fix will be issued for them.