davsclaus commented on code in PR #23181: URL: https://github.com/apache/camel/pull/23181#discussion_r3232747264
########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -0,0 +1,410 @@ += Security Model + +This page documents Apache Camel's security model: who is trusted, where the +trust boundaries sit, what counts as a framework vulnerability, and what is +expected of operators and route authors. It is the reference used by the Camel +PMC when triaging security reports and by the project when deciding whether a +behaviour should be hardened in the framework or addressed by the deployment. + +It complements two existing documents: + +* xref:security.adoc[Security] - the user-facing catalog of security features + (route, payload, endpoint and configuration security, vaults, JSSE). +* The `proposals/security.adoc` design document in the repository - the + annotation-driven security policy enforcement framework that detects insecure + configuration at startup time. + +For instructions on how to report a vulnerability, see +https://camel.apache.org/security/[Apache Camel Security] and the repository +`SECURITY.md` file. + +== Audience + +This document is written for four audiences: + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a framework vulnerability before submitting a report. +* *Automated triage tooling* (CVE scanners, AI-assisted security review) that + needs an authoritative scope statement to distinguish a real framework + vulnerability from an intentional, documented design choice. +* *Camel committers and component authors* reviewing pull requests and writing + new components, who need to know which defaults and patterns are acceptable. +* *Operators and deployment owners* who need to know how to deploy Camel + applications safely and which hardening responsibilities the framework + delegates to them. + +== Trust model + +Camel is an integration framework that is embedded in someone else's +application, not a multi-tenant managed service. Its trust model reflects that. + +=== Roles + +[cols="1,1,3"] +|=== +| Role | Trust level | What this role can do + +| Camel committers and component authors +| Trusted +| Define APIs, write components, choose defaults, publish releases. The + framework relies on these contributors to ship secure defaults. + +| Route authors (the people writing Camel routes in Java, XML or YAML DSL) +| Fully trusted +| Execute arbitrary Java code in `.bean()`, `.process()` and `Class` references; + evaluate arbitrary expressions in `simple`, `groovy`, `jexl`, `mvel`, `xpath`, + `ognl` and friends; reach any class on the classpath; configure any component + option. Code execution by a route author is by design and is not a + vulnerability in the framework. + +| Deployment operators (the people who configure and deploy a Camel + application) +| Fully trusted +| Set configuration properties (including secrets), choose the runtime, decide + what to expose on the network, decide whether to enable management endpoints, + pick the JVM and OS user, and configure the secrets backend. Operator + misconfiguration is not a framework vulnerability unless the framework's + default exposed it. + +| External message senders (HTTP clients, JMS producers, file droppers, SMTP + senders, CoAP peers, AMQP publishers, Kafka producers, mail senders, etc.) +| Untrusted +| Send messages into a Camel route over the network or filesystem. This is the + primary attacker model. The framework must not turn an untrusted message into + code execution, file read, request forgery or authentication bypass on its + own. +|=== + +=== Trust boundaries + +The fundamental trust boundary in Camel is between *the route* (and everything +the operator configured) and *the data flowing through the route*. Anything a +route author wrote is trusted code; anything that arrives in an `Exchange` +body, header or attachment from a Camel consumer is untrusted data. + +The framework's job is to keep that boundary intact: untrusted data must not +become code, must not redirect the route to a different endpoint, must not be +deserialised into arbitrary types, and must not be parsed in ways that resolve +remote resources, unless the route author explicitly asked for it. + +== Vulnerability scope + +A report is in scope when it demonstrates that the framework, in a default or +reasonably-expected configuration, lets untrusted input cross a trust boundary +that the model says it should not cross. + +=== In-scope vulnerability classes + +The classes below are grounded in advisories the Apache Camel PMC has accepted +in the past. The CVE IDs in each item are representative examples, not an +exhaustive list. The full advisory history is at +https://camel.apache.org/security/[]. + +==== Unsafe deserialization of untrusted input + +Any code path where data received from an external producer is passed to +`ObjectInputStream.readObject()`, an XStream / Hessian / Castor / SnakeYAML +unmarshaller, or a polymorphic Jackson reader without an effective filter or +allowlist. + +Historical examples: + +* CVE-2015-5344 (`camel-xstream`), CVE-2017-3159 (`camel-snakeyaml`), + CVE-2017-12633 (`camel-hessian`), CVE-2017-12634 (`camel-castor`) - + data-format components performing untrusted-type deserialisation. +* CVE-2016-8749 (`camel-jackson`) - attacker-controlled + `CamelJacksonUnmarshalType` header selecting the deserialised type. +* CVE-2015-5348 (`camel-jetty`, `camel-servlet`) - HTTP consumer auto-detecting + `application/x-java-serialized-object` and deserialising the body. +* CVE-2020-11972 (`camel-rabbitmq`), CVE-2020-11973 (`camel-netty`) - Java + deserialisation enabled in the default consumer configuration. +* CVE-2024-22369 (`camel-sql`), CVE-2024-23114 (`camel-cassandraql`), + CVE-2026-25747 (`camel-leveldb`), CVE-2026-27172 (`camel-consul`), + CVE-2026-40858 (`camel-infinispan`) - aggregation repositories doing raw + `ObjectInputStream.readObject()` on persisted state. +* CVE-2026-40048 (`camel-pqc`) - file-backed key store deserialising `.key` + files. +* CVE-2026-40473 (`camel-mina`) - TCP/UDP type converter wrapping incoming + bytes in `ObjectInputStream`. +* CVE-2026-40860 (`camel-jms`, `camel-sjms`, `camel-sjms2`, `camel-amqp`) - + `JmsBinding.extractBodyFromJms()` calling `ObjectMessage.getObject()` with no + filter while `mapJmsMessage=true` (the default). + +==== XML external entity (XXE) and remote DTD/stylesheet resolution + +Any XML parser, XSLT engine, XSD validator, XPath evaluator or XML data +converter that resolves external entities or fetches remote DTDs / stylesheets +from untrusted input by default. + +Historical examples: CVE-2014-0002 and CVE-2014-0003 (`camel-xslt`), +CVE-2015-0263 (XML converter in `camel-core`), CVE-2015-0264 (XPath language in +`camel-core`), CVE-2017-5643 (Validation component), CVE-2018-8027 +(XSD validation processor), CVE-2019-0188 (`camel-xmljson` via `json-lib`). + +==== Expression or template language injection + +Any code path where untrusted input is evaluated as a Camel `simple` expression +or a template language (Velocity, Freemarker, Mustache, MVEL, etc.) without an +explicit opt-in from the route author. + +Historical examples: CVE-2013-4330 (`CamelFileName` header value being passed +to `simple` by the producer in `camel-file` / `camel-ftp`), CVE-2020-11994 +(template injection plus arbitrary file disclosure in templating components). + +NOTE: A route author who writes `.simple("${header.x}")` against an +attacker-controlled header _is_ injecting code, but the framework cannot decide +on their behalf whether `header.x` is trusted. That case is route-author +responsibility, not a framework vulnerability. The in-scope case is when the +framework itself passes untrusted input to an evaluator without the route +author asking for it. + +==== Path traversal + +Any consumer or producer that lets an untrusted file name, header or URI +component navigate outside the configured root directory. + +Historical examples: CVE-2018-8041 (`camel-mail`), CVE-2019-0194 +(`camel-file`). + +==== SSRF or remote-resource fetch triggered by parsing + +Any parser that resolves a URL or DTD reference from untrusted input as part of +its default parsing behaviour. + +Historical example: CVE-2017-5643 (Validation component fetching remote DTDs). + +==== Camel-header / bean-dispatch abuse via untrusted input + +Camel uses internal headers - `CamelBeanMethodName`, `CamelFileName`, +`CamelExecCommandExecutable`, `CamelJmsDestinationName`, +`CamelHttpUri`, `CamelJacksonUnmarshalType` and others - to drive component +behaviour. Any consumer that maps untrusted input into the `Exchange` header +map without a strict, case-insensitive `HeaderFilterStrategy` becomes an +injection vector for these headers. + +Historical examples: CVE-2025-27636, CVE-2025-29891 (default HTTP +`HeaderFilterStrategy` bypass), CVE-2025-30177 (`camel-undertow` inbound +filter), CVE-2026-33453 (`camel-coap`), CVE-2026-33454 (`camel-mail`), +CVE-2026-40453 (`camel-jms`, `camel-sjms`, `camel-coap`, `camel-google-pubsub` +case-variant follow-on). + +==== Authentication or authorization bypass in security-providing components + +Components that explicitly provide authentication, authorization, or tenant +isolation (Keycloak, JWT, Shiro, Spring Security, platform-http auth handlers, +etc.) must enforce what they claim to enforce. + +Historical examples: CVE-2026-23552 (`camel-keycloak` not validating the JWT +`iss` claim against the configured realm), CVE-2026-40022 +(`camel-platform-http-main` Vert.x sub-router mounted at `<path>*` while the +auth handler was at the exact path, exposing subpaths of `/api`, `/admin`, +`/observe/info`). + +==== Information disclosure of secrets or sensitive Exchange state + +Code paths that write secrets, internal Exchange state, file contents or +configuration values to a log, an event, a world-readable file, or an HTTP +response. + +Historical examples: CVE-2023-34442 (`camel-jira` writing attachments to +world-readable temp files), CVE-2024-22371 (`EventFactory` exposing sensitive +Exchange data via a custom event). + +==== Insecure defaults + +A component shipping with a security-relevant option enabled by default - Java +deserialisation, TLS validation disabled, an admin endpoint listening on +`0.0.0.0`, a permissive `HeaderFilterStrategy`, an unfiltered +`ObjectInputStream` - is in scope independently of the underlying class. The +question is what an attacker can do against a component the operator simply +added to a route without further configuration. + +Historical examples: CVE-2020-11972, CVE-2020-11973 and CVE-2026-40860 are all +insecure-default cases that also fall into the deserialisation class. + +==== Injection into back-end queries built by Camel + +Components that build a query in another language from inputs they receive +must not splice untrusted input directly into that query. + +Historical examples: CVE-2025-66169 (`camel-neo4j` Cypher injection), +CVE-2014-0003 (`camel-xslt` extension-function invocation from untrusted +stylesheet input). + +=== Out of scope + +The following are *not* framework vulnerabilities. They are intentional design, +operator responsibility, or downstream misuse. Reports in these categories will +be closed as `not a vulnerability`. + +* *A route author writing code that does whatever they want.* `.bean()`, + `.process()`, `Runtime.exec()`, `simple` / `groovy` / `jexl` / `mvel` + evaluation, custom processors and beans are route code, and route code is + trusted. If a route author evaluates an attacker-controlled header as a + `simple` expression, the route is at fault, not the framework. The framework + is in scope only when *it* passes untrusted input to an evaluator without the + route author asking for it. +* *A route author building a SQL, Cypher, LDAP, XPath or HTTP URI string from + untrusted input without parameterisation.* The components offer safe APIs + (parameter binding, prepared statements, URI builders); using them is the + route author's responsibility. +* *An option whose risk is documented and which must be set explicitly to + enable the risky behaviour.* `allowJavaSerializedObject=true`, + `transferException=true`, `trustAllCertificates=true`, + `hostnameVerificationEnabled=false`, explicit selection of an + `ObjectInputStream`-using data format - these are documented opt-ins and the + operator has signed up for the consequences. +* *Denial of service via resource exhaustion.* Unthrottled routes, unbounded + aggregators, an HTTP consumer with no rate limit, a JMS consumer that + accepts arbitrarily large messages - operators must apply `throttle`, + `circuitBreaker`, `resilience4j`, JVM heap limits, and the relevant + component-level options. Algorithmic-complexity attacks in third-party + libraries are reported to the upstream project unless Camel exposes the + parser in a way that bypasses the library's own limits. +* *A deployer placing `camel-management`, the developer console, + `camel-jolokia`, JMX or another management surface on a public network.* + These are management surfaces; they assume a trusted network. +* *Vulnerabilities in third-party transitive dependencies that are not + reachable through any Camel-exposed code path.* See + https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the + upstream project for the actual CVE. +* *Self-XSS by an authenticated user* of a UI built on top of Camel. +* *Reports from automated scanners that do not demonstrate a concrete + trust-boundary breach.* "Component X uses class Y that has historically had + CVEs" is not, by itself, a finding. The report must show that the code path + is reachable from an untrusted source and that the trust boundary is crossed. + +=== Known limitations + +These are framework characteristics that look like vulnerabilities at first +glance but are documented design points. They may be tightened over time; if +they are, the change is announced through the normal upgrade-guide channel. + +* *Some heritage components default to permissive settings.* FTP, plain SMTP, + `mapJmsMessage=true` and similar are kept compatible with how they have + always behaved. Where the project has decided to tighten a default, the + change ships with an upgrade-guide entry and a corresponding CVE if the prior + default was a security risk in a default-installed deployment. +* *Bean-based dispatch via internal headers is intentional.* Headers like + `CamelBeanMethodName`, `CamelFileName`, `CamelExecCommandExecutable` and + `CamelJmsDestinationName` are the public contract for letting a route control + component behaviour. Route authors must filter Camel-internal headers from + untrusted producers (see _Deployment hardening_ below); component authors + must apply a strict `HeaderFilterStrategy` on the inbound path. +* *Aggregation repositories that persist Java objects assume the backing store + is trusted.* JDBC, Cassandra, Infinispan, LevelDB, Consul and similar + repositories are state stores for routes the operator wrote; the operator is + responsible for keeping write access to that store inside the trust boundary. +* *Many components inherit the security posture of their underlying client.* + `camel-jms` inherits JMS-broker client behaviour; `camel-kafka` inherits + Kafka-client behaviour; cloud SDK components inherit the SDK's TLS and auth + defaults. A report against Camel must show the framework, not the underlying Review Comment: ```suggestion defaults. A report against Camel must show the Camel framework, not the underlying ``` ########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -0,0 +1,410 @@ += Security Model + +This page documents Apache Camel's security model: who is trusted, where the +trust boundaries sit, what counts as a framework vulnerability, and what is +expected of operators and route authors. It is the reference used by the Camel +PMC when triaging security reports and by the project when deciding whether a +behaviour should be hardened in the framework or addressed by the deployment. + +It complements two existing documents: + +* xref:security.adoc[Security] - the user-facing catalog of security features + (route, payload, endpoint and configuration security, vaults, JSSE). +* The `proposals/security.adoc` design document in the repository - the + annotation-driven security policy enforcement framework that detects insecure + configuration at startup time. + +For instructions on how to report a vulnerability, see +https://camel.apache.org/security/[Apache Camel Security] and the repository +`SECURITY.md` file. + +== Audience + +This document is written for four audiences: + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a framework vulnerability before submitting a report. +* *Automated triage tooling* (CVE scanners, AI-assisted security review) that + needs an authoritative scope statement to distinguish a real framework + vulnerability from an intentional, documented design choice. +* *Camel committers and component authors* reviewing pull requests and writing + new components, who need to know which defaults and patterns are acceptable. +* *Operators and deployment owners* who need to know how to deploy Camel + applications safely and which hardening responsibilities the framework + delegates to them. + +== Trust model + +Camel is an integration framework that is embedded in someone else's +application, not a multi-tenant managed service. Its trust model reflects that. + +=== Roles + +[cols="1,1,3"] +|=== +| Role | Trust level | What this role can do + +| Camel committers and component authors +| Trusted +| Define APIs, write components, choose defaults, publish releases. The + framework relies on these contributors to ship secure defaults. + +| Route authors (the people writing Camel routes in Java, XML or YAML DSL) +| Fully trusted +| Execute arbitrary Java code in `.bean()`, `.process()` and `Class` references; + evaluate arbitrary expressions in `simple`, `groovy`, `jexl`, `mvel`, `xpath`, + `ognl` and friends; reach any class on the classpath; configure any component + option. Code execution by a route author is by design and is not a + vulnerability in the framework. + +| Deployment operators (the people who configure and deploy a Camel + application) +| Fully trusted +| Set configuration properties (including secrets), choose the runtime, decide + what to expose on the network, decide whether to enable management endpoints, + pick the JVM and OS user, and configure the secrets backend. Operator + misconfiguration is not a framework vulnerability unless the framework's + default exposed it. + +| External message senders (HTTP clients, JMS producers, file droppers, SMTP + senders, CoAP peers, AMQP publishers, Kafka producers, mail senders, etc.) +| Untrusted +| Send messages into a Camel route over the network or filesystem. This is the + primary attacker model. The framework must not turn an untrusted message into + code execution, file read, request forgery or authentication bypass on its + own. +|=== + +=== Trust boundaries + +The fundamental trust boundary in Camel is between *the route* (and everything +the operator configured) and *the data flowing through the route*. Anything a +route author wrote is trusted code; anything that arrives in an `Exchange` +body, header or attachment from a Camel consumer is untrusted data. + +The framework's job is to keep that boundary intact: untrusted data must not +become code, must not redirect the route to a different endpoint, must not be +deserialised into arbitrary types, and must not be parsed in ways that resolve +remote resources, unless the route author explicitly asked for it. + +== Vulnerability scope + +A report is in scope when it demonstrates that the framework, in a default or +reasonably-expected configuration, lets untrusted input cross a trust boundary +that the model says it should not cross. + +=== In-scope vulnerability classes + +The classes below are grounded in advisories the Apache Camel PMC has accepted +in the past. The CVE IDs in each item are representative examples, not an +exhaustive list. The full advisory history is at +https://camel.apache.org/security/[]. + +==== Unsafe deserialization of untrusted input + +Any code path where data received from an external producer is passed to +`ObjectInputStream.readObject()`, an XStream / Hessian / Castor / SnakeYAML +unmarshaller, or a polymorphic Jackson reader without an effective filter or +allowlist. + +Historical examples: + +* CVE-2015-5344 (`camel-xstream`), CVE-2017-3159 (`camel-snakeyaml`), + CVE-2017-12633 (`camel-hessian`), CVE-2017-12634 (`camel-castor`) - + data-format components performing untrusted-type deserialisation. +* CVE-2016-8749 (`camel-jackson`) - attacker-controlled + `CamelJacksonUnmarshalType` header selecting the deserialised type. +* CVE-2015-5348 (`camel-jetty`, `camel-servlet`) - HTTP consumer auto-detecting + `application/x-java-serialized-object` and deserialising the body. +* CVE-2020-11972 (`camel-rabbitmq`), CVE-2020-11973 (`camel-netty`) - Java + deserialisation enabled in the default consumer configuration. +* CVE-2024-22369 (`camel-sql`), CVE-2024-23114 (`camel-cassandraql`), + CVE-2026-25747 (`camel-leveldb`), CVE-2026-27172 (`camel-consul`), + CVE-2026-40858 (`camel-infinispan`) - aggregation repositories doing raw + `ObjectInputStream.readObject()` on persisted state. +* CVE-2026-40048 (`camel-pqc`) - file-backed key store deserialising `.key` + files. +* CVE-2026-40473 (`camel-mina`) - TCP/UDP type converter wrapping incoming + bytes in `ObjectInputStream`. +* CVE-2026-40860 (`camel-jms`, `camel-sjms`, `camel-sjms2`, `camel-amqp`) - + `JmsBinding.extractBodyFromJms()` calling `ObjectMessage.getObject()` with no + filter while `mapJmsMessage=true` (the default). + +==== XML external entity (XXE) and remote DTD/stylesheet resolution + +Any XML parser, XSLT engine, XSD validator, XPath evaluator or XML data +converter that resolves external entities or fetches remote DTDs / stylesheets +from untrusted input by default. + +Historical examples: CVE-2014-0002 and CVE-2014-0003 (`camel-xslt`), +CVE-2015-0263 (XML converter in `camel-core`), CVE-2015-0264 (XPath language in +`camel-core`), CVE-2017-5643 (Validation component), CVE-2018-8027 +(XSD validation processor), CVE-2019-0188 (`camel-xmljson` via `json-lib`). + +==== Expression or template language injection + +Any code path where untrusted input is evaluated as a Camel `simple` expression +or a template language (Velocity, Freemarker, Mustache, MVEL, etc.) without an +explicit opt-in from the route author. + +Historical examples: CVE-2013-4330 (`CamelFileName` header value being passed +to `simple` by the producer in `camel-file` / `camel-ftp`), CVE-2020-11994 +(template injection plus arbitrary file disclosure in templating components). + +NOTE: A route author who writes `.simple("${header.x}")` against an +attacker-controlled header _is_ injecting code, but the framework cannot decide +on their behalf whether `header.x` is trusted. That case is route-author +responsibility, not a framework vulnerability. The in-scope case is when the +framework itself passes untrusted input to an evaluator without the route +author asking for it. + +==== Path traversal + +Any consumer or producer that lets an untrusted file name, header or URI +component navigate outside the configured root directory. + +Historical examples: CVE-2018-8041 (`camel-mail`), CVE-2019-0194 +(`camel-file`). + +==== SSRF or remote-resource fetch triggered by parsing + +Any parser that resolves a URL or DTD reference from untrusted input as part of +its default parsing behaviour. + +Historical example: CVE-2017-5643 (Validation component fetching remote DTDs). + +==== Camel-header / bean-dispatch abuse via untrusted input + +Camel uses internal headers - `CamelBeanMethodName`, `CamelFileName`, +`CamelExecCommandExecutable`, `CamelJmsDestinationName`, +`CamelHttpUri`, `CamelJacksonUnmarshalType` and others - to drive component +behaviour. Any consumer that maps untrusted input into the `Exchange` header +map without a strict, case-insensitive `HeaderFilterStrategy` becomes an +injection vector for these headers. + +Historical examples: CVE-2025-27636, CVE-2025-29891 (default HTTP +`HeaderFilterStrategy` bypass), CVE-2025-30177 (`camel-undertow` inbound +filter), CVE-2026-33453 (`camel-coap`), CVE-2026-33454 (`camel-mail`), +CVE-2026-40453 (`camel-jms`, `camel-sjms`, `camel-coap`, `camel-google-pubsub` +case-variant follow-on). + +==== Authentication or authorization bypass in security-providing components + +Components that explicitly provide authentication, authorization, or tenant +isolation (Keycloak, JWT, Shiro, Spring Security, platform-http auth handlers, +etc.) must enforce what they claim to enforce. + +Historical examples: CVE-2026-23552 (`camel-keycloak` not validating the JWT +`iss` claim against the configured realm), CVE-2026-40022 +(`camel-platform-http-main` Vert.x sub-router mounted at `<path>*` while the +auth handler was at the exact path, exposing subpaths of `/api`, `/admin`, +`/observe/info`). + +==== Information disclosure of secrets or sensitive Exchange state + +Code paths that write secrets, internal Exchange state, file contents or +configuration values to a log, an event, a world-readable file, or an HTTP +response. + +Historical examples: CVE-2023-34442 (`camel-jira` writing attachments to +world-readable temp files), CVE-2024-22371 (`EventFactory` exposing sensitive +Exchange data via a custom event). + +==== Insecure defaults + +A component shipping with a security-relevant option enabled by default - Java +deserialisation, TLS validation disabled, an admin endpoint listening on +`0.0.0.0`, a permissive `HeaderFilterStrategy`, an unfiltered +`ObjectInputStream` - is in scope independently of the underlying class. The +question is what an attacker can do against a component the operator simply +added to a route without further configuration. + +Historical examples: CVE-2020-11972, CVE-2020-11973 and CVE-2026-40860 are all +insecure-default cases that also fall into the deserialisation class. + +==== Injection into back-end queries built by Camel + +Components that build a query in another language from inputs they receive +must not splice untrusted input directly into that query. + +Historical examples: CVE-2025-66169 (`camel-neo4j` Cypher injection), +CVE-2014-0003 (`camel-xslt` extension-function invocation from untrusted +stylesheet input). + +=== Out of scope + +The following are *not* framework vulnerabilities. They are intentional design, +operator responsibility, or downstream misuse. Reports in these categories will +be closed as `not a vulnerability`. + +* *A route author writing code that does whatever they want.* `.bean()`, + `.process()`, `Runtime.exec()`, `simple` / `groovy` / `jexl` / `mvel` + evaluation, custom processors and beans are route code, and route code is + trusted. If a route author evaluates an attacker-controlled header as a + `simple` expression, the route is at fault, not the framework. The framework + is in scope only when *it* passes untrusted input to an evaluator without the + route author asking for it. +* *A route author building a SQL, Cypher, LDAP, XPath or HTTP URI string from + untrusted input without parameterisation.* The components offer safe APIs + (parameter binding, prepared statements, URI builders); using them is the + route author's responsibility. +* *An option whose risk is documented and which must be set explicitly to + enable the risky behaviour.* `allowJavaSerializedObject=true`, + `transferException=true`, `trustAllCertificates=true`, + `hostnameVerificationEnabled=false`, explicit selection of an + `ObjectInputStream`-using data format - these are documented opt-ins and the + operator has signed up for the consequences. +* *Denial of service via resource exhaustion.* Unthrottled routes, unbounded + aggregators, an HTTP consumer with no rate limit, a JMS consumer that + accepts arbitrarily large messages - operators must apply `throttle`, + `circuitBreaker`, `resilience4j`, JVM heap limits, and the relevant + component-level options. Algorithmic-complexity attacks in third-party + libraries are reported to the upstream project unless Camel exposes the + parser in a way that bypasses the library's own limits. +* *A deployer placing `camel-management`, the developer console, + `camel-jolokia`, JMX or another management surface on a public network.* + These are management surfaces; they assume a trusted network. +* *Vulnerabilities in third-party transitive dependencies that are not + reachable through any Camel-exposed code path.* See + https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the + upstream project for the actual CVE. +* *Self-XSS by an authenticated user* of a UI built on top of Camel. +* *Reports from automated scanners that do not demonstrate a concrete + trust-boundary breach.* "Component X uses class Y that has historically had + CVEs" is not, by itself, a finding. The report must show that the code path + is reachable from an untrusted source and that the trust boundary is crossed. + +=== Known limitations + +These are framework characteristics that look like vulnerabilities at first +glance but are documented design points. They may be tightened over time; if +they are, the change is announced through the normal upgrade-guide channel. + +* *Some heritage components default to permissive settings.* FTP, plain SMTP, + `mapJmsMessage=true` and similar are kept compatible with how they have + always behaved. Where the project has decided to tighten a default, the + change ships with an upgrade-guide entry and a corresponding CVE if the prior + default was a security risk in a default-installed deployment. +* *Bean-based dispatch via internal headers is intentional.* Headers like + `CamelBeanMethodName`, `CamelFileName`, `CamelExecCommandExecutable` and + `CamelJmsDestinationName` are the public contract for letting a route control + component behaviour. Route authors must filter Camel-internal headers from + untrusted producers (see _Deployment hardening_ below); component authors + must apply a strict `HeaderFilterStrategy` on the inbound path. +* *Aggregation repositories that persist Java objects assume the backing store + is trusted.* JDBC, Cassandra, Infinispan, LevelDB, Consul and similar + repositories are state stores for routes the operator wrote; the operator is + responsible for keeping write access to that store inside the trust boundary. +* *Many components inherit the security posture of their underlying client.* + `camel-jms` inherits JMS-broker client behaviour; `camel-kafka` inherits + Kafka-client behaviour; cloud SDK components inherit the SDK's TLS and auth + defaults. A report against Camel must show the framework, not the underlying + client, is the cause. + +== Deployment hardening + +Operators are responsible for the following. None of these are framework +vulnerabilities if skipped; all of them reduce the attack surface materially. + +* *Enable the security policy framework.* Set `camel.main.profile = prod` so Review Comment: prod is the default profile, so users do not have to set it. on the other hand if they set the profile=dev or profile=test then they deliberabilty use a non production profile and as such lets camel include more services that are intended for development and testing purposes that can expose or give malicious users acces or power that are unsafe ########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -0,0 +1,410 @@ += Security Model + +This page documents Apache Camel's security model: who is trusted, where the +trust boundaries sit, what counts as a framework vulnerability, and what is +expected of operators and route authors. It is the reference used by the Camel +PMC when triaging security reports and by the project when deciding whether a +behaviour should be hardened in the framework or addressed by the deployment. + +It complements two existing documents: + +* xref:security.adoc[Security] - the user-facing catalog of security features + (route, payload, endpoint and configuration security, vaults, JSSE). +* The `proposals/security.adoc` design document in the repository - the + annotation-driven security policy enforcement framework that detects insecure + configuration at startup time. + +For instructions on how to report a vulnerability, see +https://camel.apache.org/security/[Apache Camel Security] and the repository +`SECURITY.md` file. + +== Audience + +This document is written for four audiences: + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a framework vulnerability before submitting a report. +* *Automated triage tooling* (CVE scanners, AI-assisted security review) that + needs an authoritative scope statement to distinguish a real framework + vulnerability from an intentional, documented design choice. +* *Camel committers and component authors* reviewing pull requests and writing + new components, who need to know which defaults and patterns are acceptable. +* *Operators and deployment owners* who need to know how to deploy Camel + applications safely and which hardening responsibilities the framework + delegates to them. + +== Trust model + +Camel is an integration framework that is embedded in someone else's +application, not a multi-tenant managed service. Its trust model reflects that. + +=== Roles + +[cols="1,1,3"] +|=== +| Role | Trust level | What this role can do + +| Camel committers and component authors +| Trusted +| Define APIs, write components, choose defaults, publish releases. The + framework relies on these contributors to ship secure defaults. + +| Route authors (the people writing Camel routes in Java, XML or YAML DSL) +| Fully trusted +| Execute arbitrary Java code in `.bean()`, `.process()` and `Class` references; + evaluate arbitrary expressions in `simple`, `groovy`, `jexl`, `mvel`, `xpath`, + `ognl` and friends; reach any class on the classpath; configure any component + option. Code execution by a route author is by design and is not a + vulnerability in the framework. + +| Deployment operators (the people who configure and deploy a Camel + application) +| Fully trusted +| Set configuration properties (including secrets), choose the runtime, decide + what to expose on the network, decide whether to enable management endpoints, + pick the JVM and OS user, and configure the secrets backend. Operator + misconfiguration is not a framework vulnerability unless the framework's + default exposed it. + +| External message senders (HTTP clients, JMS producers, file droppers, SMTP + senders, CoAP peers, AMQP publishers, Kafka producers, mail senders, etc.) +| Untrusted +| Send messages into a Camel route over the network or filesystem. This is the + primary attacker model. The framework must not turn an untrusted message into + code execution, file read, request forgery or authentication bypass on its + own. +|=== + +=== Trust boundaries + +The fundamental trust boundary in Camel is between *the route* (and everything +the operator configured) and *the data flowing through the route*. Anything a +route author wrote is trusted code; anything that arrives in an `Exchange` +body, header or attachment from a Camel consumer is untrusted data. + +The framework's job is to keep that boundary intact: untrusted data must not +become code, must not redirect the route to a different endpoint, must not be +deserialised into arbitrary types, and must not be parsed in ways that resolve +remote resources, unless the route author explicitly asked for it. + +== Vulnerability scope + +A report is in scope when it demonstrates that the framework, in a default or +reasonably-expected configuration, lets untrusted input cross a trust boundary +that the model says it should not cross. + +=== In-scope vulnerability classes + +The classes below are grounded in advisories the Apache Camel PMC has accepted +in the past. The CVE IDs in each item are representative examples, not an +exhaustive list. The full advisory history is at +https://camel.apache.org/security/[]. + +==== Unsafe deserialization of untrusted input + +Any code path where data received from an external producer is passed to +`ObjectInputStream.readObject()`, an XStream / Hessian / Castor / SnakeYAML +unmarshaller, or a polymorphic Jackson reader without an effective filter or +allowlist. + +Historical examples: + +* CVE-2015-5344 (`camel-xstream`), CVE-2017-3159 (`camel-snakeyaml`), + CVE-2017-12633 (`camel-hessian`), CVE-2017-12634 (`camel-castor`) - + data-format components performing untrusted-type deserialisation. +* CVE-2016-8749 (`camel-jackson`) - attacker-controlled + `CamelJacksonUnmarshalType` header selecting the deserialised type. +* CVE-2015-5348 (`camel-jetty`, `camel-servlet`) - HTTP consumer auto-detecting + `application/x-java-serialized-object` and deserialising the body. +* CVE-2020-11972 (`camel-rabbitmq`), CVE-2020-11973 (`camel-netty`) - Java + deserialisation enabled in the default consumer configuration. +* CVE-2024-22369 (`camel-sql`), CVE-2024-23114 (`camel-cassandraql`), + CVE-2026-25747 (`camel-leveldb`), CVE-2026-27172 (`camel-consul`), + CVE-2026-40858 (`camel-infinispan`) - aggregation repositories doing raw + `ObjectInputStream.readObject()` on persisted state. +* CVE-2026-40048 (`camel-pqc`) - file-backed key store deserialising `.key` + files. +* CVE-2026-40473 (`camel-mina`) - TCP/UDP type converter wrapping incoming + bytes in `ObjectInputStream`. +* CVE-2026-40860 (`camel-jms`, `camel-sjms`, `camel-sjms2`, `camel-amqp`) - + `JmsBinding.extractBodyFromJms()` calling `ObjectMessage.getObject()` with no + filter while `mapJmsMessage=true` (the default). + +==== XML external entity (XXE) and remote DTD/stylesheet resolution + +Any XML parser, XSLT engine, XSD validator, XPath evaluator or XML data +converter that resolves external entities or fetches remote DTDs / stylesheets +from untrusted input by default. + +Historical examples: CVE-2014-0002 and CVE-2014-0003 (`camel-xslt`), +CVE-2015-0263 (XML converter in `camel-core`), CVE-2015-0264 (XPath language in +`camel-core`), CVE-2017-5643 (Validation component), CVE-2018-8027 +(XSD validation processor), CVE-2019-0188 (`camel-xmljson` via `json-lib`). + +==== Expression or template language injection + +Any code path where untrusted input is evaluated as a Camel `simple` expression +or a template language (Velocity, Freemarker, Mustache, MVEL, etc.) without an +explicit opt-in from the route author. + +Historical examples: CVE-2013-4330 (`CamelFileName` header value being passed +to `simple` by the producer in `camel-file` / `camel-ftp`), CVE-2020-11994 +(template injection plus arbitrary file disclosure in templating components). + +NOTE: A route author who writes `.simple("${header.x}")` against an +attacker-controlled header _is_ injecting code, but the framework cannot decide +on their behalf whether `header.x` is trusted. That case is route-author +responsibility, not a framework vulnerability. The in-scope case is when the +framework itself passes untrusted input to an evaluator without the route +author asking for it. + +==== Path traversal + +Any consumer or producer that lets an untrusted file name, header or URI +component navigate outside the configured root directory. + +Historical examples: CVE-2018-8041 (`camel-mail`), CVE-2019-0194 +(`camel-file`). + +==== SSRF or remote-resource fetch triggered by parsing + +Any parser that resolves a URL or DTD reference from untrusted input as part of +its default parsing behaviour. + +Historical example: CVE-2017-5643 (Validation component fetching remote DTDs). + +==== Camel-header / bean-dispatch abuse via untrusted input + +Camel uses internal headers - `CamelBeanMethodName`, `CamelFileName`, +`CamelExecCommandExecutable`, `CamelJmsDestinationName`, +`CamelHttpUri`, `CamelJacksonUnmarshalType` and others - to drive component +behaviour. Any consumer that maps untrusted input into the `Exchange` header +map without a strict, case-insensitive `HeaderFilterStrategy` becomes an +injection vector for these headers. + +Historical examples: CVE-2025-27636, CVE-2025-29891 (default HTTP +`HeaderFilterStrategy` bypass), CVE-2025-30177 (`camel-undertow` inbound +filter), CVE-2026-33453 (`camel-coap`), CVE-2026-33454 (`camel-mail`), +CVE-2026-40453 (`camel-jms`, `camel-sjms`, `camel-coap`, `camel-google-pubsub` +case-variant follow-on). + +==== Authentication or authorization bypass in security-providing components + +Components that explicitly provide authentication, authorization, or tenant +isolation (Keycloak, JWT, Shiro, Spring Security, platform-http auth handlers, +etc.) must enforce what they claim to enforce. + +Historical examples: CVE-2026-23552 (`camel-keycloak` not validating the JWT +`iss` claim against the configured realm), CVE-2026-40022 +(`camel-platform-http-main` Vert.x sub-router mounted at `<path>*` while the +auth handler was at the exact path, exposing subpaths of `/api`, `/admin`, +`/observe/info`). + +==== Information disclosure of secrets or sensitive Exchange state + +Code paths that write secrets, internal Exchange state, file contents or +configuration values to a log, an event, a world-readable file, or an HTTP +response. + +Historical examples: CVE-2023-34442 (`camel-jira` writing attachments to +world-readable temp files), CVE-2024-22371 (`EventFactory` exposing sensitive +Exchange data via a custom event). + +==== Insecure defaults + +A component shipping with a security-relevant option enabled by default - Java +deserialisation, TLS validation disabled, an admin endpoint listening on +`0.0.0.0`, a permissive `HeaderFilterStrategy`, an unfiltered +`ObjectInputStream` - is in scope independently of the underlying class. The +question is what an attacker can do against a component the operator simply +added to a route without further configuration. + +Historical examples: CVE-2020-11972, CVE-2020-11973 and CVE-2026-40860 are all +insecure-default cases that also fall into the deserialisation class. + +==== Injection into back-end queries built by Camel + +Components that build a query in another language from inputs they receive +must not splice untrusted input directly into that query. + +Historical examples: CVE-2025-66169 (`camel-neo4j` Cypher injection), +CVE-2014-0003 (`camel-xslt` extension-function invocation from untrusted +stylesheet input). + +=== Out of scope + +The following are *not* framework vulnerabilities. They are intentional design, +operator responsibility, or downstream misuse. Reports in these categories will +be closed as `not a vulnerability`. + +* *A route author writing code that does whatever they want.* `.bean()`, + `.process()`, `Runtime.exec()`, `simple` / `groovy` / `jexl` / `mvel` + evaluation, custom processors and beans are route code, and route code is + trusted. If a route author evaluates an attacker-controlled header as a + `simple` expression, the route is at fault, not the framework. The framework + is in scope only when *it* passes untrusted input to an evaluator without the + route author asking for it. +* *A route author building a SQL, Cypher, LDAP, XPath or HTTP URI string from + untrusted input without parameterisation.* The components offer safe APIs + (parameter binding, prepared statements, URI builders); using them is the + route author's responsibility. +* *An option whose risk is documented and which must be set explicitly to + enable the risky behaviour.* `allowJavaSerializedObject=true`, + `transferException=true`, `trustAllCertificates=true`, + `hostnameVerificationEnabled=false`, explicit selection of an + `ObjectInputStream`-using data format - these are documented opt-ins and the + operator has signed up for the consequences. +* *Denial of service via resource exhaustion.* Unthrottled routes, unbounded + aggregators, an HTTP consumer with no rate limit, a JMS consumer that + accepts arbitrarily large messages - operators must apply `throttle`, + `circuitBreaker`, `resilience4j`, JVM heap limits, and the relevant + component-level options. Algorithmic-complexity attacks in third-party + libraries are reported to the upstream project unless Camel exposes the + parser in a way that bypasses the library's own limits. +* *A deployer placing `camel-management`, the developer console, + `camel-jolokia`, JMX or another management surface on a public network.* + These are management surfaces; they assume a trusted network. +* *Vulnerabilities in third-party transitive dependencies that are not + reachable through any Camel-exposed code path.* See + https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the + upstream project for the actual CVE. +* *Self-XSS by an authenticated user* of a UI built on top of Camel. +* *Reports from automated scanners that do not demonstrate a concrete + trust-boundary breach.* "Component X uses class Y that has historically had + CVEs" is not, by itself, a finding. The report must show that the code path + is reachable from an untrusted source and that the trust boundary is crossed. + +=== Known limitations + +These are framework characteristics that look like vulnerabilities at first +glance but are documented design points. They may be tightened over time; if +they are, the change is announced through the normal upgrade-guide channel. + +* *Some heritage components default to permissive settings.* FTP, plain SMTP, + `mapJmsMessage=true` and similar are kept compatible with how they have + always behaved. Where the project has decided to tighten a default, the + change ships with an upgrade-guide entry and a corresponding CVE if the prior + default was a security risk in a default-installed deployment. +* *Bean-based dispatch via internal headers is intentional.* Headers like + `CamelBeanMethodName`, `CamelFileName`, `CamelExecCommandExecutable` and + `CamelJmsDestinationName` are the public contract for letting a route control + component behaviour. Route authors must filter Camel-internal headers from + untrusted producers (see _Deployment hardening_ below); component authors + must apply a strict `HeaderFilterStrategy` on the inbound path. +* *Aggregation repositories that persist Java objects assume the backing store + is trusted.* JDBC, Cassandra, Infinispan, LevelDB, Consul and similar + repositories are state stores for routes the operator wrote; the operator is + responsible for keeping write access to that store inside the trust boundary. +* *Many components inherit the security posture of their underlying client.* + `camel-jms` inherits JMS-broker client behaviour; `camel-kafka` inherits + Kafka-client behaviour; cloud SDK components inherit the SDK's TLS and auth + defaults. A report against Camel must show the framework, not the underlying + client, is the cause. + +== Deployment hardening + +Operators are responsible for the following. None of these are framework +vulnerabilities if skipped; all of them reduce the attack surface materially. + +* *Enable the security policy framework.* Set `camel.main.profile = prod` so + the default policy for the four categories (`secret`, `insecure:ssl`, + `insecure:serialization`, `insecure:dev`) defaults to `fail`. Override + individual categories explicitly when a deployment genuinely needs the + relaxed behaviour. See the `proposals/security.adoc` design document for + details. +* *Resolve secrets through a vault.* Use one of the supported backends + (xref:security.adoc[AWS Secrets Manager, Azure Key Vault, Google Secret + Manager, HashiCorp Vault, IBM Secrets Manager, CyberArk Conjur]) rather than + plain-text values in property files. +* *Configure TLS through the JSSE Utility.* Use + xref:camel-configuration-utilities.adoc[`SSLContextParameters`] to set the + trust store, key store, ciphers and protocols explicitly. Do not use + `trustAllCertificates=true` or `hostnameVerificationEnabled=false` in + production. +* *Strip Camel-internal headers at the trust boundary.* When a consumer + receives messages from an untrusted producer, remove Camel-controlled + headers before the message reaches any dispatching processor: ++ +[source,java] +---- +from("jetty:http://0.0.0.0:8080/api";) + .removeHeaders("Camel*") + .removeHeaders("org.apache.camel.*") + .to("direct:trusted-pipeline"); +---- +* *Do not enable Java serialisation on consumers exposed to untrusted + networks.* In particular, do not set `allowJavaSerializedObject=true`, + `transferException=true`, or `mapJmsMessage=true` on a JMS consumer when the + upstream broker is not inside the trust boundary. If the option is + unavoidable, install an `ObjectInputFilter`. +* *Do not expose management surfaces.* `camel-management`, the developer + console, `camel-jolokia` and JMX should listen on a loopback interface, a + sidecar, or a separate network only. +* *Keep components patched.* Pin Camel to a supported version, subscribe to + the announce list, and respond to advisories at + https://camel.apache.org/security/[]. +* *Run with least privilege.* Limit the OS user's file-system, network and + process privileges; in a container deployment, drop unneeded capabilities + and mount only the filesystem paths the routes actually need. Review Comment: * Only include the least set of Camel dependencies (JARs) as your Camel application need and use. Same practice applies for any 3rd party non Camel dependencies. ########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -0,0 +1,410 @@ += Security Model + +This page documents Apache Camel's security model: who is trusted, where the +trust boundaries sit, what counts as a framework vulnerability, and what is +expected of operators and route authors. It is the reference used by the Camel +PMC when triaging security reports and by the project when deciding whether a +behaviour should be hardened in the framework or addressed by the deployment. + +It complements two existing documents: + +* xref:security.adoc[Security] - the user-facing catalog of security features + (route, payload, endpoint and configuration security, vaults, JSSE). +* The `proposals/security.adoc` design document in the repository - the + annotation-driven security policy enforcement framework that detects insecure + configuration at startup time. + +For instructions on how to report a vulnerability, see +https://camel.apache.org/security/[Apache Camel Security] and the repository +`SECURITY.md` file. + +== Audience + +This document is written for four audiences: + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a framework vulnerability before submitting a report. +* *Automated triage tooling* (CVE scanners, AI-assisted security review) that + needs an authoritative scope statement to distinguish a real framework + vulnerability from an intentional, documented design choice. +* *Camel committers and component authors* reviewing pull requests and writing + new components, who need to know which defaults and patterns are acceptable. +* *Operators and deployment owners* who need to know how to deploy Camel + applications safely and which hardening responsibilities the framework + delegates to them. + +== Trust model + +Camel is an integration framework that is embedded in someone else's +application, not a multi-tenant managed service. Its trust model reflects that. + +=== Roles + +[cols="1,1,3"] +|=== +| Role | Trust level | What this role can do + +| Camel committers and component authors +| Trusted +| Define APIs, write components, choose defaults, publish releases. The + framework relies on these contributors to ship secure defaults. + +| Route authors (the people writing Camel routes in Java, XML or YAML DSL) +| Fully trusted +| Execute arbitrary Java code in `.bean()`, `.process()` and `Class` references; + evaluate arbitrary expressions in `simple`, `groovy`, `jexl`, `mvel`, `xpath`, + `ognl` and friends; reach any class on the classpath; configure any component + option. Code execution by a route author is by design and is not a + vulnerability in the framework. + +| Deployment operators (the people who configure and deploy a Camel + application) +| Fully trusted +| Set configuration properties (including secrets), choose the runtime, decide + what to expose on the network, decide whether to enable management endpoints, + pick the JVM and OS user, and configure the secrets backend. Operator + misconfiguration is not a framework vulnerability unless the framework's + default exposed it. + +| External message senders (HTTP clients, JMS producers, file droppers, SMTP + senders, CoAP peers, AMQP publishers, Kafka producers, mail senders, etc.) +| Untrusted +| Send messages into a Camel route over the network or filesystem. This is the + primary attacker model. The framework must not turn an untrusted message into + code execution, file read, request forgery or authentication bypass on its + own. +|=== + +=== Trust boundaries + +The fundamental trust boundary in Camel is between *the route* (and everything +the operator configured) and *the data flowing through the route*. Anything a +route author wrote is trusted code; anything that arrives in an `Exchange` +body, header or attachment from a Camel consumer is untrusted data. + +The framework's job is to keep that boundary intact: untrusted data must not +become code, must not redirect the route to a different endpoint, must not be +deserialised into arbitrary types, and must not be parsed in ways that resolve +remote resources, unless the route author explicitly asked for it. + +== Vulnerability scope + +A report is in scope when it demonstrates that the framework, in a default or +reasonably-expected configuration, lets untrusted input cross a trust boundary +that the model says it should not cross. + +=== In-scope vulnerability classes + +The classes below are grounded in advisories the Apache Camel PMC has accepted +in the past. The CVE IDs in each item are representative examples, not an +exhaustive list. The full advisory history is at +https://camel.apache.org/security/[]. + +==== Unsafe deserialization of untrusted input + +Any code path where data received from an external producer is passed to +`ObjectInputStream.readObject()`, an XStream / Hessian / Castor / SnakeYAML +unmarshaller, or a polymorphic Jackson reader without an effective filter or +allowlist. + +Historical examples: + +* CVE-2015-5344 (`camel-xstream`), CVE-2017-3159 (`camel-snakeyaml`), + CVE-2017-12633 (`camel-hessian`), CVE-2017-12634 (`camel-castor`) - + data-format components performing untrusted-type deserialisation. +* CVE-2016-8749 (`camel-jackson`) - attacker-controlled + `CamelJacksonUnmarshalType` header selecting the deserialised type. +* CVE-2015-5348 (`camel-jetty`, `camel-servlet`) - HTTP consumer auto-detecting + `application/x-java-serialized-object` and deserialising the body. +* CVE-2020-11972 (`camel-rabbitmq`), CVE-2020-11973 (`camel-netty`) - Java + deserialisation enabled in the default consumer configuration. +* CVE-2024-22369 (`camel-sql`), CVE-2024-23114 (`camel-cassandraql`), + CVE-2026-25747 (`camel-leveldb`), CVE-2026-27172 (`camel-consul`), + CVE-2026-40858 (`camel-infinispan`) - aggregation repositories doing raw + `ObjectInputStream.readObject()` on persisted state. +* CVE-2026-40048 (`camel-pqc`) - file-backed key store deserialising `.key` + files. +* CVE-2026-40473 (`camel-mina`) - TCP/UDP type converter wrapping incoming + bytes in `ObjectInputStream`. +* CVE-2026-40860 (`camel-jms`, `camel-sjms`, `camel-sjms2`, `camel-amqp`) - + `JmsBinding.extractBodyFromJms()` calling `ObjectMessage.getObject()` with no + filter while `mapJmsMessage=true` (the default). + +==== XML external entity (XXE) and remote DTD/stylesheet resolution + +Any XML parser, XSLT engine, XSD validator, XPath evaluator or XML data +converter that resolves external entities or fetches remote DTDs / stylesheets +from untrusted input by default. + +Historical examples: CVE-2014-0002 and CVE-2014-0003 (`camel-xslt`), +CVE-2015-0263 (XML converter in `camel-core`), CVE-2015-0264 (XPath language in +`camel-core`), CVE-2017-5643 (Validation component), CVE-2018-8027 +(XSD validation processor), CVE-2019-0188 (`camel-xmljson` via `json-lib`). + +==== Expression or template language injection + +Any code path where untrusted input is evaluated as a Camel `simple` expression +or a template language (Velocity, Freemarker, Mustache, MVEL, etc.) without an +explicit opt-in from the route author. + +Historical examples: CVE-2013-4330 (`CamelFileName` header value being passed +to `simple` by the producer in `camel-file` / `camel-ftp`), CVE-2020-11994 +(template injection plus arbitrary file disclosure in templating components). + +NOTE: A route author who writes `.simple("${header.x}")` against an +attacker-controlled header _is_ injecting code, but the framework cannot decide +on their behalf whether `header.x` is trusted. That case is route-author +responsibility, not a framework vulnerability. The in-scope case is when the +framework itself passes untrusted input to an evaluator without the route +author asking for it. + +==== Path traversal + +Any consumer or producer that lets an untrusted file name, header or URI +component navigate outside the configured root directory. + +Historical examples: CVE-2018-8041 (`camel-mail`), CVE-2019-0194 +(`camel-file`). + +==== SSRF or remote-resource fetch triggered by parsing + +Any parser that resolves a URL or DTD reference from untrusted input as part of +its default parsing behaviour. + +Historical example: CVE-2017-5643 (Validation component fetching remote DTDs). + +==== Camel-header / bean-dispatch abuse via untrusted input + +Camel uses internal headers - `CamelBeanMethodName`, `CamelFileName`, +`CamelExecCommandExecutable`, `CamelJmsDestinationName`, +`CamelHttpUri`, `CamelJacksonUnmarshalType` and others - to drive component +behaviour. Any consumer that maps untrusted input into the `Exchange` header +map without a strict, case-insensitive `HeaderFilterStrategy` becomes an +injection vector for these headers. + +Historical examples: CVE-2025-27636, CVE-2025-29891 (default HTTP +`HeaderFilterStrategy` bypass), CVE-2025-30177 (`camel-undertow` inbound +filter), CVE-2026-33453 (`camel-coap`), CVE-2026-33454 (`camel-mail`), +CVE-2026-40453 (`camel-jms`, `camel-sjms`, `camel-coap`, `camel-google-pubsub` +case-variant follow-on). + +==== Authentication or authorization bypass in security-providing components + +Components that explicitly provide authentication, authorization, or tenant +isolation (Keycloak, JWT, Shiro, Spring Security, platform-http auth handlers, +etc.) must enforce what they claim to enforce. + +Historical examples: CVE-2026-23552 (`camel-keycloak` not validating the JWT +`iss` claim against the configured realm), CVE-2026-40022 +(`camel-platform-http-main` Vert.x sub-router mounted at `<path>*` while the +auth handler was at the exact path, exposing subpaths of `/api`, `/admin`, +`/observe/info`). + +==== Information disclosure of secrets or sensitive Exchange state + +Code paths that write secrets, internal Exchange state, file contents or +configuration values to a log, an event, a world-readable file, or an HTTP +response. + +Historical examples: CVE-2023-34442 (`camel-jira` writing attachments to +world-readable temp files), CVE-2024-22371 (`EventFactory` exposing sensitive +Exchange data via a custom event). + +==== Insecure defaults + +A component shipping with a security-relevant option enabled by default - Java +deserialisation, TLS validation disabled, an admin endpoint listening on +`0.0.0.0`, a permissive `HeaderFilterStrategy`, an unfiltered +`ObjectInputStream` - is in scope independently of the underlying class. The +question is what an attacker can do against a component the operator simply +added to a route without further configuration. + +Historical examples: CVE-2020-11972, CVE-2020-11973 and CVE-2026-40860 are all +insecure-default cases that also fall into the deserialisation class. + +==== Injection into back-end queries built by Camel + +Components that build a query in another language from inputs they receive +must not splice untrusted input directly into that query. + +Historical examples: CVE-2025-66169 (`camel-neo4j` Cypher injection), +CVE-2014-0003 (`camel-xslt` extension-function invocation from untrusted +stylesheet input). + +=== Out of scope + +The following are *not* framework vulnerabilities. They are intentional design, +operator responsibility, or downstream misuse. Reports in these categories will +be closed as `not a vulnerability`. + +* *A route author writing code that does whatever they want.* `.bean()`, + `.process()`, `Runtime.exec()`, `simple` / `groovy` / `jexl` / `mvel` + evaluation, custom processors and beans are route code, and route code is + trusted. If a route author evaluates an attacker-controlled header as a + `simple` expression, the route is at fault, not the framework. The framework + is in scope only when *it* passes untrusted input to an evaluator without the + route author asking for it. +* *A route author building a SQL, Cypher, LDAP, XPath or HTTP URI string from + untrusted input without parameterisation.* The components offer safe APIs + (parameter binding, prepared statements, URI builders); using them is the + route author's responsibility. +* *An option whose risk is documented and which must be set explicitly to + enable the risky behaviour.* `allowJavaSerializedObject=true`, + `transferException=true`, `trustAllCertificates=true`, + `hostnameVerificationEnabled=false`, explicit selection of an + `ObjectInputStream`-using data format - these are documented opt-ins and the + operator has signed up for the consequences. +* *Denial of service via resource exhaustion.* Unthrottled routes, unbounded + aggregators, an HTTP consumer with no rate limit, a JMS consumer that + accepts arbitrarily large messages - operators must apply `throttle`, + `circuitBreaker`, `resilience4j`, JVM heap limits, and the relevant + component-level options. Algorithmic-complexity attacks in third-party + libraries are reported to the upstream project unless Camel exposes the + parser in a way that bypasses the library's own limits. +* *A deployer placing `camel-management`, the developer console, + `camel-jolokia`, JMX or another management surface on a public network.* + These are management surfaces; they assume a trusted network. +* *Vulnerabilities in third-party transitive dependencies that are not + reachable through any Camel-exposed code path.* See + https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the + upstream project for the actual CVE. +* *Self-XSS by an authenticated user* of a UI built on top of Camel. +* *Reports from automated scanners that do not demonstrate a concrete + trust-boundary breach.* "Component X uses class Y that has historically had + CVEs" is not, by itself, a finding. The report must show that the code path + is reachable from an untrusted source and that the trust boundary is crossed. + +=== Known limitations + +These are framework characteristics that look like vulnerabilities at first +glance but are documented design points. They may be tightened over time; if +they are, the change is announced through the normal upgrade-guide channel. + +* *Some heritage components default to permissive settings.* FTP, plain SMTP, + `mapJmsMessage=true` and similar are kept compatible with how they have + always behaved. Where the project has decided to tighten a default, the + change ships with an upgrade-guide entry and a corresponding CVE if the prior + default was a security risk in a default-installed deployment. +* *Bean-based dispatch via internal headers is intentional.* Headers like + `CamelBeanMethodName`, `CamelFileName`, `CamelExecCommandExecutable` and + `CamelJmsDestinationName` are the public contract for letting a route control + component behaviour. Route authors must filter Camel-internal headers from + untrusted producers (see _Deployment hardening_ below); component authors + must apply a strict `HeaderFilterStrategy` on the inbound path. +* *Aggregation repositories that persist Java objects assume the backing store + is trusted.* JDBC, Cassandra, Infinispan, LevelDB, Consul and similar + repositories are state stores for routes the operator wrote; the operator is + responsible for keeping write access to that store inside the trust boundary. +* *Many components inherit the security posture of their underlying client.* + `camel-jms` inherits JMS-broker client behaviour; `camel-kafka` inherits + Kafka-client behaviour; cloud SDK components inherit the SDK's TLS and auth + defaults. A report against Camel must show the framework, not the underlying + client, is the cause. + +== Deployment hardening + +Operators are responsible for the following. None of these are framework +vulnerabilities if skipped; all of them reduce the attack surface materially. + +* *Enable the security policy framework.* Set `camel.main.profile = prod` so + the default policy for the four categories (`secret`, `insecure:ssl`, + `insecure:serialization`, `insecure:dev`) defaults to `fail`. Override + individual categories explicitly when a deployment genuinely needs the + relaxed behaviour. See the `proposals/security.adoc` design document for + details. +* *Resolve secrets through a vault.* Use one of the supported backends + (xref:security.adoc[AWS Secrets Manager, Azure Key Vault, Google Secret + Manager, HashiCorp Vault, IBM Secrets Manager, CyberArk Conjur]) rather than + plain-text values in property files. +* *Configure TLS through the JSSE Utility.* Use + xref:camel-configuration-utilities.adoc[`SSLContextParameters`] to set the + trust store, key store, ciphers and protocols explicitly. Do not use + `trustAllCertificates=true` or `hostnameVerificationEnabled=false` in + production. +* *Strip Camel-internal headers at the trust boundary.* When a consumer + receives messages from an untrusted producer, remove Camel-controlled + headers before the message reaches any dispatching processor: ++ +[source,java] +---- +from("jetty:http://0.0.0.0:8080/api";) + .removeHeaders("Camel*") + .removeHeaders("org.apache.camel.*") Review Comment: the org.apache.camel header are very old from Camel v1. We no longer have that, this can be removed. There may indeed be some old header filter code still with this pattern, but we should actually remove that there (if present) ########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -0,0 +1,410 @@ += Security Model + +This page documents Apache Camel's security model: who is trusted, where the +trust boundaries sit, what counts as a framework vulnerability, and what is +expected of operators and route authors. It is the reference used by the Camel +PMC when triaging security reports and by the project when deciding whether a +behaviour should be hardened in the framework or addressed by the deployment. + +It complements two existing documents: + +* xref:security.adoc[Security] - the user-facing catalog of security features + (route, payload, endpoint and configuration security, vaults, JSSE). +* The `proposals/security.adoc` design document in the repository - the + annotation-driven security policy enforcement framework that detects insecure + configuration at startup time. + +For instructions on how to report a vulnerability, see +https://camel.apache.org/security/[Apache Camel Security] and the repository +`SECURITY.md` file. + +== Audience + +This document is written for four audiences: + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a framework vulnerability before submitting a report. +* *Automated triage tooling* (CVE scanners, AI-assisted security review) that + needs an authoritative scope statement to distinguish a real framework + vulnerability from an intentional, documented design choice. +* *Camel committers and component authors* reviewing pull requests and writing + new components, who need to know which defaults and patterns are acceptable. +* *Operators and deployment owners* who need to know how to deploy Camel + applications safely and which hardening responsibilities the framework + delegates to them. + +== Trust model + +Camel is an integration framework that is embedded in someone else's +application, not a multi-tenant managed service. Its trust model reflects that. + +=== Roles + +[cols="1,1,3"] +|=== +| Role | Trust level | What this role can do + +| Camel committers and component authors +| Trusted +| Define APIs, write components, choose defaults, publish releases. The + framework relies on these contributors to ship secure defaults. + +| Route authors (the people writing Camel routes in Java, XML or YAML DSL) +| Fully trusted +| Execute arbitrary Java code in `.bean()`, `.process()` and `Class` references; + evaluate arbitrary expressions in `simple`, `groovy`, `jexl`, `mvel`, `xpath`, + `ognl` and friends; reach any class on the classpath; configure any component + option. Code execution by a route author is by design and is not a + vulnerability in the framework. + +| Deployment operators (the people who configure and deploy a Camel + application) +| Fully trusted +| Set configuration properties (including secrets), choose the runtime, decide + what to expose on the network, decide whether to enable management endpoints, + pick the JVM and OS user, and configure the secrets backend. Operator + misconfiguration is not a framework vulnerability unless the framework's + default exposed it. + +| External message senders (HTTP clients, JMS producers, file droppers, SMTP + senders, CoAP peers, AMQP publishers, Kafka producers, mail senders, etc.) +| Untrusted +| Send messages into a Camel route over the network or filesystem. This is the + primary attacker model. The framework must not turn an untrusted message into + code execution, file read, request forgery or authentication bypass on its + own. +|=== + +=== Trust boundaries + +The fundamental trust boundary in Camel is between *the route* (and everything +the operator configured) and *the data flowing through the route*. Anything a +route author wrote is trusted code; anything that arrives in an `Exchange` +body, header or attachment from a Camel consumer is untrusted data. + +The framework's job is to keep that boundary intact: untrusted data must not +become code, must not redirect the route to a different endpoint, must not be +deserialised into arbitrary types, and must not be parsed in ways that resolve +remote resources, unless the route author explicitly asked for it. + +== Vulnerability scope + +A report is in scope when it demonstrates that the framework, in a default or +reasonably-expected configuration, lets untrusted input cross a trust boundary +that the model says it should not cross. + +=== In-scope vulnerability classes + +The classes below are grounded in advisories the Apache Camel PMC has accepted +in the past. The CVE IDs in each item are representative examples, not an +exhaustive list. The full advisory history is at +https://camel.apache.org/security/[]. + +==== Unsafe deserialization of untrusted input + +Any code path where data received from an external producer is passed to +`ObjectInputStream.readObject()`, an XStream / Hessian / Castor / SnakeYAML +unmarshaller, or a polymorphic Jackson reader without an effective filter or +allowlist. + +Historical examples: + +* CVE-2015-5344 (`camel-xstream`), CVE-2017-3159 (`camel-snakeyaml`), + CVE-2017-12633 (`camel-hessian`), CVE-2017-12634 (`camel-castor`) - + data-format components performing untrusted-type deserialisation. +* CVE-2016-8749 (`camel-jackson`) - attacker-controlled + `CamelJacksonUnmarshalType` header selecting the deserialised type. +* CVE-2015-5348 (`camel-jetty`, `camel-servlet`) - HTTP consumer auto-detecting + `application/x-java-serialized-object` and deserialising the body. +* CVE-2020-11972 (`camel-rabbitmq`), CVE-2020-11973 (`camel-netty`) - Java + deserialisation enabled in the default consumer configuration. +* CVE-2024-22369 (`camel-sql`), CVE-2024-23114 (`camel-cassandraql`), + CVE-2026-25747 (`camel-leveldb`), CVE-2026-27172 (`camel-consul`), + CVE-2026-40858 (`camel-infinispan`) - aggregation repositories doing raw + `ObjectInputStream.readObject()` on persisted state. +* CVE-2026-40048 (`camel-pqc`) - file-backed key store deserialising `.key` + files. +* CVE-2026-40473 (`camel-mina`) - TCP/UDP type converter wrapping incoming + bytes in `ObjectInputStream`. +* CVE-2026-40860 (`camel-jms`, `camel-sjms`, `camel-sjms2`, `camel-amqp`) - + `JmsBinding.extractBodyFromJms()` calling `ObjectMessage.getObject()` with no + filter while `mapJmsMessage=true` (the default). + +==== XML external entity (XXE) and remote DTD/stylesheet resolution + +Any XML parser, XSLT engine, XSD validator, XPath evaluator or XML data +converter that resolves external entities or fetches remote DTDs / stylesheets +from untrusted input by default. + +Historical examples: CVE-2014-0002 and CVE-2014-0003 (`camel-xslt`), +CVE-2015-0263 (XML converter in `camel-core`), CVE-2015-0264 (XPath language in +`camel-core`), CVE-2017-5643 (Validation component), CVE-2018-8027 +(XSD validation processor), CVE-2019-0188 (`camel-xmljson` via `json-lib`). + +==== Expression or template language injection + +Any code path where untrusted input is evaluated as a Camel `simple` expression +or a template language (Velocity, Freemarker, Mustache, MVEL, etc.) without an +explicit opt-in from the route author. + +Historical examples: CVE-2013-4330 (`CamelFileName` header value being passed +to `simple` by the producer in `camel-file` / `camel-ftp`), CVE-2020-11994 +(template injection plus arbitrary file disclosure in templating components). + +NOTE: A route author who writes `.simple("${header.x}")` against an +attacker-controlled header _is_ injecting code, but the framework cannot decide +on their behalf whether `header.x` is trusted. That case is route-author +responsibility, not a framework vulnerability. The in-scope case is when the +framework itself passes untrusted input to an evaluator without the route +author asking for it. + +==== Path traversal + +Any consumer or producer that lets an untrusted file name, header or URI +component navigate outside the configured root directory. + +Historical examples: CVE-2018-8041 (`camel-mail`), CVE-2019-0194 +(`camel-file`). + +==== SSRF or remote-resource fetch triggered by parsing + +Any parser that resolves a URL or DTD reference from untrusted input as part of +its default parsing behaviour. + +Historical example: CVE-2017-5643 (Validation component fetching remote DTDs). + +==== Camel-header / bean-dispatch abuse via untrusted input + +Camel uses internal headers - `CamelBeanMethodName`, `CamelFileName`, +`CamelExecCommandExecutable`, `CamelJmsDestinationName`, +`CamelHttpUri`, `CamelJacksonUnmarshalType` and others - to drive component +behaviour. Any consumer that maps untrusted input into the `Exchange` header +map without a strict, case-insensitive `HeaderFilterStrategy` becomes an +injection vector for these headers. + +Historical examples: CVE-2025-27636, CVE-2025-29891 (default HTTP +`HeaderFilterStrategy` bypass), CVE-2025-30177 (`camel-undertow` inbound +filter), CVE-2026-33453 (`camel-coap`), CVE-2026-33454 (`camel-mail`), +CVE-2026-40453 (`camel-jms`, `camel-sjms`, `camel-coap`, `camel-google-pubsub` +case-variant follow-on). + +==== Authentication or authorization bypass in security-providing components + +Components that explicitly provide authentication, authorization, or tenant +isolation (Keycloak, JWT, Shiro, Spring Security, platform-http auth handlers, +etc.) must enforce what they claim to enforce. + +Historical examples: CVE-2026-23552 (`camel-keycloak` not validating the JWT +`iss` claim against the configured realm), CVE-2026-40022 +(`camel-platform-http-main` Vert.x sub-router mounted at `<path>*` while the +auth handler was at the exact path, exposing subpaths of `/api`, `/admin`, +`/observe/info`). + +==== Information disclosure of secrets or sensitive Exchange state + +Code paths that write secrets, internal Exchange state, file contents or +configuration values to a log, an event, a world-readable file, or an HTTP +response. + +Historical examples: CVE-2023-34442 (`camel-jira` writing attachments to +world-readable temp files), CVE-2024-22371 (`EventFactory` exposing sensitive +Exchange data via a custom event). + +==== Insecure defaults + +A component shipping with a security-relevant option enabled by default - Java +deserialisation, TLS validation disabled, an admin endpoint listening on +`0.0.0.0`, a permissive `HeaderFilterStrategy`, an unfiltered +`ObjectInputStream` - is in scope independently of the underlying class. The +question is what an attacker can do against a component the operator simply +added to a route without further configuration. + +Historical examples: CVE-2020-11972, CVE-2020-11973 and CVE-2026-40860 are all +insecure-default cases that also fall into the deserialisation class. + +==== Injection into back-end queries built by Camel + +Components that build a query in another language from inputs they receive +must not splice untrusted input directly into that query. + +Historical examples: CVE-2025-66169 (`camel-neo4j` Cypher injection), +CVE-2014-0003 (`camel-xslt` extension-function invocation from untrusted +stylesheet input). + +=== Out of scope + +The following are *not* framework vulnerabilities. They are intentional design, +operator responsibility, or downstream misuse. Reports in these categories will +be closed as `not a vulnerability`. + +* *A route author writing code that does whatever they want.* `.bean()`, + `.process()`, `Runtime.exec()`, `simple` / `groovy` / `jexl` / `mvel` + evaluation, custom processors and beans are route code, and route code is + trusted. If a route author evaluates an attacker-controlled header as a + `simple` expression, the route is at fault, not the framework. The framework + is in scope only when *it* passes untrusted input to an evaluator without the + route author asking for it. +* *A route author building a SQL, Cypher, LDAP, XPath or HTTP URI string from + untrusted input without parameterisation.* The components offer safe APIs + (parameter binding, prepared statements, URI builders); using them is the + route author's responsibility. +* *An option whose risk is documented and which must be set explicitly to + enable the risky behaviour.* `allowJavaSerializedObject=true`, + `transferException=true`, `trustAllCertificates=true`, + `hostnameVerificationEnabled=false`, explicit selection of an + `ObjectInputStream`-using data format - these are documented opt-ins and the + operator has signed up for the consequences. +* *Denial of service via resource exhaustion.* Unthrottled routes, unbounded + aggregators, an HTTP consumer with no rate limit, a JMS consumer that + accepts arbitrarily large messages - operators must apply `throttle`, + `circuitBreaker`, `resilience4j`, JVM heap limits, and the relevant + component-level options. Algorithmic-complexity attacks in third-party + libraries are reported to the upstream project unless Camel exposes the + parser in a way that bypasses the library's own limits. +* *A deployer placing `camel-management`, the developer console, + `camel-jolokia`, JMX or another management surface on a public network.* + These are management surfaces; they assume a trusted network. +* *Vulnerabilities in third-party transitive dependencies that are not + reachable through any Camel-exposed code path.* See + https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the + upstream project for the actual CVE. +* *Self-XSS by an authenticated user* of a UI built on top of Camel. +* *Reports from automated scanners that do not demonstrate a concrete + trust-boundary breach.* "Component X uses class Y that has historically had + CVEs" is not, by itself, a finding. The report must show that the code path + is reachable from an untrusted source and that the trust boundary is crossed. + +=== Known limitations + +These are framework characteristics that look like vulnerabilities at first +glance but are documented design points. They may be tightened over time; if +they are, the change is announced through the normal upgrade-guide channel. + +* *Some heritage components default to permissive settings.* FTP, plain SMTP, + `mapJmsMessage=true` and similar are kept compatible with how they have + always behaved. Where the project has decided to tighten a default, the + change ships with an upgrade-guide entry and a corresponding CVE if the prior + default was a security risk in a default-installed deployment. +* *Bean-based dispatch via internal headers is intentional.* Headers like + `CamelBeanMethodName`, `CamelFileName`, `CamelExecCommandExecutable` and + `CamelJmsDestinationName` are the public contract for letting a route control + component behaviour. Route authors must filter Camel-internal headers from + untrusted producers (see _Deployment hardening_ below); component authors + must apply a strict `HeaderFilterStrategy` on the inbound path. +* *Aggregation repositories that persist Java objects assume the backing store + is trusted.* JDBC, Cassandra, Infinispan, LevelDB, Consul and similar + repositories are state stores for routes the operator wrote; the operator is + responsible for keeping write access to that store inside the trust boundary. +* *Many components inherit the security posture of their underlying client.* + `camel-jms` inherits JMS-broker client behaviour; `camel-kafka` inherits + Kafka-client behaviour; cloud SDK components inherit the SDK's TLS and auth + defaults. A report against Camel must show the framework, not the underlying + client, is the cause. + +== Deployment hardening + +Operators are responsible for the following. None of these are framework +vulnerabilities if skipped; all of them reduce the attack surface materially. + +* *Enable the security policy framework.* Set `camel.main.profile = prod` so + the default policy for the four categories (`secret`, `insecure:ssl`, + `insecure:serialization`, `insecure:dev`) defaults to `fail`. Override + individual categories explicitly when a deployment genuinely needs the + relaxed behaviour. See the `proposals/security.adoc` design document for + details. +* *Resolve secrets through a vault.* Use one of the supported backends + (xref:security.adoc[AWS Secrets Manager, Azure Key Vault, Google Secret + Manager, HashiCorp Vault, IBM Secrets Manager, CyberArk Conjur]) rather than + plain-text values in property files. +* *Configure TLS through the JSSE Utility.* Use + xref:camel-configuration-utilities.adoc[`SSLContextParameters`] to set the + trust store, key store, ciphers and protocols explicitly. Do not use + `trustAllCertificates=true` or `hostnameVerificationEnabled=false` in + production. +* *Strip Camel-internal headers at the trust boundary.* When a consumer + receives messages from an untrusted producer, remove Camel-controlled + headers before the message reaches any dispatching processor: ++ +[source,java] +---- +from("jetty:http://0.0.0.0:8080/api";) + .removeHeaders("Camel*") + .removeHeaders("org.apache.camel.*") + .to("direct:trusted-pipeline"); +---- +* *Do not enable Java serialisation on consumers exposed to untrusted + networks.* In particular, do not set `allowJavaSerializedObject=true`, + `transferException=true`, or `mapJmsMessage=true` on a JMS consumer when the + upstream broker is not inside the trust boundary. If the option is + unavoidable, install an `ObjectInputFilter`. +* *Do not expose management surfaces.* `camel-management`, the developer + console, `camel-jolokia` and JMX should listen on a loopback interface, a + sidecar, or a separate network only. +* *Keep components patched.* Pin Camel to a supported version, subscribe to + the announce list, and respond to advisories at + https://camel.apache.org/security/[]. +* *Run with least privilege.* Limit the OS user's file-system, network and + process privileges; in a container deployment, drop unneeded capabilities + and mount only the filesystem paths the routes actually need. + +== Guidance for component authors and reviewers + +When writing a new component or reviewing a pull request that touches an +existing one, the following questions decide whether the change is in line +with the security model. + +* *Does the component consume untrusted input?* If yes, the inbound side must + apply a `HeaderFilterStrategy` that blocks `Camel*`, `camel*`, + `org.apache.camel.*` and any internal headers the component itself uses, + case-insensitively. +* *Does the component deserialise into a Java object?* If it uses + `ObjectInputStream.readObject()`, an XStream-style unmarshaller or a + polymorphic Jackson reader on input the operator did not explicitly control, + the default must be safe: either an `ObjectInputFilter` is installed, the + feature is opt-in only, or the component refuses to deserialise unknown + types. +* *Does a `@UriParam` control a security-relevant default?* Mark it with the + appropriate `security = "insecure:*"` attribute so the policy enforcement + framework can warn or fail on it. The four categories are `secret`, + `insecure:ssl`, `insecure:serialization`, `insecure:dev`. See + `proposals/security.adoc`. +* *Does the component persist state?* Aggregation repositories, idempotent + repositories and similar must not call `ObjectInputStream.readObject()` + without an `ObjectInputFilter`; the project has accepted five sequential + advisories (CVE-2024-22369, CVE-2024-23114, CVE-2026-25747, CVE-2026-27172, + CVE-2026-40858) for this exact pattern. +* *Does the component provide authentication or authorization?* It must + enforce what its option names claim - validate token issuers, audiences and + signatures; cover every sub-path the matching handler advertises; fail + closed. +* *Does the change relax a default?* New defaults err toward "denied unless + opted in" for the four `security` categories. If a default must be relaxed, + the change requires a corresponding upgrade-guide entry and PMC review. + +== Reporting a vulnerability + +The Apache Camel project uses the standard ASF vulnerability reporting +process: + +* Read https://camel.apache.org/security/[Apache Camel Security]. +* Email [email protected] with a description, affected + versions, and a proof of concept that demonstrates the trust-boundary breach. +* Do not file a public Jira ticket or open a public pull request for an Review Comment: ... and avoid disclousing anything about the potential vulnerability anywhere in the public internet or elsewhere. Only contact the Security from Apache Software Foundation (https://apache.org/security/) to report and follow their instructions . ########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -0,0 +1,410 @@ += Security Model + +This page documents Apache Camel's security model: who is trusted, where the +trust boundaries sit, what counts as a framework vulnerability, and what is +expected of operators and route authors. It is the reference used by the Camel +PMC when triaging security reports and by the project when deciding whether a +behaviour should be hardened in the framework or addressed by the deployment. + +It complements two existing documents: + +* xref:security.adoc[Security] - the user-facing catalog of security features + (route, payload, endpoint and configuration security, vaults, JSSE). +* The `proposals/security.adoc` design document in the repository - the + annotation-driven security policy enforcement framework that detects insecure + configuration at startup time. + +For instructions on how to report a vulnerability, see +https://camel.apache.org/security/[Apache Camel Security] and the repository +`SECURITY.md` file. + +== Audience + +This document is written for four audiences: + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a framework vulnerability before submitting a report. +* *Automated triage tooling* (CVE scanners, AI-assisted security review) that + needs an authoritative scope statement to distinguish a real framework + vulnerability from an intentional, documented design choice. +* *Camel committers and component authors* reviewing pull requests and writing + new components, who need to know which defaults and patterns are acceptable. +* *Operators and deployment owners* who need to know how to deploy Camel + applications safely and which hardening responsibilities the framework + delegates to them. + +== Trust model + +Camel is an integration framework that is embedded in someone else's +application, not a multi-tenant managed service. Its trust model reflects that. + +=== Roles + +[cols="1,1,3"] +|=== +| Role | Trust level | What this role can do + +| Camel committers and component authors +| Trusted +| Define APIs, write components, choose defaults, publish releases. The + framework relies on these contributors to ship secure defaults. + +| Route authors (the people writing Camel routes in Java, XML or YAML DSL) +| Fully trusted +| Execute arbitrary Java code in `.bean()`, `.process()` and `Class` references; + evaluate arbitrary expressions in `simple`, `groovy`, `jexl`, `mvel`, `xpath`, + `ognl` and friends; reach any class on the classpath; configure any component + option. Code execution by a route author is by design and is not a + vulnerability in the framework. + +| Deployment operators (the people who configure and deploy a Camel + application) +| Fully trusted +| Set configuration properties (including secrets), choose the runtime, decide + what to expose on the network, decide whether to enable management endpoints, + pick the JVM and OS user, and configure the secrets backend. Operator + misconfiguration is not a framework vulnerability unless the framework's + default exposed it. + +| External message senders (HTTP clients, JMS producers, file droppers, SMTP + senders, CoAP peers, AMQP publishers, Kafka producers, mail senders, etc.) +| Untrusted +| Send messages into a Camel route over the network or filesystem. This is the + primary attacker model. The framework must not turn an untrusted message into + code execution, file read, request forgery or authentication bypass on its + own. +|=== + +=== Trust boundaries + +The fundamental trust boundary in Camel is between *the route* (and everything +the operator configured) and *the data flowing through the route*. Anything a +route author wrote is trusted code; anything that arrives in an `Exchange` +body, header or attachment from a Camel consumer is untrusted data. + +The framework's job is to keep that boundary intact: untrusted data must not +become code, must not redirect the route to a different endpoint, must not be +deserialised into arbitrary types, and must not be parsed in ways that resolve +remote resources, unless the route author explicitly asked for it. + +== Vulnerability scope + +A report is in scope when it demonstrates that the framework, in a default or +reasonably-expected configuration, lets untrusted input cross a trust boundary +that the model says it should not cross. + +=== In-scope vulnerability classes + +The classes below are grounded in advisories the Apache Camel PMC has accepted +in the past. The CVE IDs in each item are representative examples, not an +exhaustive list. The full advisory history is at +https://camel.apache.org/security/[]. + +==== Unsafe deserialization of untrusted input + +Any code path where data received from an external producer is passed to +`ObjectInputStream.readObject()`, an XStream / Hessian / Castor / SnakeYAML +unmarshaller, or a polymorphic Jackson reader without an effective filter or +allowlist. + +Historical examples: + +* CVE-2015-5344 (`camel-xstream`), CVE-2017-3159 (`camel-snakeyaml`), + CVE-2017-12633 (`camel-hessian`), CVE-2017-12634 (`camel-castor`) - + data-format components performing untrusted-type deserialisation. +* CVE-2016-8749 (`camel-jackson`) - attacker-controlled + `CamelJacksonUnmarshalType` header selecting the deserialised type. +* CVE-2015-5348 (`camel-jetty`, `camel-servlet`) - HTTP consumer auto-detecting + `application/x-java-serialized-object` and deserialising the body. +* CVE-2020-11972 (`camel-rabbitmq`), CVE-2020-11973 (`camel-netty`) - Java + deserialisation enabled in the default consumer configuration. +* CVE-2024-22369 (`camel-sql`), CVE-2024-23114 (`camel-cassandraql`), + CVE-2026-25747 (`camel-leveldb`), CVE-2026-27172 (`camel-consul`), + CVE-2026-40858 (`camel-infinispan`) - aggregation repositories doing raw + `ObjectInputStream.readObject()` on persisted state. +* CVE-2026-40048 (`camel-pqc`) - file-backed key store deserialising `.key` + files. +* CVE-2026-40473 (`camel-mina`) - TCP/UDP type converter wrapping incoming + bytes in `ObjectInputStream`. +* CVE-2026-40860 (`camel-jms`, `camel-sjms`, `camel-sjms2`, `camel-amqp`) - + `JmsBinding.extractBodyFromJms()` calling `ObjectMessage.getObject()` with no + filter while `mapJmsMessage=true` (the default). + +==== XML external entity (XXE) and remote DTD/stylesheet resolution + +Any XML parser, XSLT engine, XSD validator, XPath evaluator or XML data +converter that resolves external entities or fetches remote DTDs / stylesheets +from untrusted input by default. + +Historical examples: CVE-2014-0002 and CVE-2014-0003 (`camel-xslt`), +CVE-2015-0263 (XML converter in `camel-core`), CVE-2015-0264 (XPath language in +`camel-core`), CVE-2017-5643 (Validation component), CVE-2018-8027 +(XSD validation processor), CVE-2019-0188 (`camel-xmljson` via `json-lib`). + +==== Expression or template language injection + +Any code path where untrusted input is evaluated as a Camel `simple` expression +or a template language (Velocity, Freemarker, Mustache, MVEL, etc.) without an +explicit opt-in from the route author. + +Historical examples: CVE-2013-4330 (`CamelFileName` header value being passed +to `simple` by the producer in `camel-file` / `camel-ftp`), CVE-2020-11994 +(template injection plus arbitrary file disclosure in templating components). + +NOTE: A route author who writes `.simple("${header.x}")` against an +attacker-controlled header _is_ injecting code, but the framework cannot decide +on their behalf whether `header.x` is trusted. That case is route-author +responsibility, not a framework vulnerability. The in-scope case is when the +framework itself passes untrusted input to an evaluator without the route +author asking for it. + +==== Path traversal + +Any consumer or producer that lets an untrusted file name, header or URI +component navigate outside the configured root directory. + +Historical examples: CVE-2018-8041 (`camel-mail`), CVE-2019-0194 +(`camel-file`). + +==== SSRF or remote-resource fetch triggered by parsing + +Any parser that resolves a URL or DTD reference from untrusted input as part of +its default parsing behaviour. + +Historical example: CVE-2017-5643 (Validation component fetching remote DTDs). + +==== Camel-header / bean-dispatch abuse via untrusted input + +Camel uses internal headers - `CamelBeanMethodName`, `CamelFileName`, +`CamelExecCommandExecutable`, `CamelJmsDestinationName`, +`CamelHttpUri`, `CamelJacksonUnmarshalType` and others - to drive component +behaviour. Any consumer that maps untrusted input into the `Exchange` header +map without a strict, case-insensitive `HeaderFilterStrategy` becomes an +injection vector for these headers. + +Historical examples: CVE-2025-27636, CVE-2025-29891 (default HTTP +`HeaderFilterStrategy` bypass), CVE-2025-30177 (`camel-undertow` inbound +filter), CVE-2026-33453 (`camel-coap`), CVE-2026-33454 (`camel-mail`), +CVE-2026-40453 (`camel-jms`, `camel-sjms`, `camel-coap`, `camel-google-pubsub` +case-variant follow-on). + +==== Authentication or authorization bypass in security-providing components + +Components that explicitly provide authentication, authorization, or tenant +isolation (Keycloak, JWT, Shiro, Spring Security, platform-http auth handlers, +etc.) must enforce what they claim to enforce. + +Historical examples: CVE-2026-23552 (`camel-keycloak` not validating the JWT +`iss` claim against the configured realm), CVE-2026-40022 +(`camel-platform-http-main` Vert.x sub-router mounted at `<path>*` while the +auth handler was at the exact path, exposing subpaths of `/api`, `/admin`, +`/observe/info`). + +==== Information disclosure of secrets or sensitive Exchange state + +Code paths that write secrets, internal Exchange state, file contents or +configuration values to a log, an event, a world-readable file, or an HTTP +response. + +Historical examples: CVE-2023-34442 (`camel-jira` writing attachments to +world-readable temp files), CVE-2024-22371 (`EventFactory` exposing sensitive +Exchange data via a custom event). + +==== Insecure defaults + +A component shipping with a security-relevant option enabled by default - Java +deserialisation, TLS validation disabled, an admin endpoint listening on +`0.0.0.0`, a permissive `HeaderFilterStrategy`, an unfiltered +`ObjectInputStream` - is in scope independently of the underlying class. The +question is what an attacker can do against a component the operator simply +added to a route without further configuration. + +Historical examples: CVE-2020-11972, CVE-2020-11973 and CVE-2026-40860 are all +insecure-default cases that also fall into the deserialisation class. + +==== Injection into back-end queries built by Camel + +Components that build a query in another language from inputs they receive +must not splice untrusted input directly into that query. + +Historical examples: CVE-2025-66169 (`camel-neo4j` Cypher injection), +CVE-2014-0003 (`camel-xslt` extension-function invocation from untrusted +stylesheet input). + +=== Out of scope + +The following are *not* framework vulnerabilities. They are intentional design, +operator responsibility, or downstream misuse. Reports in these categories will +be closed as `not a vulnerability`. + +* *A route author writing code that does whatever they want.* `.bean()`, + `.process()`, `Runtime.exec()`, `simple` / `groovy` / `jexl` / `mvel` + evaluation, custom processors and beans are route code, and route code is + trusted. If a route author evaluates an attacker-controlled header as a + `simple` expression, the route is at fault, not the framework. The framework + is in scope only when *it* passes untrusted input to an evaluator without the + route author asking for it. +* *A route author building a SQL, Cypher, LDAP, XPath or HTTP URI string from + untrusted input without parameterisation.* The components offer safe APIs + (parameter binding, prepared statements, URI builders); using them is the + route author's responsibility. +* *An option whose risk is documented and which must be set explicitly to + enable the risky behaviour.* `allowJavaSerializedObject=true`, + `transferException=true`, `trustAllCertificates=true`, + `hostnameVerificationEnabled=false`, explicit selection of an + `ObjectInputStream`-using data format - these are documented opt-ins and the + operator has signed up for the consequences. +* *Denial of service via resource exhaustion.* Unthrottled routes, unbounded + aggregators, an HTTP consumer with no rate limit, a JMS consumer that + accepts arbitrarily large messages - operators must apply `throttle`, + `circuitBreaker`, `resilience4j`, JVM heap limits, and the relevant + component-level options. Algorithmic-complexity attacks in third-party + libraries are reported to the upstream project unless Camel exposes the + parser in a way that bypasses the library's own limits. +* *A deployer placing `camel-management`, the developer console, + `camel-jolokia`, JMX or another management surface on a public network.* + These are management surfaces; they assume a trusted network. +* *Vulnerabilities in third-party transitive dependencies that are not + reachable through any Camel-exposed code path.* See + https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the + upstream project for the actual CVE. +* *Self-XSS by an authenticated user* of a UI built on top of Camel. +* *Reports from automated scanners that do not demonstrate a concrete + trust-boundary breach.* "Component X uses class Y that has historically had + CVEs" is not, by itself, a finding. The report must show that the code path + is reachable from an untrusted source and that the trust boundary is crossed. + +=== Known limitations + +These are framework characteristics that look like vulnerabilities at first +glance but are documented design points. They may be tightened over time; if +they are, the change is announced through the normal upgrade-guide channel. + +* *Some heritage components default to permissive settings.* FTP, plain SMTP, + `mapJmsMessage=true` and similar are kept compatible with how they have + always behaved. Where the project has decided to tighten a default, the + change ships with an upgrade-guide entry and a corresponding CVE if the prior + default was a security risk in a default-installed deployment. +* *Bean-based dispatch via internal headers is intentional.* Headers like + `CamelBeanMethodName`, `CamelFileName`, `CamelExecCommandExecutable` and + `CamelJmsDestinationName` are the public contract for letting a route control + component behaviour. Route authors must filter Camel-internal headers from + untrusted producers (see _Deployment hardening_ below); component authors + must apply a strict `HeaderFilterStrategy` on the inbound path. +* *Aggregation repositories that persist Java objects assume the backing store + is trusted.* JDBC, Cassandra, Infinispan, LevelDB, Consul and similar + repositories are state stores for routes the operator wrote; the operator is + responsible for keeping write access to that store inside the trust boundary. +* *Many components inherit the security posture of their underlying client.* + `camel-jms` inherits JMS-broker client behaviour; `camel-kafka` inherits + Kafka-client behaviour; cloud SDK components inherit the SDK's TLS and auth + defaults. A report against Camel must show the framework, not the underlying + client, is the cause. + +== Deployment hardening + +Operators are responsible for the following. None of these are framework +vulnerabilities if skipped; all of them reduce the attack surface materially. + +* *Enable the security policy framework.* Set `camel.main.profile = prod` so + the default policy for the four categories (`secret`, `insecure:ssl`, + `insecure:serialization`, `insecure:dev`) defaults to `fail`. Override + individual categories explicitly when a deployment genuinely needs the + relaxed behaviour. See the `proposals/security.adoc` design document for + details. +* *Resolve secrets through a vault.* Use one of the supported backends + (xref:security.adoc[AWS Secrets Manager, Azure Key Vault, Google Secret + Manager, HashiCorp Vault, IBM Secrets Manager, CyberArk Conjur]) rather than + plain-text values in property files. +* *Configure TLS through the JSSE Utility.* Use + xref:camel-configuration-utilities.adoc[`SSLContextParameters`] to set the + trust store, key store, ciphers and protocols explicitly. Do not use + `trustAllCertificates=true` or `hostnameVerificationEnabled=false` in + production. +* *Strip Camel-internal headers at the trust boundary.* When a consumer + receives messages from an untrusted producer, remove Camel-controlled + headers before the message reaches any dispatching processor: ++ +[source,java] +---- +from("jetty:http://0.0.0.0:8080/api";) + .removeHeaders("Camel*") + .removeHeaders("org.apache.camel.*") + .to("direct:trusted-pipeline"); +---- +* *Do not enable Java serialisation on consumers exposed to untrusted + networks.* In particular, do not set `allowJavaSerializedObject=true`, + `transferException=true`, or `mapJmsMessage=true` on a JMS consumer when the + upstream broker is not inside the trust boundary. If the option is + unavoidable, install an `ObjectInputFilter`. +* *Do not expose management surfaces.* `camel-management`, the developer + console, `camel-jolokia` and JMX should listen on a loopback interface, a + sidecar, or a separate network only. +* *Keep components patched.* Pin Camel to a supported version, subscribe to + the announce list, and respond to advisories at + https://camel.apache.org/security/[]. +* *Run with least privilege.* Limit the OS user's file-system, network and + process privileges; in a container deployment, drop unneeded capabilities + and mount only the filesystem paths the routes actually need. + +== Guidance for component authors and reviewers + +When writing a new component or reviewing a pull request that touches an +existing one, the following questions decide whether the change is in line +with the security model. + +* *Does the component consume untrusted input?* If yes, the inbound side must + apply a `HeaderFilterStrategy` that blocks `Camel*`, `camel*`, Review Comment: same about org.apache.camel as before Also header filter startegy is case agnostic now, so Camel CAMEL caMEL cAmEl are all threaded the same and dropped using the out of the box header filters from Camel. However any custom header filter then make sure to respect this by extending the default header filter strategy to inheirt this feature or make sure to implement this feature as well in your custom header filter strategy code -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
