From 473e13add4c72ec68d5592b989cdcca81d19df95 Mon Sep 17 00:00:00 2001 From: Andrea Cosentino Date: Thu, 14 May 2026 17:58:48 +0200 Subject: [PATCH 1/2] docs: clarify management-surface scope in security model Expand the "management surface" out-of-scope bullet in security-model.adoc to name the MBean operations the bullet covers (ManagedCamelContext.sendBody / requestBody, ManagedBacklogDebugger.evaluateExpressionAtBreakpoint and addConditionalBreakpoint, BacklogTracer.setTraceFilter) and to state explicitly that the trust boundary is the JMX / Jolokia / management HTTP surface itself - JVM JMX authentication, the Jolokia restrictor policy and the network exposure of the management port - rather than any individual MBean method. These operations are intentionally as expressive as a route author's DSL so that operator workflows (Camel JBang, Hawtio, JConsole, monitoring agents) keep working. The clarification helps future readers of the security model identify which side of the trust boundary the management API sits on without having to derive the reasoning from the trust-model section. _Claude Code (Opus 4.7) on behalf of Andrea Cosentino_ Signed-off-by: Andrea Cosentino --- .../modules/ROOT/pages/security-model.adoc | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/user-manual/modules/ROOT/pages/security-model.adoc b/docs/user-manual/modules/ROOT/pages/security-model.adoc index 8a6abeaf1d66e..3f05b81bb3f28 100644 --- a/docs/user-manual/modules/ROOT/pages/security-model.adoc +++ b/docs/user-manual/modules/ROOT/pages/security-model.adoc @@ -263,7 +263,19 @@ be closed as `not a vulnerability`. 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. + 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 that are not reachable through any Camel-exposed code path.* See https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the From f057d7afd62a87bd01f78cf475d1ad67dd64f33e Mon Sep 17 00:00:00 2001 From: Andrea Cosentino Date: Fri, 15 May 2026 10:54:00 +0200 Subject: [PATCH 2/2] docs: add severity tiers and lifecycle scope to security model Add a "Security properties and violation severity" subsection mapping each protective property to its violation symptom and an indicative severity tier (an impact view complementing the mechanism-oriented in-scope classes), and a "Deprecated and removed components" subsection placing deprecated components in limited scope and removed ones out of scope. Bridge AGENTS.md to SECURITY.md so the vulnerability-reporting convention is complete and agents are instructed not to disclose suspected issues publicly. Co-Authored-By: Claude Opus 4.7 (1M context) --- AGENTS.md | 6 ++ .../modules/ROOT/pages/security-model.adoc | 87 +++++++++++++++++++ 2 files changed, 93 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 9bbb476d226f5..950ec27a4a88c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -177,6 +177,12 @@ document is [`docs/user-manual/modules/ROOT/pages/security-model.adoc`](docs/use Use it as the reference when triaging security reports, deciding whether a finding warrants a CVE, or reviewing a security-sensitive PR. +For the vulnerability **reporting** convention, [`SECURITY.md`](SECURITY.md) at the repository +root is the entry point GitHub and security tooling expect. It points to the threat model above +for scope and to the ASF process for private disclosure. An agent that discovers or is handed a +suspected vulnerability MUST NOT open a public issue, PR, or mailing-list post about it — follow +the private process in `SECURITY.md` and stop. + ### Trust assumptions - **Camel committers and component authors** are trusted to ship secure defaults. diff --git a/docs/user-manual/modules/ROOT/pages/security-model.adoc b/docs/user-manual/modules/ROOT/pages/security-model.adoc index 3f05b81bb3f28..bd26f25008ed6 100644 --- a/docs/user-manual/modules/ROOT/pages/security-model.adoc +++ b/docs/user-manual/modules/ROOT/pages/security-model.adoc @@ -93,6 +93,66 @@ 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. + +[cols="3,3,1",options="header"] +|=== +| 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. + === In-scope vulnerability classes The classes below are grounded in advisories the Apache Camel PMC has accepted @@ -286,6 +346,33 @@ be closed as `not a vulnerability`. 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