CVE-2026-63621 — camel-knative structured CloudEvent header injection

Runnable proof-of-concept reproducers for the same Apache Camel vulnerability, one per runtime:

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).

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

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:

// 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.