This is an automated email from the ASF dual-hosted git repository.
oscerd pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 9784faba1b60 CAMEL-23496: docs - add a project-level security model
document (#23181)
9784faba1b60 is described below
commit 9784faba1b60abdfeda890be44cc6ec805c011eb
Author: Andrea Cosentino <[email protected]>
AuthorDate: Wed May 13 15:31:15 2026 +0200
CAMEL-23496: docs - add a project-level security model document (#23181)
* CAMEL-23496: docs - add a project-level security model document
Introduce docs/user-manual/modules/ROOT/pages/security-model.adoc that
documents the Camel threat model: who is trusted (committers, route
authors, deployment operators), where the trust boundary sits (between
the route plus its configuration and the data flowing through it),
which vulnerability classes the PMC accepts as framework issues, which
categories are out of scope (route-author or operator responsibility,
explicit opt-ins, DoS through unthrottled routes, third-party
transitive CVEs not reachable through Camel), and what operators and
committers are expected to do.
In-scope and out-of-scope lists are anchored in the project's accepted
CVE history (~40 advisories) so each rule has a concrete precedent:
unsafe deserialisation, XXE, expression/template injection, path
traversal, SSRF via parser resolution, Camel-header / bean-dispatch
abuse, auth bypass in AAA components, information disclosure, insecure
defaults, injection into back-end queries.
The document is referenced from three places: a NOTE block at the top
of the existing user-manual security.adoc, a new "Security Model"
section in AGENTS.md, and a pointer paragraph in SECURITY.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
* Update docs/user-manual/modules/ROOT/pages/security-model.adoc
Co-authored-by: Claus Ibsen <[email protected]>
* CAMEL-23496: docs - address review feedback on security model
- prod is the default profile in Camel main; invert the hardening
bullet so it reads as "stay on prod" rather than "set profile to
prod", and call out that switching to dev/test is the explicit opt-in
to development-only behaviour.
- Drop the obsolete org.apache.camel.* header prefix from the Java
example and the committer checklist; the prefix is a Camel v1
leftover and is no longer emitted by core consumers.
- Spell out that DefaultHeaderFilterStrategy is case-insensitive out of
the box (Camel, CAMEL, caMEL filtered identically) and that custom
HeaderFilterStrategy implementations must either extend the default
or implement the same behaviour.
- Add a hardening bullet on minimal dependencies (only the Camel
components and 3rd-party JARs the application actually uses).
- Strengthen the reporting section: do not disclose on mailing lists,
social media or any other public channel until a coordinated fix is
released; report through the ASF Security team.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
Co-authored-by: Claus Ibsen <[email protected]>
---
AGENTS.md | 103 +++++
SECURITY.md | 9 +
.../modules/ROOT/pages/security-model.adoc | 421 +++++++++++++++++++++
docs/user-manual/modules/ROOT/pages/security.adoc | 8 +
4 files changed, 541 insertions(+)
diff --git a/AGENTS.md b/AGENTS.md
index 1d71aedf8a6c..9bbb476d226f 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -169,6 +169,109 @@ When writing or modifying `.adoc` documentation:
- **When reviewing doc PRs**, check that all `xref:` links and anchors resolve
correctly, especially
cross-component references that may span versions.
+## Security Model
+
+Camel has a documented threat model that defines who is trusted, where the
trust boundaries sit,
+what counts as a framework vulnerability, and what is operator responsibility.
The canonical
+document is
[`docs/user-manual/modules/ROOT/pages/security-model.adoc`](docs/user-manual/modules/ROOT/pages/security-model.adoc).
+Use it as the reference when triaging security reports, deciding whether a
finding warrants a
+CVE, or reviewing a security-sensitive PR.
+
+### Trust assumptions
+
+- **Camel committers and component authors** are trusted to ship secure
defaults.
+- **Route authors** (the people writing DSL routes) are **fully trusted**.
They execute arbitrary
+ Java in `.bean()` / `.process()`, evaluate arbitrary expressions in `simple`
/ `groovy` / `jexl`
+ / `mvel` / `xpath`, and configure every component option. Code execution by
a route author is
+ by design and is **not** a vulnerability.
+- **Deployment operators** are **fully trusted**. They set configuration,
secrets, network
+ exposure and the JVM. Their misconfiguration is not a framework
vulnerability unless Camel's
+ default exposed it.
+- **External message senders** (HTTP clients, JMS producers, file droppers,
SMTP senders, CoAP
+ peers, etc.) are **untrusted**. This is the primary attacker model.
+
+The fundamental trust boundary is between **the route plus its configuration**
(trusted) and
+**the data flowing through the route** (untrusted). The framework must not
turn untrusted data
+into code execution, file read, request forgery, or auth bypass on its own.
+
+### What is in scope (concise summary)
+
+Reports that demonstrate untrusted input crossing a trust boundary the
framework should have
+held — in a default or reasonably-expected configuration — are in scope.
Concrete classes the
+PMC has historically accepted:
+
+- **Unsafe deserialisation** of untrusted input (XStream / Hessian / Jackson
polymorphic / raw
+ `ObjectInputStream` in consumers, type converters, aggregation repositories,
key stores).
+- **XXE** and remote DTD/stylesheet resolution in XML/XSLT/XPath/XSD parsers.
+- **Expression or template language injection** where the framework itself
passes untrusted
+ input to an evaluator (not the route author).
+- **Path traversal** in file/mail/FTP consumers and producers.
+- **SSRF triggered by parser default resolution**.
+- **Camel-header / bean-dispatch abuse** when a consumer maps untrusted input
into the Exchange
+ header map without a strict, case-insensitive `HeaderFilterStrategy`.
+- **Auth/authz bypass** in components implementing AAA (Keycloak, Shiro,
platform-http auth,
+ Spring Security integration).
+- **Information disclosure** of secrets or Exchange state via logs, events,
world-readable files
+ or HTTP responses.
+- **Insecure defaults** — any component shipping with deserialisation,
TLS-skip or admin-exposure
+ enabled out of the box.
+- **Injection into back-end queries** built by Camel itself (Cypher, XSLT
extension functions,
+ etc.).
+
+### What is out of scope
+
+The following are explicitly **not** framework vulnerabilities and will be
closed as such:
+
+- A **route author** executing arbitrary code through `.bean()`, `.process()`,
`Runtime.exec()`,
+ or evaluating `simple` / `groovy` on untrusted input. Route code is trusted.
+- A route author building a SQL / Cypher / LDAP / HTTP URI from untrusted
input without
+ parameterising. The route is at fault, not the framework.
+- Behaviour that is enabled by **explicit opt-in**:
`allowJavaSerializedObject=true`,
+ `transferException=true`, `trustAllCertificates=true`,
`hostnameVerificationEnabled=false`, or
+ selecting an `ObjectInputStream`-using data format.
+- **DoS / resource exhaustion** through unthrottled routes. Operators apply
`throttle`,
+ `circuitBreaker`, `resilience4j`, JVM limits.
+- A deployer exposing `camel-management`, the developer console,
`camel-jolokia` or JMX on a
+ public network.
+- Third-party transitive dependency CVEs that are not reachable through any
Camel-exposed code
+ path.
+- Automated scanner reports without a PoC demonstrating an actual
trust-boundary breach.
+
+### Operator hardening checklist
+
+When reviewing or recommending a deployment, surface the following:
+
+- Enable the security policy framework: set `camel.main.profile = prod` so the
default for
+ `secret` / `insecure:ssl` / `insecure:serialization` / `insecure:dev` is
`fail`
+ (see [`proposals/security.adoc`](proposals/security.adoc)).
+- Resolve secrets through one of the supported vaults rather than plain-text
properties.
+- Configure TLS through `SSLContextParameters` (the JSSE Utility); never
`trustAllCertificates`
+ in production.
+- Strip Camel-internal headers (`Camel*`, `org.apache.camel.*`) from messages
arriving from
+ untrusted producers using `removeHeaders("Camel*")` before any dispatching
processor.
+- Do not enable Java serialisation on consumers exposed to untrusted networks.
+- Keep `camel-management`, the developer console, `camel-jolokia` and JMX on a
trusted network
+ only.
+
+### Committer review checklist (for security-sensitive PRs)
+
+When reviewing a PR that touches a consumer, type converter, aggregation
repository, data
+format, parser, or anything that handles `@UriParam` security knobs:
+
+- Does the inbound side apply a `HeaderFilterStrategy` that blocks `Camel*` /
`camel*` /
+ `org.apache.camel.*` **case-insensitively**? The header-injection family
(CVE-2025-27636 and
+ five follow-ons) recurred precisely because new consumers shipped without it.
+- Does the change call `ObjectInputStream.readObject()` (directly or via
Hessian/Castor/XStream)
+ without an `ObjectInputFilter`? Five sequential CVEs (CVE-2024-22369, 23114,
2026-25747, 27172,
+ 40858) accepted this exact pattern in aggregation repositories.
+- Does any new `@UriParam` control a security-relevant default? If so, mark it
with
+ `secret = true` for secrets or `security = "insecure:ssl"` /
`"insecure:serialization"` /
+ `"insecure:dev"` for risky flags (see the `Annotations` subsection further
down).
+- Does the change relax a default? New defaults err toward "denied unless
opted in". A relaxed
+ default needs an upgrade-guide entry and PMC sign-off.
+- Does an authentication or authorization component enforce what its option
names claim — issuer
+ validation, audience checking, signature verification, every advertised
sub-path covered?
+
## Structure
```
diff --git a/SECURITY.md b/SECURITY.md
index 90902febefa9..386f3c429e2e 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -7,3 +7,12 @@ To see which versions of Apache Camel are supported please
refer to this [page](
## Reporting a Vulnerability
For information on how to report a new security problem please see
[here](https://camel.apache.org/security/).
+
+## Security Model
+
+Before submitting a report, please read the project's
+[Security Model](docs/user-manual/modules/ROOT/pages/security-model.adoc). It
documents who is
+trusted, where the trust boundaries sit, which vulnerability classes the Camel
PMC accepts, and
+which categories are out of scope (route-author or operator responsibility,
explicit opt-ins,
+DoS through unthrottled routes, third-party transitive CVEs not reachable
through Camel code,
+etc.). Reports outside the documented scope will be closed with a reference to
that page.
diff --git a/docs/user-manual/modules/ROOT/pages/security-model.adoc
b/docs/user-manual/modules/ROOT/pages/security-model.adoc
new file mode 100644
index 000000000000..10aa0587f1b0
--- /dev/null
+++ b/docs/user-manual/modules/ROOT/pages/security-model.adoc
@@ -0,0 +1,421 @@
+= 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 Camel 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.
+
+* *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 `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*")
+ .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.
+* *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
+ `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, 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
+ https://apache.org/security/[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
+
+* xref:security.adoc[Security] - the user-facing security catalog (route,
+ payload, endpoint, configuration security, vaults).
+* xref:camel-configuration-utilities.adoc[Camel Configuration Utilities] -
+ JSSE Utility for SSL/TLS configuration.
+* `proposals/security.adoc` (in the source tree) - design document for the
+ security policy enforcement framework.
+* https://camel.apache.org/security/[Apache Camel Security] - the public
+ advisory index and reporting process.
+* `SECURITY.md` (in the source tree) - the GitHub-rendered security pointer.
diff --git a/docs/user-manual/modules/ROOT/pages/security.adoc
b/docs/user-manual/modules/ROOT/pages/security.adoc
index d5e66b29795a..61a1c09359b4 100644
--- a/docs/user-manual/modules/ROOT/pages/security.adoc
+++ b/docs/user-manual/modules/ROOT/pages/security.adoc
@@ -4,6 +4,14 @@ Camel offers several forms and levels of security capabilities
that can be
used on Camel routes. These various forms of security may be used in
conjunction with each other or separately.
+[NOTE]
+====
+This page describes the security *features* Camel offers to route authors and
+operators. For the project's *security model* - who is trusted, where the
+trust boundaries sit, what counts as a framework vulnerability, and what is
+operator responsibility - see xref:security-model.adoc[Security Model].
+====
+
The broad categories offered are:
* _Route Security_ - Authentication and Authorization services to proceed
