camel-coap Header Injection → RCE Self-Contained Reproducer (CVE-2026-33453)
by oscerd (Andrea Cosentino) · 2026-07-06
- Severity
- Critical
- CVE
- CVE-2026-33453
- Category
- web
- Affected product
- Apache Camel camel-coap component (org.apache.camel.coap.CamelCoapResource), routes forwarding to camel-exec
- Affected versions
- From 4.14.0 before 4.14.6, and from 4.15.0 before 4.18.1
- Disclosed
- 2026-07-06
- Patch status
- unpatched
Tags
References
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-06 |
| Last Updated | 2026-07-06 |
| Author / Researcher | oscerd (Andrea Cosentino) |
| CVE / Advisory | CVE-2026-33453 |
| Category | web |
| Severity | Critical |
| CVSS Score | 9.8 (per Apache Camel security advisory) |
| Status | Patched |
| Tags | apache-camel, camel-coap, coap, header-injection, rce, cwe-915, camel-exec, unauthenticated, udp, spring-boot |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | Apache Camel camel-coap component (org.apache.camel.coap.CamelCoapResource), routes forwarding to camel-exec |
| Versions Affected | From 4.14.0 before 4.14.6, and from 4.15.0 before 4.18.1 |
| Language / Platform | Java 17+, Spring Boot, Apache Camel |
| Authentication Required | No |
| Network Access Required | Yes (single unauthenticated CoAP/UDP datagram to port 5683) |
Summary
Apache Camel’s camel-coap component copies CoAP request URI query parameters directly into Camel Exchange headers inside CamelCoapResource.handleRequest(), without applying any HeaderFilterStrategy. Because CoAPEndpoint extends DefaultEndpoint (not DefaultHeaderFilterStrategyEndpoint) and CoAPComponent does not implement HeaderFilterStrategyComponent, internal Camel*-prefixed control headers can be injected by any unauthenticated CoAP client simply by adding query parameters to the request URI. When the route forwards to a header-sensitive producer such as camel-exec, an attacker-controlled CamelExecCommandExecutable/CamelExecCommandArgs header overrides the configured command, giving unauthenticated remote code execution from a single UDP datagram. This is a self-contained Spring Boot reproducer bundling both the vulnerable victim route (coap://.../run → exec:echo) and an attacker CoAP client, so no external target or Docker container is required to reproduce the bug.
Vulnerability Details
Root Cause
| |
CoAP is UDP-based (RFC 7252) with no built-in authentication (DTLS is optional and disabled by default), so any client able to reach the port can set arbitrary headers on the Exchange.
Attack Vector
- A Camel route consumes from
coap://0.0.0.0:5683/runand forwards toexec:echo?args=hello(a fixed, harmless command in the victim configuration). - The attacker sends a single CoAP UDP datagram to
coap://target:5683/runwith query parametersCamelExecCommandExecutable=/usr/bin/touch&CamelExecCommandArgs=/tmp/pwned. CamelCoapResource.handleRequest()copies both query parameters into Exchange headers with no filtering.camel-exechonors the injectedCamelExecCommandExecutable/CamelExecCommandArgsheaders by default, overriding the route’s configured command and executing the attacker’s command instead.- Command stdout is written back into the Exchange body and returned directly in the CoAP response.
Impact
Unauthenticated remote code execution from a single UDP packet, with command output returned in-band via the CoAP response — no callback/exfiltration channel required. The same header-injection primitive also reaches other header-sensitive producers (camel-file → CamelFileName path traversal/arbitrary write, camel-bean → CamelBeanMethodName method-invocation control, camel-sql, templating components).
Environment / Lab Setup
Target: Spring Boot app with a Camel route: coap://0.0.0.0:5683/run -> exec:echo?args=hello
Attacker: bundled CoAP client (ExploitController REST endpoints) or any raw CoAP client (e.g. libcoap's coap-client)
No Docker container or external service is required — the reproducer app is both the vulnerable CoAP server and the attacker client.
Proof of Concept
PoC Application
See
pom.xmlandsrc/main/java/com/example/in this folder —CoapExecRoutedefines the vulnerable victim route,ExploitControllerbundles a CoAP attacker client exposed via/exploit/normaland/exploit/attack.
| |
Detection & Indicators of Compromise
Signs of compromise:
- CoAP/UDP traffic to Camel-hosted CoAP endpoints carrying unexpected
Camel*-prefixed query parameters - The Camel application process spawning shell children not matching the route’s configured
execcommand - Unexpected file writes/reads on hosts running
camel-filebehind CoAP-sourced routes
Remediation
| Action | Detail |
|---|---|
| Primary fix | Upgrade camel-coap to 4.14.6, 4.18.1, or 4.19.0 (CAMEL-23222), which gives CoAPEndpoint a HeaderFilterStrategy and applies it in handleRequest() so Camel*-prefixed headers are filtered on the CoAP boundary |
| Interim mitigation | Add .removeHeaders("Camel*") immediately after from("coap:..."); avoid placing header-sensitive producers (camel-exec, camel-file, camel-bean, camel-sql) downstream of untrusted CoAP input; enable DTLS (coaps://) with client authentication; keep the CoAP port on a trusted network |
References
Notes
Mirrored from https://github.com/oscerd/CVE-2026-33453 on 2026-07-06. A separate, independently-authored PoC for the same CVE already exists in this archive at pocs/web/2026-07-05_cve-2026-33453-apache-camel-coap-header-injection-rce/ (source: dinosn, a Python exploit against a Dockerized target); this entry is kept distinct as it is a different, self-contained Spring Boot reproducer bundling both the vulnerable route and the attacker client, from the same maintainer who patched the underlying Apache Camel bug.