## https://sploitus.com/exploit?id=182DFC3E-40F4-55DA-A065-90986AD4F39C
# CVE-2026-63621 — camel-knative structured CloudEvent header injection
Runnable proof-of-concept reproducers for the same Apache Camel vulnerability, one per runtime:
| Runtime | Directory | Stack | Style |
|---------|-----------|-------|-------|
| **Camel Spring Boot** | [`camel-spring-boot/`](camel-spring-boot/) | Spring Boot 3.5.13 + camel-knative **4.18.2** | direct decode (see note) |
| **Camel Quarkus** | [`camel-quarkus/`](camel-quarkus/) | Quarkus 3.36.0 + Camel Quarkus 3.36.0 (bundles Camel **4.20.0**) | full HTTP-driven knative source |
Both are **affected** versions (the issue is fixed in 4.14.9 / 4.18.4 / 4.22.0), and both demonstrate the identical
defect: the camel-knative consumer accepts CloudEvents in two content modes. In **binary** mode the attributes
arrive as HTTP headers and are mapped through a `HeaderFilterStrategy`, so `Camel*` headers are dropped. In
**structured** mode (`Content-Type: application/cloudevents+json`) the whole event is a JSON body, and the affected
build maps every extension field of that JSON onto the message headers with
`setHeader(key.toLowerCase(Locale.US), value)` and **no** `HeaderFilterStrategy`. Extension names are chosen by the
sender, so an attacker can set a Camel-internal control header. Here the injected extension `camelsqlquery` becomes
the `CamelSqlQuery` header (Camel headers are case-insensitive) — the statement a camel-sql producer would execute
(header injection → CWE-74).
> **Note on the Spring Boot variant.** The knative HTTP transport is Vert.x-based and is used in camel-main /
> Camel Quarkus deployments. A Spring Boot servlet application does not host that transport, so the Spring Boot
> reproducer drives the **exact vulnerable decode** (`CloudEventProcessors.fromSpecVersion("1.0").consumer(...)`)
> directly — the same code path an inbound `application/cloudevents+json` request drives inside the knative
> consumer. The Camel Quarkus variant is the full HTTP-driven reproducer (POST a CloudEvent to the live source).
```bash
cd camel-spring-boot # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
```
Expected output on an affected build (both variants):
```
1) Benign structured CloudEvent (no extension):
CamelSqlQuery ... = [null]
2) Malicious structured CloudEvent (injected extension 'camelsqlquery'):
CamelSqlQuery ... = [SELECT * FROM secrets WHERE 1=1 -- injected-by-attacker]
>>> PROVEN: ... a camel-sql producer downstream would execute this attacker-supplied statement: true
```
## Vulnerability Summary
| Property | Value |
|----------|-------|
| **Component** | `camel-knative` (Spring Boot: `camel-knative`; Quarkus: `camel-quarkus-knative`) |
| **CWE** | CWE-20 (Improper Input Validation) → CWE-74 (Injection) |
| **Attack vector** | A structured-mode CloudEvent (`application/cloudevents+json`) with an attacker-chosen extension field |
| **Impact** | Injection of Camel-internal control headers onto the Exchange (here `CamelSqlQuery`) |
| **Affected Versions** | From 3.15.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0 |
| **Fixed Versions** | 4.14.9, 4.18.4, 4.22.0 |
| **JIRA** | [CAMEL-24084](https://issues.apache.org/jira/browse/CAMEL-24084) |
| **Credit** | Andrea Cosentino (Apache Software Foundation) |
Advisory: https://camel.apache.org/security/CVE-2026-63621.html
## The fix
The structured-mode extension mapping now runs each field through a `HeaderFilterStrategy` (a
`DefaultHeaderFilterStrategy`) before setting it, consistent with the binary content-mode path — so `Camel*`
extension names from the untrusted body are dropped:
```java
// fixed (AbstractCloudEventProcessor.mapExtensionAsHeader)
final String headerName = key.toLowerCase(Locale.US);
if (!headerFilterStrategy.applyFilterToExternalHeaders(headerName, value, exchange)) {
message.setHeader(headerName, value);
}
```
## 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 injected value is a
benign marker (an inert SQL string that is never executed here). Do not use this material against systems you do
not own or operate.