Andrea Cosentino created CAMEL-23496:
----------------------------------------
Summary: Document the Camel security model: user roles, trust
boundaries, in-scope vs. out-of-scope vulnerability classes, and deployment
hardening
Key: CAMEL-23496
URL: https://issues.apache.org/jira/browse/CAMEL-23496
Project: Camel
Issue Type: Improvement
Reporter: Andrea Cosentino
h2. Background
Camel ships 300+ components and is embedded in widely different deployments
(microservices, ESBs, JBang scripts, Quarkus/Spring Boot apps, multi-tenant
gateways). Today the project's only public security artifact is
{{SECURITY.md}}, which is a one-paragraph pointer to
[https://camel.apache.org/security/]. There is no documented trust model or
scope statement.
This causes recurring problems:
* *Triage cost.* Reports arrive describing route authors deliberately enabling
{{allowJavaSerializedObject=true}}, {{trustAllCertificates=true}}, Bean
dispatch on attacker-controlled input, or {{simple}} / {{groovy}} evaluation of
user data. Each requires re-explaining the trust boundary on a per-report
basis. With explicit scope rules a reporter, an automated scanner, or an AI
triage agent can self-sort the report before it reaches the PMC private list.
* *Inconsistent fixes for the same class.* Historically Camel has accepted ~40
advisories. The two dominant clusters - unsafe Java deserialization (14
advisories) and header / bean-dispatch injection (7+ advisories) - keep
recurring in _new_ components because there is no documented rule for
"vulnerable default". CVE-2024-22369 ({{camel-sql}}) triggered four follow-on
CVEs in {{camel-cassandraql}}, {{camel-leveldb}}, {{camel-consul}}, and
{{camel-infinispan}} after the same {{ObjectInputStream}} pattern was found
elsewhere. CVE-2025-27636 / 29891 (HTTP {{HeaderFilterStrategy}}) triggered
follow-ons in {{camel-undertow}}, {{camel-coap}}, {{camel-mail}}, and
{{camel-jms/sjms/google-pubsub}}.
* *No anchor for automated scanning.* Apache Airflow publishes a comparable
document at
[https://github.com/apache/airflow/blob/main/AGENTS.md#security-model] and
[https://github.com/apache/airflow/blob/main/airflow-core/docs/security/security_model.rst].
It lets external tooling (CVE auto-triage, internal vulnerability scanners,
AI-assisted security review) distinguish a real framework vulnerability from a
misuse of an intentionally permissive feature. Camel needs the same.
h2. Proposal
Add two pieces of documentation that reference each other:
# *Canonical document* at
{{docs/user-manual/modules/ROOT/pages/security-model.adoc}} - rendered on
camel.apache.org, linked from the existing {{security.adoc}} page and from
{{SECURITY.md}} at the repo root.
# *Inline summary in {{AGENTS.md}}* - a "Security Model" section that
summarises the rules and links to the canonical doc, mirroring the structure
Airflow uses in its own AGENTS.md.
h2. Document contents
h3. User roles and trust assumptions
* *Camel committers / component developers* - trusted to ship secure defaults.
* *Route authors* - TRUSTED. A route author can execute Java, invoke beans,
evaluate {{simple}} / {{groovy}} / {{jexl}} / {{mvel}} / {{xpath}} against any
input. Code execution by a route author is by design, not a vulnerability.
* *Deployment operators* - TRUSTED. Control configuration, secrets, JVM,
network exposure. Their misconfiguration is not a framework vulnerability
unless Camel's default exposes it.
* *External message senders* (HTTP clients, JMS producers, file droppers, SMTP
senders, CoAP peers, etc.) - UNTRUSTED. This is the primary attacker model.
h3. In-scope vulnerability classes (with historical CVEs as anchors)
* *Unsafe deserialization triggered by untrusted input* - XStream
(CVE-2015-5344), Jetty/Servlet auto-deserialization (CVE-2015-5348), Jackson
polymorphic via header (CVE-2016-8749), SnakeYAML (CVE-2017-3159), Hessian
(CVE-2017-12633), Castor (CVE-2017-12634), RabbitMQ default (CVE-2020-11972),
Netty default (CVE-2020-11973), aggregation repos for SQL / Cassandra / LevelDB
/ Consul / Infinispan (CVE-2024-22369, 23114, 25747, 27172, 2026-40858), PQC
key store (CVE-2026-40048), Mina type converter (CVE-2026-40473), JMS
{{mapJmsMessage}} default (CVE-2026-40860).
* *XXE / XML external entity resolution* - XSLT (CVE-2014-0002), XML converter
(CVE-2015-0263), XPath (CVE-2015-0264), camel-xmljson via json-lib
(CVE-2019-0188), XSD validation (CVE-2018-8027).
* *Expression / template language injection* - {{CamelFileName}}
Simple-language abuse (CVE-2013-4330), Velocity/Freemarker template injection
(CVE-2020-11994).
* *Path traversal* - camel-mail (CVE-2018-8041), camel-file (CVE-2019-0194).
* *SSRF via parser resolution* - Validation component DTD (CVE-2017-5643).
* *Header / bean-dispatch abuse via untrusted input* - HeaderFilterStrategy
bypass family (CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-33453
camel-coap, CVE-2026-33454 camel-mail, CVE-2026-40453 jms/sjms/coap/pubsub).
* *Auth bypass in components implementing AAA* - Keycloak {{iss}} not validated
(CVE-2026-23552), platform-http subpath auth bypass (CVE-2026-40022).
* *Information disclosure* - world-readable temp files (CVE-2023-34442),
EventFactory exposure (CVE-2024-22371).
* *Insecure defaults* - any component shipping with deserialization, TLS-skip,
or admin-exposure enabled out of the box.
* *Injection into back-end queries built by Camel* - Cypher (CVE-2025-66169),
XSLT extension functions (CVE-2014-0003), analogous classes.
h3. Out of scope (intentional design, operator responsibility, or downstream
misuse)
* A route author writing {{.bean()}}, {{.process()}}, {{Runtime.exec()}}, or
evaluating {{simple}} / {{groovy}} on untrusted input. Route code is trusted.
* A route author building an SQL / Cypher / HTTP URI from untrusted input
without parameterising. The route is at fault, not Camel.
* Java deserialization enabled by *explicit opt-in*
({{allowJavaSerializedObject=true}}, {{transferException=true}}, an explicitly
chosen {{ObjectInputStream}}-using data format).
* TLS bypass with explicit {{trustAllCertificates=true}} /
{{hostnameVerificationEnabled=false}}.
* DoS / resource exhaustion through unthrottled routes (operator's
responsibility - {{throttle}}, {{circuitBreaker}}, {{resilience4j}}, JVM
limits).
* A deployer placing the dev console, JMX, Jolokia, or management endpoints on
a public network.
* 3rd-party CVE in a transitive dependency that is not reachable through any
Camel-exposed code path.
* Self-XSS by authenticated users of a Camel-built UI.
* Reports from automated scanners with no PoC demonstrating an actual
trust-boundary breach.
h3. Known limitations
* Some components have heritage-permissive defaults appropriate for trusted
networks (FTP, plain SMTP, JMS Object messages). Where defaults are being
tightened we should reference the related JIRA / CVE.
* Bean-based dispatch via internal headers ({{CamelBeanMethodName}},
{{CamelFileName}}, {{CamelExecCommandExecutable}}, {{CamelJmsDestinationName}},
etc.) means _any_ consumer that maps external input into the Exchange header
map can become an injection vector. Route authors must filter incoming headers
from untrusted producers; component authors must apply a strict
{{HeaderFilterStrategy}} on the inbound path, case-insensitively.
* Aggregation repositories that persist Java objects assume the backing store
is trusted - see the deserialization-class CVEs above.
h3. Deployment hardening (operator section)
* Use the security policy framework from {{proposals/security.adoc}} and set
{{camel.main.profile = prod}} so the default policy is {{fail}}.
* Resolve secrets through one of the supported vaults rather than property
files.
* Configure TLS through the JSSE Utility; never {{trustAllCertificates=true}}
in production.
* Strip Camel-internal headers ({{CamelBeanMethodName}}, {{CamelFileName}},
{{CamelExec*}}, {{CamelJms*}}, etc.) at the boundary using {{removeHeader}} /
{{removeHeaders}} before letting external data reach a dispatching processor.
* Do not expose {{camel-management}}, the dev console, Jolokia, or JMX on a
public network.
* For components that integrate Java deserialization, set an
{{ObjectInputFilter}} or disable the option.
h3. Guidance for committers (PR review section)
* When a {{@UriParam}} controls a security-relevant default, mark it with the
right {{security = "insecure:*"}} category from {{proposals/security.adoc}}.
* Any new component that consumes external input must define a
{{HeaderFilterStrategy}} covering inbound and outbound, case-insensitively.
* Any new aggregation repository / persistent state component must not call
{{ObjectInputStream.readObject()}} without an {{ObjectInputFilter}}.
* New defaults must err on the side of "denied unless opted in" for the four
{{security}} categories.
h2. Acceptance criteria
* {{docs/user-manual/modules/ROOT/pages/security-model.adoc}} exists,
referenced from {{security.adoc}} and the user-manual nav.
* {{SECURITY.md}} at repo root links to the new doc (in addition to the
existing vuln-reporting pointer).
* {{AGENTS.md}} has a "Security Model" section summarising the rules and
linking to the canonical doc.
* In-scope and out-of-scope lists each cite at least one concrete historical
CVE so the rule is anchored in accepted precedent.
* The doc cross-references {{proposals/security.adoc}} (existing security
policy framework) and the existing {{security.adoc}} (user-facing security
features).
* Doc has been reviewed on the private security list and on
[email protected] so the PMC concurs on scope before publication.
h2. Out of scope for this issue
* Changing any code defaults. This issue is documentation-only. Hardening
individual components, adding {{HeaderFilterStrategy}} to a specific consumer,
or installing {{ObjectInputFilter}} in an aggregation repository remain
individual CVE / improvement tickets.
* Producing a CVSS-style severity rubric. The model documents _whether_
something is in scope, not _how severe_ it is.
* Auto-generating advisories. The model supports the existing private
vulnerability reporting workflow described at
[https://camel.apache.org/security/].
h2. References
* Airflow security model (the pattern this issue mirrors):
[https://github.com/apache/airflow/blob/main/airflow-core/docs/security/security_model.rst]
and the AGENTS.md summary at
[https://github.com/apache/airflow/blob/main/AGENTS.md#security-model].
* {{proposals/security.adoc}} - existing Camel security policy framework (the
{{secret}} / {{insecure:ssl}} / {{insecure:serialization}} / {{insecure:dev}}
categories with {{allow}} / {{warn}} / {{fail}} enforcement).
* {{docs/user-manual/modules/ROOT/pages/security.adoc}} - existing user-facing
security page.
* {{SECURITY.md}} - current vuln-reporting shim.
* 40 historical Camel advisories at
[https://github.com/apache/camel-website/tree/main/content/security].
----
_Claude Code on behalf of Andrea Cosentino_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
