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:

  • Security - the user-facing catalog of security features (route, payload, endpoint and configuration security, vaults, JSSE).

  • The design/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 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

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.

Adversary model

The adversary the framework defends against is the External message senders role from Roles above: a network or filesystem peer who places a message on a transport that a Camel consumer reads from. This subsection states the attacker shape that the in-scope and out-of-scope rules below presume, so a report can be evaluated against the same model the rules were written for.

What the attacker controls: the body, headers, attachments and transport metadata of a message arriving on an input the consumer reads, plus the ability to replay or shape that message arbitrarily within the protocol’s limits. The attacker may exploit any combination of those inputs against the framework’s own machinery - expression languages, type converters, the Exchange / Message model, the header namespace, the EIP processors, the property-placeholder and bean-reference resolution, and any default parser configuration used by a consumer or data format.

What the attacker is trying to do: break one of the properties listed in Security properties and violation severity or Core router-engine invariants below - turn untrusted input into code execution, an arbitrary file read or write, a request forgery, an unintended endpoint or bean dispatch, a deserialisation gadget, an authentication or authorization bypass, or a disclosure of secrets or Exchange state.

What the attacker is not assumed to have: code execution inside the JVM running the Camel context (that is route-author territory), the operator’s filesystem, the deployment’s configuration source, the secrets vault, the management network, the connection back to the broker / SDK / endpoint, or the keys and credentials the route author and operator configured. They cannot author or modify route definitions, configuration or the runtime image. They cannot side-step the trust boundary by being a co-tenant in the JVM; Camel is not a sandbox and does not pretend to be one (see Security properties not provided below).

The following actors are explicitly not in the adversary model. A report that requires one of them as the attacker is OUT-OF-MODEL: adversary-not-in-scope (see Triage dispositions).

  • Route authors. A route author who evaluates an attacker-controlled header as a simple, OGNL, bean or scripting expression has authored trusted code that does exactly what it says. The framework is in scope only when it passes untrusted input to an evaluator without the route author asking for it (see the route-author entry in Out of scope).

  • Deployment operators. An operator who disables TLS verification, enables Java serialisation, picks a relaxed profile, or exposes a management surface to the public network has signed up for the consequences. Misconfiguration is operator territory unless the framework’s default exposed it.

  • Network peers reaching a management surface. camel-management, the developer console, camel-jolokia and JMX are administrative APIs whose trust boundary is the management surface itself (JVM JMX authentication, the Jolokia restrictor policy, the network exposure of the management port), not the individual MBean method. See the management-surface entry in Out of scope.

  • Authors of transitive third-party dependencies. A CVE in a JAR Camel pulls in but does not reach through any Camel-exposed code path is the upstream project’s vulnerability. See the third-party-dependency entry in Out of scope.

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.

Security properties and violation severity

The trust-boundary statement above commits the framework to a small set of concrete properties. Each one maps to a specific impact an attacker achieves if the framework fails to uphold it, and to an indicative severity tier. The classes in In-scope vulnerability classes below are the mechanisms by which these properties are broken; the table here is the impact view that triage tooling and reporters can use to gauge how serious a candidate finding is and which protective property it breaks.

Property the framework upholds for untrusted input (default or reasonably-expected configuration) What a violation looks like (symptom a reporter or scanner observes) Indicative severity

Untrusted data is never turned into executed code or OS commands

A crafted message, header or attachment causes a deserialisation gadget chain, a bean / method / command dispatch, or an expression/template evaluation the route author never requested

Critical (CVSS 9.0-10.0)

Untrusted data cannot redirect the route to a different endpoint, bean, method or command

An internal header injected from the wire (CamelBeanMethodName, CamelExecCommandExecutable, CamelHttpUri, CamelJmsDestinationName, …​) changes where the exchange is dispatched

Critical (CVSS 9.0-9.8)

Untrusted data is never deserialised into arbitrary Java types

A consumer, type converter or persisted-state repository instantiates attacker-chosen classes through ObjectInputStream / XStream / Hessian / polymorphic Jackson without an effective filter

Critical when gadget-reachable (9.0-9.8); High otherwise (7.0-8.6)

Untrusted parsing does not resolve external or remote resources

An XML / XSLT / XSD / XPath parse of attacker input reads a local file, performs SSRF, or fetches a remote DTD or stylesheet by default

