In Apache Camel, a manipulated AI reply can quietly redirect what the server does next

Apache Camel's connectors for AI tool-calling do something that looks harmless and turns out to be dangerous: they take the reply an AI model sends back, and copy every field in it straight into the message's internal control headers. There is no check that those fields match the parameters the tool actually declared. So if an attacker can influence what the model says, through a prompt injection, they can plant Camel's own control headers on the message and change what the route does next. On the wrong route, that reaches remote code execution.

The flaw is tracked as CVE-2026-49042, reported by Yu Bao of PayPal. Apache rates it medium severity and published no CVSS vector. That rating undersells the worst case, and the reason is worth understanding, because it is a pattern we keep seeing across agentic AI software: the model's output is being trusted as if it were the developer's own configuration.

What actually breaks

Camel routes pass a message, called an Exchange, from one step to the next. Headers on that Exchange are how steps tell each other what to do: CamelHttpUri sets the URL an HTTP call goes to, CamelFileName sets the file a write lands in, CamelExecCommandExecutable sets the program the exec step runs. When you wire an AI model into a route with camel-langchain4j-tools, camel-langchain4j-agent, or camel-spring-ai-tools, the model calls a tool by returning a small JSON object of arguments. The producer takes the field names in that JSON and sets them as Exchange headers.

The bug is that it sets all of them, not only the ones the tool declared. A tool that declares a single city parameter should only ever produce a city header. Instead, a model that also returns a CamelExecCommandExecutable field gets that written as a header too. The declared-parameter schema, which should be the allowlist, is ignored. A public proof-of-concept from a Camel maintainer walks through exactly this, using the injected headers to hijack the exec: step and run a command as the container process.

Why medium severity undersells it on some routes

Here is the part the severity number hides: the blast radius of this bug is set by your route, not by the CVE. The injected headers do nothing on their own. They matter only when a downstream step reads them. Put an exec producer after the tool call and the ceiling is remote code execution. Put an HTTP producer there and you get server-side request forgery, a way to make the server call attacker-chosen internal URLs. Put a file producer there and you get arbitrary file writes. Same bug, three different worst cases, decided entirely by what you built downstream.

So the honest way to triage this is not that it is a medium and can wait. It is to go look at every route where an AI tool call feeds a producer that acts on headers, and rank those by how dangerous the sink is. A route that ends in exec is your first patch, today.

The AI model is now an untrusted input

This is the same class of mistake as the older Camel header-injection bug that reached command execution through crafted HTTP headers, but with a softer entry point. That one needed an attacker who could shape a request. This one needs only a prompt injection, and prompt injection is a boundary that agentic systems cross constantly: any content the model reads, a support ticket, a web page, a document, a database row, can carry the instructions that steer its next tool call.

We have watched this same trust boundary fail elsewhere. The first AI-run ransomware hinged on an agent doing what its inputs told it to. Docker's AI agent tooling gave up root to a rigged image. And Camel's own Solr routes were reachable through header injection a few days ago. The lesson repeats: a model's output is untrusted input, and any framework that maps it onto a control plane needs an allowlist, not a passthrough.

Patch, then hunt the headers that should not be there

Upgrade to Apache Camel 4.21.0. If you are on the 4.18.x maintenance line, upgrade to 4.18.3. The fix does the obvious right thing: it checks each field name the model returns against the parameters the tool actually declared, keeps only the matches as headers, and logs the rest at WARN before discarding them.

If you cannot patch immediately, strip the internal headers right after the tool endpoint with removeHeaders('Camel*') and removeHeaders('camel*'), and declare an explicit parameter schema for every tool so the model's arguments are constrained by name.

The fix also hands you free detection. Those WARN lines, undeclared tool-argument fields being skipped, are a signal that something tried to set a header it had no business setting. After you patch, alert on them: a burst of dropped Camel* fields on a tool route is a prompt-injection attempt hitting the allowlist. On unpatched hosts, watch your exec steps for executables that were never supposed to run, and your outbound calls for URLs your routes never target. No in-the-wild exploitation has been reported yet, but a working proof-of-concept is public, so the window to get ahead of it is now.