Improper Tool Argument Header Validation in Apache Camel

This repository is a self-contained Java/Spring Boot proof-of-concept for CVE-2026-49042 in Apache Camel’s camel-langchain4j-tools family. It is a real exploit reproducer, not merely a detector. The core issue is improper input validation: tool-call arguments returned by an LLM are copied directly into Camel Exchange headers without restricting them to the tool’s declared parameter schema. Because LLM output is attacker-steerable via prompt injection, extra JSON fields can become Camel control headers and redirect downstream components. Repository structure is small and focused: Application.java starts the Spring Boot app; VictimRoutes.java defines the vulnerable Camel routes; MockChatModel.java simulates a prompt-injected LLM by returning a malicious tool call; ModelConfig.java registers that mock model; ExploitController.java provides an attacker driver endpoint that triggers exploitation and verifies success; Dockerfile and docker-compose.yml package the demo into a single containerized service. The pom.xml pins Camel 4.18.2, an affected version, and includes camel-platform-http, camel-langchain4j-tools, and camel-exec. Exploit flow: a GET request to /exploit/attack causes the controller to POST attacker-controlled text to the local /chat endpoint. The /chat route wraps the text as a user message and sends it to langchain4j-tools:agent using the mock model. On the first turn, the mock model emits a tool call for get_system_status with legitimate parameter host plus two malicious extra fields: CamelExecCommandExecutable=/bin/sh and CamelExecCommandArgs=-c "id > /tmp/pwned". The vulnerable producer maps all fields into headers. The tool route then invokes exec:echo?args=diagnostic-ok, but the injected CamelExecCommand* headers override the intended command, resulting in shell execution. Success is confirmed by reading /tmp/pwned. Main exploit capability demonstrated is remote code execution through header injection into the Camel exec component. The README also correctly explains that the same primitive can be adapted to SSRF via CamelHttpUri or arbitrary file write via CamelFileName if the downstream tool route uses HTTP or file producers instead. Overall, this is an operational PoC showing end-to-end exploitation of a vulnerable Camel AI-agent integration over HTTP.