[
https://issues.apache.org/jira/browse/CAMEL-23496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080513#comment-18080513
]
Andrea Cosentino commented on CAMEL-23496:
------------------------------------------
Pull request opened: https://github.com/apache/camel/pull/23181
_Claude Code on behalf of Andrea Cosentino_
> 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
> Assignee: Andrea Cosentino
> Priority: Major
> Labels: documentation, security
>
> 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)