High (CVSS 7.5-8.6); Critical if it yields RCE or credential theft

Untrusted file names or URI components cannot escape the configured root

A file / mail / FTP consumer or producer reads or writes a path outside the configured directory via ../ or an absolute path supplied in a header

High (CVSS 7.5-8.8)

Components that advertise authentication or authorization actually enforce it

A request is served without a valid token, with an unvalidated issuer / audience / signature, or on a sub-path the auth handler was assumed to cover

Critical (CVSS 9.0-9.8)

Secrets and internal Exchange state are not disclosed

Credentials, message bodies or configuration values reach a log, an event, a world-readable file, or an HTTP response visible to a lower-privileged party

Medium to High (CVSS 5.3-8.2), depending on what leaks

Untrusted input is not spliced into a back-end query language Camel builds

Camel constructs a Cypher / XSLT-extension / similar query and the attacker alters its structure rather than only its data

High to Critical (CVSS 8.1-9.8)

All of the above hold with zero security configuration

Any of the above is reachable simply by adding the component to a route and sending a message, with no risky option explicitly set

Severity of the underlying class; always in scope

The tiers above are indicative, reflecting how the Camel PMC has historically scored these classes. The PMC assigns the definitive CVSS vector per report based on attack vector, the configuration required to reach the code path, and the concrete impact demonstrated. A finding that needs an unusual non-default configuration, or whose impact is limited, may score lower than the tier suggests; one that chains into full host compromise may score higher.

Core router-engine invariants

The table above is the cross-component impact view: each property is broken when some component mishandles untrusted input on its way into a route. This subsection states the companion engine view - what camel-core itself (the routing engine, the Exchange / Message model, the EIP processors, the expression, language and property-placeholder resolution, and the type-converter and data-format registries) upholds independently of any one component. It exists so that a candidate located in a core/camel-* module, rather than in a component, can be routed to a property and a disposition without re-deriving the trust model.

These are not new commitments. Each invariant is the engine-layer projection of an In-scope vulnerability class below, or of the trust boundary in Trust model; it is restated here because a finding against the core is reported against core code, and the triager needs the core-side statement to judge it.

Invariant the router engine upholds on its own (no component-specific configuration) What a violation looks like Indicative severity

The engine never evaluates an Exchange body, header or property as a simple, OGNL, bean or scripting expression unless a route author placed an expression or predicate at that point in the route

A core processor or language resolves untrusted message content as an expression with no route-author-authored expression referencing it

Critical (CVSS 9.0-9.8)

Untrusted Exchange content does not, by the engine’s own action, select the endpoint, bean, method or command dispatched to; the dynamic targets of toD, recipientList, routingSlip, the dynamic router and bean-method resolution are computed from the route-author expression and the documented dispatch headers only

A value the engine itself promoted from a body or attachment into a dispatch header (CamelBeanMethodName, CamelHttpUri, CamelJmsDestinationName, …​) or into a dynamic-target expression input

Critical (CVSS 9.0-9.8)

The core type-converter registry does not instantiate or deserialise attacker-chosen Java types when a route merely declares a target type (convertBodyTo, a typed body, expression coercion); a converter that reads external entities or runs an ObjectInputStream is the converting component’s responsibility, not an automatic core behaviour

A registered core converter instantiating or deserialising arbitrary types from an untrusted body during automatic conversion (historic instance: CVE-2015-0263, the camel-core XML converter)

Critical when gadget-reachable (9.0-9.8); High otherwise (7.0-8.6)

Property-placeholder and bean-reference resolution ({{…​}}, #bean:, #class:, #type:, #property:) operates on route and configuration text supplied by the route author or operator, never on Exchange content

Message body or header content reaches placeholder or #class: / #bean: resolution and is resolved or instantiated

Critical (CVSS 9.0-9.8)

The engine and the Exchange / Message model never promote a body field, attachment or transport metadata into the internal Camel* / org.apache.camel.* header namespace; populating that namespace from untrusted wire input is a consumer responsibility governed by the inbound HeaderFilterStrategy (the CVE-2025-27636 family), not an engine action

Core machinery, rather than a specific consumer, copies an untrusted-origin value into the internal header namespace

Critical (CVSS 9.0-9.8)

Error handling, dead-letter routing, redelivery and the in-band trace / debug processors do not, on the in-band route path, evaluate untrusted content as code or expose one `Exchange’s body, headers or secrets to an unprivileged in-band party

An onException, dead-letter or BacklogTracer in-band path turns untrusted content into evaluation or cross-Exchange disclosure. Exposure or expression evaluation reached through a management connection (JMX, Jolokia, the developer console) is governed by the management-surface item under Out of scope, not by this invariant

Medium to Critical, depending on what is reached

The engine makes no unbounded-resource guarantee

Unthrottled routing, unbounded aggregation or recursion under attacker-influenced volume. This is an availability concern the operator bounds (throttle, circuitBreaker, resilience4j, JVM limits); see Out of scope. A core finding whose only effect is resource consumption is closed as not a vulnerability

Out of scope (no engine guarantee)

A candidate located in a core/camel- module is judged against these invariants first. If the engine upheld the invariant and the violation arises only because a route author authored an expression or route over untrusted input, or wired an untrusted source straight through without removeHeaders("Camel"), the disposition is the route-author position in Out of scope, not a framework vulnerability - the same line the rest of this model draws between the route plus its configuration and the data flowing through it.

Security properties not provided

The complement of Security properties and violation severity and Core router-engine invariants above: properties the framework does not claim, and well-known attack classes it does not defend against on its own. Listing them is what lets the in-scope / out-of-scope rules below work as a closed set rather than an "everything else is also a vulnerability" reading. A report whose entire claim is "feature X failed to do Y" can then be routed to "X was not built to do Y" rather than re-argued case by case.

  • No sandboxing of the route or the JVM running it. Route authors execute arbitrary Java in .bean(), .process() and class references; evaluate arbitrary expressions in simple, groovy, jexl, mvel, xpath, ognl; reach any class on the classpath; and configure any component option. Camel does not constrain what route code is allowed to do (see the route-author entry in Roles).

  • No availability guarantee under attacker-influenced volume or resource cost. The engine does not throttle, bound aggregation, cap recursion or limit per-Exchange memory. Operators apply throttle, circuitBreaker, resilience4j and JVM limits; algorithmic-complexity attacks in third-party parsers (XML billion-laughs, ReDoS in route-author regex, decompression amplification in zip / gzip / brotli inputs) are out of scope unless Camel exposes the parser in a way that bypasses the library’s own limits. See the denial-of-service entry in Out of scope and the unbounded-resource row in Core router-engine invariants.

  • No automatic sanitisation of application-level semantic headers. The framework’s automatic header filtering is scoped to the internal Camel* / org.apache.camel.* namespace only. Application-level headers that components consume as part of their documented header contract - To, Cc, Bcc, Subject, From in camel-mail; arbitrary HTTP header names; JMS properties; AMQP, MQTT, CoAP and Kafka headers - are passed through intentionally. Sanitising them against an untrusted upstream is the route author’s responsibility at the trust boundary (removeHeaders, normalisation, allow-listing). See the third bullet under Known limitations.

  • No shield against transitive-dependency CVEs. A CVE in a JAR Camel pulls in is the upstream project’s vulnerability; Camel fixes CVEs in Camel code, not in third-party JARs. Camel may upgrade the dependency to pick up an upstream fix, but the CVE itself is closed against the upstream project. See the third-party-dependency entry in Out of scope.

  • No production guarantees under the non-default dev or test profile. The dev console, debug and trace endpoints, the backlog debugger and verbose diagnostics are enabled, and the security policy default relaxes from fail to warn. Camel may reveal configuration, route and Exchange detail that it would not reveal under the default prod profile. See the profile entry in Out of scope and design/security.adoc.

  • No production-grade information-hiding guarantees under non-default diagnostic log levels. DEBUG and TRACE log levels are diagnostic, not production, configurations; they are expected to log internal Exchange, route and configuration detail that the default INFO, WARN and ERROR levels do not. The project strives to avoid logging sensitive data even at diagnostic levels where it makes sense, but does not commit to redacting it. The default INFO, WARN and ERROR levels are what the framework commits to keeping clean of sensitive data; see the Information disclosure of secrets or sensitive Exchange state class under In-scope vulnerability classes.

  • No defence against the operator misconfiguring the deployment outside the framework’s defaults. trustAllCertificates=true, hostnameVerificationEnabled=false, allowJavaSerializedObject=true, transferException=true, exposing the management surface on a public network, placing the aggregation-repository store on a writeable share - all are operator decisions. The framework is in scope only when the default shipped the risky behaviour. See the explicit-opt-in entry in Out of scope.

  • No constant-time, side-channel-resistant comparison or cryptographic primitives. Equality of headers, tokens and identifiers uses general-purpose Java comparison. Route-author code that compares a shared secret against an untrusted input is responsible for using a constant-time comparator; Camel does not provide one.

False-friend properties

Features that look like a security property and are sometimes mistaken for one. Each is documented here so that a report whose claim rests on the misunderstanding can be closed against the correct contract.

  • DefaultHeaderFilterStrategy is an internal-namespace filter, not an application-header sanitiser. It filters the Camel* / org.apache.camel.* namespace case-insensitively, which is what contains the internal-dispatch family (the CVE-2025-27636 class). It does not, and cannot, strip the application-level headers a component reads as semantic input. Route authors who need application-header sanitisation must do it explicitly at the trust boundary.

  • removeHeaders("Camel") strips the internal-dispatch headers, not every untrusted-origin header.* It is the recommended trust-boundary hygiene against the internal-header dispatch class (see Deployment hardening), and it is necessary; it is not, on its own, sufficient to sanitise the application headers a downstream component will trust.

  • The security policy enforcement framework is a configuration linter, not a runtime sandbox. The four categories (secret, insecure:ssl, insecure:serialization, insecure:dev) detect insecure configuration at bootstrap time and emit a warning or fail startup under the prod profile. They do not intercept runtime data or enforce a policy on a per-Exchange basis. See design/security.adoc.

  • Component deprecation is not a security boundary. A (deprecated) component still ships in a supported release and remains in limited scope (see Deprecated and removed components). Deprecation marks a removal path with a documented migration; it does not by itself reduce the trust boundary or imply the component is unsafe to receive a fix.

  • TLS by default is not peer authentication. Components that default to TLS for transport (HTTP, AMQP, MQTT, Kafka, JMS) protect the wire from passive observers and trivial man-in-the-middle. They do not, on their own, validate that the peer is the one the route intended to talk to; that requires an SSLContextParameters with a trust store and hostname verification configured by the operator (see Deployment hardening).

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

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

The prefixed headers of the API-based components - CamelFhir., CamelBox., CamelOlingo4., CamelAs2. and the other camel-api-component generated producers, which select the API method and its arguments - sit inside the Camel* namespace, so they are governed by exactly this rule. The project’s position on a Camel<Api>. header reaching an API producer from an untrusted source is therefore *conditional, and the condition is at the inbound consumer, not at the API producer; it is not "always out of scope". A consumer that admits a Camel<Api>. header from an untrusted source without an effective case-insensitive Camel HeaderFilterStrategy is in scope regardless of which producer ultimately consumes the header - this is the same class as the CVE-2025-27636 family. The API producer honouring a Camel<Api>. header that reached it only because a route author wired an untrusted source straight to the producer without removeHeaders("Camel"), while the inbound filter was in place and effective, is the documented bean-dispatch contract (see Known limitations), not a framework vulnerability.

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

Judged against the default production log levels (INFO, WARN, ERROR); findings whose impact only manifests when the operator has enabled the diagnostic DEBUG or TRACE levels are out of scope, since those levels are operator-enabled diagnostic configurations expected to log internal Exchange, route and configuration detail (see the diagnostic-logging entry under Known non-findings).

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.

  • Behaviour that is only present under the non-default dev or test profile. Camel defaults to the prod profile; the dev and test profiles (set explicitly via camel.main.profile, or selected for you by tooling such as Camel JBang) are development-only and deliberately less guarded - they enable the developer console, debug and trace endpoints, the backlog debugger and more verbose diagnostics, and relax the security policy default from fail to warn. Camel may, by design, reveal configuration, route and Exchange detail in these modes that it would not reveal under prod. A report whose impact only manifests under camel.main.profile = dev or test is out of scope as a non-default, development-only configuration; the production posture against which findings are judged is the default prod profile (see Deployment hardening and the design/security.adoc design document for the profile-aware policy defaults).

  • 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. The operations they expose - including ManagedCamelContext.sendBody / requestBody, ManagedBacklogDebugger.evaluateExpressionAtBreakpoint, addConditionalBreakpoint and BacklogTracer.setTraceFilter - are intentionally as expressive as a route author’s DSL, because they exist to support operator workflows (Camel JBang, Hawtio, JConsole, monitoring agents). The trust boundary is the management surface itself - JVM JMX authentication (-Dcom.sun.management.jmxremote.authenticate), the Jolokia restrictor policy, and the network exposure of the management port - not the individual MBean method. A report that demonstrates "MBean operation X executes code or sends to endpoint Y when invoked from a JMX or Jolokia connection" describes the documented contract, not a framework vulnerability.

  • Vulnerabilities in third-party transitive dependencies. Camel fixes CVEs in Camel code, not in third-party JARs; the report belongs upstream. Camel may upgrade the dependency to pick up an upstream fix, but the CVE itself is closed against the upstream project. See 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.

Deprecated and removed components

A component’s position in its lifecycle changes how a report against it is handled. Whether a component is deprecated is mechanically verifiable: it carries the (deprecated) suffix in its pom.xml name and documentation title, an @Deprecated annotation, a deprecated flag in the Camel catalog, and an upgrade-guide entry pointing at the replacement or migration.

  • Deprecated components are in limited scope. A deprecated component is on a removal path and has a documented replacement or migration. A report against one is still triaged on the private security list, but the primary remediation is the documented migration, not necessarily a code change in the deprecated component. Depending on the severity and on how widely the component is still used, the PMC may fix in place, publish an advisory whose remediation is "migrate to the supported replacement", or accelerate removal. Hardening and defence-in-depth work goes to the supported replacement, not the deprecated component.

  • Removed components are out of scope. A component that no longer ships in any supported release cannot receive a fix. A finding must be demonstrated against a component present in a supported release; if the only affected code is one that has been removed, the resolution is to upgrade to a release where it is gone or replaced.

  • This lifecycle rule does not change the in-scope classes for a non-deprecated component that merely depends on a deprecated or end-of-life third-party library - that case is governed by the third-party-dependency item under Out of scope above.

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.

  • The framework’s automatic header filtering is scoped to the internal Camel / org.apache.camel. namespace. DefaultHeaderFilterStrategy filters that namespace case-insensitively; it does not, and cannot, filter the non-prefixed application-level headers a component reads as semantic input - To, Cc, Bcc, Subject, From in camel-mail; HTTP header names; JMS properties; and so on. Those headers are part of each component’s documented header contract and are intentionally passed through. There is one uniform rule rather than a per-component policy: protecting a producer’s semantic headers from an untrusted upstream is route-author responsibility - strip or normalise them at the trust boundary, exactly as for a query string built from untrusted input - while the specific set of semantic headers a component honours is necessarily component-by-component and is documented on each component page. The framework itself is in scope only when a consumer maps untrusted wire input into those headers as part of its own default behaviour without an effective inbound HeaderFilterStrategy (the same inbound-filter class as the Camel-header item under In-scope vulnerability classes, e.g. CVE-2026-33454 in camel-mail); the path-traversal class applies independently where such a header navigates outside a configured root (e.g. CVE-2018-8041).

  • 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 Camel framework, not the underlying client, is the cause.

Known non-findings

Patterns that automated scanners, AI-assisted analysers and human reviewers repeatedly report against Camel that are not framework vulnerabilities under this model. Each entry names the recurring claim, cites the section of this document that discharges it, and where appropriate states the suppression shape. This list is the highest-leverage input for an automated triage pass; it can be fed back to a scanner verbatim as a negative prompt or suppression configuration. Disposition is KNOWN-NON-FINDING (see Triage dispositions).

  • "Component X depends on a JAR with CVE-Z, therefore Camel is vulnerable." Out of scope per the transitive-dependency entry in Out of scope. Camel fixes CVEs in Camel code, not in third-party JARs; the report belongs upstream. Camel may upgrade the dependency to pick up an upstream fix, but the CVE itself is closed against the upstream project.

  • "`simple(…​), `xpath(…​), groovy(…​), jexl(…​) or mvel(…​) evaluates an untrusted expression." The expression text is route-author code, not untrusted input. The framework is in scope only when it passes an Exchange body, header or property to an evaluator without the route author placing an expression there - the first invariant under Core router-engine invariants. Otherwise this is the route-author entry in Out of scope.

  • "`.bean(…​), `.process(…​), Runtime.exec(…​) or a Class reference allows RCE." These are route-author primitives by design. Route code is trusted code; see the route-author entry in Out of scope and the route-author row in Roles.

  • "A Camel / org.apache.camel. header controls dispatch, therefore the consumer is vulnerable." Bean-based dispatch via internal headers is the public contract for letting a route control component behaviour; see the second bullet under Known limitations. A finding is in scope only when a consumer promotes an untrusted-origin value into that namespace without an effective HeaderFilterStrategy - the Camel-header / bean-dispatch class under In-scope vulnerability classes.

  • "Application-level header X (To, Subject, HTTP X-…​, JMS property, AMQP / MQTT / CoAP / Kafka header) is not stripped, therefore the consumer is vulnerable." Application-level headers are part of each component’s documented header contract and are intentionally passed through; the framework filters only the internal Camel* namespace. See the third bullet under Known limitations and the application-headers point under Security properties not provided. The route author sanitises at the trust boundary.

  • "`DefaultHeaderFilterStrategy` can be bypassed by changing the case (caMEL, CAMEL)." The default strategy is case-insensitive out of the box (Camel, CAMEL and caMEL are filtered identically); see the third bullet under Known limitations. A finding here would have to demonstrate a custom strategy that does not extend DefaultHeaderFilterStrategy and re-implements the matching without case-insensitivity - and the fix lives in that custom strategy.

  • "The developer console, the backlog debugger, the Tracer / BacklogTracer, JMX, Jolokia or camel-management exposes operations that execute code or read Exchange state." Management surfaces; the trust boundary is the surface itself (JVM JMX authentication, the Jolokia restrictor, the network exposure of the management port), not the individual MBean method. See the management-surface entry in Out of scope and the error-handling row in Core router-engine invariants.

  • "A finding only manifests under camel.main.profile=dev or camel.main.profile=test." Non-default development-only configuration; out of scope per the profile entry in Out of scope.

  • "`camel-FOO` logs the Exchange body, a header, or a configuration value at DEBUG or TRACE level." DEBUG and TRACE are diagnostic log levels enabled explicitly by the operator; they are expected to reveal internal Exchange, route and configuration detail that the default INFO, WARN and ERROR levels do not. Information-disclosure findings are judged against the default production log levels (see the Information disclosure of secrets or sensitive Exchange state class under In-scope vulnerability classes, and the diagnostic-log-levels point under Security properties not provided). The project strives to avoid logging sensitive data even at diagnostic levels where it makes sense, but does not commit to redacting it.

  • "Component camel-FOO uses MD5 / SHA-1 / a non-cryptographic hash function." Camel uses content hashing for non-security purposes such as idempotency keys, content-based routing identifiers, partitioner selection and cache keys. A finding requires the use to be a security primitive (authentication, integrity check, secret derivation, signature), not a routing or identification primitive. See the constant-time-comparison point under Security properties not provided.

  • "A deprecated component still ships and has a CVE." Deprecated components are in limited scope; the primary remediation is the documented migration to the supported replacement, not necessarily a fix in the deprecated component. See Deprecated and removed components.

  • "An option allowJavaSerializedObject=true, transferException=true, mapJmsMessage=true, trustAllCertificates=true or hostnameVerificationEnabled=false enables an unsafe behaviour." Documented opt-ins; the operator has explicitly accepted the consequence. See the explicit-opt-in entry in Out of scope.

  • "A finding lands in a core/camel- module."* Routed first against Core router-engine invariants. If the engine upheld every listed invariant and the violation arises only because a route author authored an expression or route over untrusted input, or wired an untrusted source straight through without removeHeaders("Camel*"), the disposition is the route-author position in Out of scope.

Triage dispositions

The closed set of outcomes a vulnerability report, scanner finding or AI-assisted review can receive when judged against this model. Each disposition cites the section that licenses it, so the triage response is "see Section X of this document" rather than ad-hoc prose. A finding that does not fit any of the dispositions below is MODEL-GAP, and the correct response is to revise the model (extend In-scope vulnerability classes, Out of scope, Known limitations or Security properties not provided), not to close the report ad hoc.

Disposition Meaning Licensed by

VALID

Violates a property the framework claims, via the adversary defined in Adversary model and an input the model marks untrusted. Fixed in a coordinated release; published as a CVE advisory.

Security properties and violation severity, Core router-engine invariants, In-scope vulnerability classes, Adversary model

VALID-HARDENING

No claimed property is violated, but a recurring misuse or scanner pattern makes the framework elect to harden the default or add a defence-in-depth check at maintainer discretion. Reported privately; typically shipped without a CVE; documented in the upgrade guide.

Known limitations, Guidance for component authors and reviewers

OUT-OF-MODEL: trusted-input

Requires control over an input the model marks trusted (route DSL, configuration property, operator-controlled file).

Trust model (Roles, Trust boundaries)

OUT-OF-MODEL: adversary-not-in-scope

Requires an attacker capability the adversary model excludes (route author, deployment operator, management-surface network peer, author of a transitive third-party dependency).

Adversary model

OUT-OF-MODEL: unsupported-component

The affected component has been removed in supported releases, or the finding is against example or sample code outside the framework’s shipped surface.

Deprecated and removed components

OUT-OF-MODEL: non-default-build

Only manifests under a non-default profile (camel.main.profile = dev or test), an explicit opt-in option (allowJavaSerializedObject=true, transferException=true, trustAllCertificates=true, hostnameVerificationEnabled=false, mapJmsMessage=true) or another documented opt-in.

Out of scope (profile and explicit-opt-in entries), design/security.adoc

BY-DESIGN: property-disclaimed

Concerns a property the framework explicitly does not provide - DoS / resource bounds, JVM sandboxing, application-level header sanitisation, transitive-dependency CVEs, constant-time comparison, protection from operator misconfiguration outside framework defaults.

Security properties not provided, Out of scope

KNOWN-NON-FINDING

Matches a documented recurring false-positive pattern.

Known non-findings

MODEL-GAP

Does not fit any disposition above. Triggers a revision of this document (a new in-scope class, a new out-of-scope entry, a new known limitation or a new disclaimed property) rather than an ad-hoc call on the report.

Reporting a vulnerability (PMC review), upgrade-guide entry

Deployment hardening

Operators are responsible for the following. None of these are framework vulnerabilities if skipped; all of them reduce the attack surface materially.

  • Stay on the default prod profile in production. Camel defaults to the prod profile, under which the security policy framework defaults to fail for the four categories (secret, insecure:ssl, insecure:serialization, insecure:dev). Setting camel.main.profile = dev or test is an explicit opt-in to development-only behaviour (extra services, dev console, debug endpoints) and should not be used in production. Override individual categories explicitly when a deployment genuinely needs a relaxed policy. See the design/security.adoc design document for details.

  • Resolve secrets through a vault. Use one of the supported backends (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 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:

    from("jetty:http://0.0.0.0:8080/api")
    .removeHeaders("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 /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.

  • Use the minimal set of dependencies. Include only the Camel components and third-party JARs the application actually uses. Every extra dependency enlarges the attack surface and the patch responsibility.

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* and any internal headers the component itself uses. The default DefaultHeaderFilterStrategy is case-insensitive out of the box (so Camel, CAMEL and caMEL are all filtered identically); custom strategies must either extend DefaultHeaderFilterStrategy to inherit this behaviour or implement the case-insensitive matching themselves.

  • 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 design/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 Apache Camel Security.

  • Email private-security@camel.apache.org with a description, affected versions, and a proof of concept that demonstrates the trust-boundary breach.

  • Do not file a public Jira ticket, open a public pull request, post on a mailing list, social media, or any other public channel for an unpublished vulnerability - avoid disclosing anything about the potential issue until a coordinated fix is released. Only contact the Apache Software Foundation Security team to report the issue and follow their instructions.

Reports that match the in-scope classes above will be triaged on the private security list, fixed in a coordinated release, and published as a CVE advisory. Reports that match the out-of-scope categories will be closed with a reference to this document.

Related documents

  • Security - the user-facing security catalog (route, payload, endpoint, configuration security, vaults).

  • Camel Configuration Utilities - JSSE Utility for SSL/TLS configuration.

  • design/security.adoc (in the source tree) - design document for the security policy enforcement framework.

  • Apache Camel Security - the public advisory index and reporting process.

  • SECURITY.md (in the source tree) - the GitHub-rendered security pointer.

Back to top