This page documents the security model of the Apache Camel Kamelet Catalog: who is trusted, where the trust boundaries sit, what counts as a catalog vulnerability, and what is left to the route author and the deployment operator. It is the reference used by the Apache Camel PMC when triaging security reports against the Kamelet Catalog and when deciding whether a behaviour should be hardened in a Kamelet template or addressed by the deployment.
The Kamelet Catalog is an Apache Camel sub-project. It does not define its own trust model from scratch: it specialises the Apache Camel Security Model for the specific shape of a Kamelet (a pre-written, PMC-reviewed Camel route template distributed as YAML). Where this document is silent, the Camel Security Model governs. Where they overlap, this document is the more specific authority for the catalog.
|
Important
|
Status: Maintainer-ratified (Apache Camel PMC, 2026-05-15). Ready to publish
as the catalog’s security model. |
This document is written for four audiences:
-
Security researchers and CVE reporters who need to know what the Camel PMC will accept as a Kamelet Catalog vulnerability before submitting a report.
-
Automated triage tooling (CVE scanners, AI-assisted security review) that needs an authoritative scope statement to distinguish a real catalog vulnerability from intentional, documented design.
-
Kamelet authors and reviewers contributing or reviewing Kamelet YAML, who need to know which template patterns and property defaults are acceptable.
-
Route authors and deployment operators who embed Kamelets in an integration, and need to know which responsibilities the catalog delegates to them.
A Kamelet is a single YAML file containing a Camel route template (in
spec.template, YAML DSL) plus a JSON-schema declaration of the configuration
properties the route author binds (in spec.definition.properties). The
catalog ships about 250 of these (94 sources, 95 sinks, 61 actions). A Kamelet
is referenced by name from a route or Pipe; the runtime substitutes
{{property}} placeholders with the bound values and runs the template like any
other Camel route.
The security-relevant consequence: in a hand-written Camel route, the route author writes the route; in a Kamelet, the catalog author (the Camel community, reviewed by the PMC) writes the route fragment and the route author only supplies bound property values. The trust boundary between trusted route code and untrusted message data is unchanged from Camel’s model - but the author of the trusted code is now the catalog. That is the single fact that shapes everything below: a Kamelet template must be safe-by-default for the untrusted-data boundary, because the operator who deploys it generally does not inspect or rewrite the template.
| Role | Trust level | What this role can do |
|---|---|---|
Kamelet authors and the Camel PMC |
Trusted |
Author and review the Kamelet template (which is route code), choose property defaults, decide which inbound headers a template maps where, and select the underlying Camel component. The catalog relies on PMC review to ship templates that are safe by default. |
Route authors (who reference a Kamelet and bind its properties in Java, XML,
YAML DSL or a |
Fully trusted |
Choose which Kamelet to use and where to place it in a route, and bind every property - URLs, queries, file paths, OS commands, template/expression strings, credentials - from configuration. Binding a property to an attacker-controlled value is route-author error, not a catalog vulnerability. |
Deployment operators |
Fully trusted |
Decide network exposure of source Kamelets, supply secrets and the secrets backend, choose the Camel runtime and JVM, and decide which catalog to load Kamelets from. Loading a Kamelet from an untrusted source is operator error (see Known limitations). |
External message senders / data flowing through the Kamelet |
Untrusted |
Provide the message body, headers and attachments that a source Kamelet emits or that a sink/action Kamelet consumes. This is the primary attacker model. The catalog’s templates must not turn this data into code execution, endpoint redirection, unsafe deserialisation, remote-resource resolution or auth bypass on their own. |
The fundamental trust boundary is identical to Camel’s: between the Kamelet
(its template plus the operator’s bound configuration) and the data flowing
through it. The Kamelet template and every {{property}} value are trusted;
anything that arrives in an Exchange body, header or attachment from the wire
or filesystem is untrusted.
The Kamelet Catalog adds one internal boundary of its own: the boundary between the catalog as a distribution (the set of YAML files the PMC signs and releases) and the consumer that loads them. An entity that can introduce or modify a Kamelet definition in the catalog a runtime loads is, by design, a trusted route author with arbitrary route/code execution. Integrity of the catalog artifact is therefore a precondition of this whole model, not a property the runtime re-checks.
The repository ships several artifacts with different threat profiles. Only the first is the security-relevant product.
| Family | What it is | In this model? |
|---|---|---|
Kamelet YAML catalog ( |
~250 PMC-reviewed Camel route templates. The product. All template-level security posture lives here. |
Yes - primary |
|
Runtime metadata reader. Loads only the YAML bundled on its own classpath at
build time, via Jackson |
Yes - metadata API surface only |
|
Fabric8-generated Kubernetes model POJOs for the Kamelet CRD. Deserialised by the consumer’s Kubernetes client / Fabric8, not by code in this repository. |
No - the deserialiser is the consumer’s, not this repo’s (PMC-confirmed) |
|
Build-time validation of catalog YAML against the Camel component model. |
No - build tooling |
|
Maven BOM (pom only) and the resource bundle that jars family 1. |
Only as the delivery vehicle for family 1 |
|
CI, documentation generation, test and scaffolding code. Not shipped to a runtime. |
No - unsupported / build / examples |
The Kamelet execution runtime: the |
Lives in |
No - governed by the Camel Security Model |
The last row is the most consequential boundary statement: a defect in how a
Kamelet is executed (placeholder resolution, the kamelet: component, the
shared utility beans) is an apache/camel finding, not a catalog finding. A
defect in what a shipped template does by default is a catalog finding.
A report is in scope when it demonstrates that a shipped Kamelet template, in its default configuration, lets untrusted message data cross a trust boundary that an equivalent competently-written hand route would not have crossed - because the defect is in the template the catalog authored, not in how the operator wired it.
The catalog commits to a small set of properties on top of whatever the underlying Camel component already provides. The Camel Security Model’s property/severity table applies unchanged to the component layer; the table below is the catalog-template layer.
| Property the catalog upholds (default configuration) | What a violation looks like | Indicative severity |
|---|---|---|
A sink/action template that maps an untrusted inbound header or body into a dispatch-controlling position strips or fixes the Camel-internal dispatch headers it does not intend to expose |
A wire-supplied |
High to Critical (CVSS 7.5-9.8) |
A template does not pass untrusted message data to an expression/template/ query evaluator the Kamelet’s purpose did not call for |
The template feeds |
High to Critical (CVSS 8.1-9.8) |
A shipped template does not enable a security-relevant component default that
the Camel model classes as insecure (Java deserialisation on an untrusted
consumer, TLS verification disabled, an admin surface bound to |
Adding the Kamelet to a route and sending a message reaches the insecure behaviour with no risky property set |
Severity of the underlying Camel class; in scope |
Secret-bearing properties are declared so tooling can mask them
( |
A credential property is rendered or logged in plaintext by tooling that honoured the schema, because the Kamelet failed to mark it |
Medium (CVSS 4.0-6.5) |
Free-form destination-like properties constrain their accepted shape
( |
A property documented as an HTTP URL accepts a |
Low to Medium (CVSS 3.7-6.1); see the false-friend note in Out of scope |
These tiers are indicative. The PMC assigns the definitive CVSS per report. A property only counts here if the catalog has actually committed to it in a template, the README/developer guide, or a PMC statement.
A sink or action template that copies an untrusted inbound header or body into
a Camel-internal dispatch header (CamelHttpUri, CamelFileName,
Camel*DestinationName, CamelExecCommand*, CamelBeanMethodName, …) - or
that fails to strip such a header it does not consume - so that wire input
redirects the component. Many catalog templates already defend this (for
example http-sink performs removeHeader: CamelHttpUri before to: {{url}},
and extract-field-action sanitises a configurable header name). A new or
changed template that maps untrusted input into dispatch without that
discipline is the catalog analogue of the Camel header-injection CVE family.
A template that passes untrusted message data (not a {{property}}) to a
simple expression, a template language (Velocity, Freemarker, Mustache, MVEL,
JSLT, XJ, string-template, …), JSONPath/JQ, or a back-end query string the
Kamelet builds. The defect is the template doing this without the route author
asking; an operator binding a {{template}} / {{query}} / {{expression}}
property to untrusted data is out of scope (route-author responsibility,
mirroring Camel).
A template that adds a Camel component to the route with a security-relevant
option set to the insecure value by default (Java serialisation on a consumer
exposed to an untrusted broker, TLS/hostname verification disabled, a
permissive header filter, an unfiltered ObjectInputStream), reachable simply
by deploying the Kamelet. This is the Camel "insecure defaults" class scoped to
the template’s choice of defaults.
A property carrying a credential that is not declared format: password with
the credentials x-descriptors, so schema-honouring tooling exposes it; or a
destination-like property whose missing pattern: turns a documented operator
contract into reachable unintended behaviour. Triaged as low/medium hardening
unless it produces a concrete disclosure.
The following are not Kamelet Catalog vulnerabilities and will be closed as such, with a reference to this page.
-
A route author or operator binding a Kamelet property to untrusted data.
{{template}},{{query}},{{expression}},{{url}},{{executable}}, file paths and credentials are configuration. The catalog cannot decide on the operator’s behalf whether a bound value is trusted. Template-language Kamelets (velocity-template-action,jslt-action,freemarker-template-action,mvel-template-action,mustache-template-action,xj-template-action,string-template-action,chunk-template-action) and SQL/NoSQL/GraphQL Kamelets (postgresql-,mysql-,mariadb-,sqlserver-,oracle-database-,cassandra-,mongodb-,snowflake-,graphql-sink, …) evaluate or build their template/query from an operator-bound property. Wiring an untrusted source into that property is route-author error, exactly as in the Camel model. -
A Kamelet doing, by design, the dangerous thing it is named for.
exec-sink("Execute system commands") deliberately maps an inboundargs/ce-argsheader intoCamelExecCommandArgsand runsexec:{{executable}};ssh-sink,scp-sink,ssh-sourcerun remote commands/transfers. Placing such a Kamelet downstream of untrusted input is operator responsibility - the behaviour is the Kamelet’s documented contract, analogous to Camel’s "bean-based dispatch via internal headers is intentional" limitation. -
Network exposure of a source Kamelet.
webhook-source,http-source,http-secured-sourceand similar open aplatform-httplistener. The catalog does not add authentication except where a Kamelet’s name and properties say it does (-secured-variants expose auth options the operator must configure). Exposing a source to untrusted networks, or not configuring the offered auth, is operator responsibility. -
Explicitly-named insecure convenience Kamelets.
-not-secured-/kafka-not-secured-*Kamelets advertise their posture in the name and are development/test conveniences. Their lack of transport security is the documented contract, not a defect. -
Vulnerabilities in the underlying Camel component or its transitive dependencies. "Kamelet X uses component Y which had CVE Z" is a Camel / upstream finding unless the template configures Y insecurely by default. A Kamelet’s declared
mvn:dependencies are vetted only for Apache-license compatibility; their CVEs follow Camel’s third-party-dependency policy. -
Defects in the Kamelet execution runtime. The
kamelet:component,{{property}}placeholder binding andorg.apache.camel.kamelets.utils.*live inapache/camel; route such findings there. -
Denial of service via resource exhaustion. Unthrottled sources, oversized messages, expansion bombs - operators apply
throttle,circuitBreaker, resilience and JVM limits, exactly as in the Camel model. -
The
data:imageicon annotation as an injection vector. It is base64 metadata for catalog tooling, never executed by the route runtime; safe rendering of catalog metadata is the consuming UI’s concern. -
camel-kamelets-catalog"deserialises YAML". It parses only YAML bundled on its own build-time classpath into model objects; it is not an untrusted-document parser, and exposes no API that accepts caller-supplied YAML. -
Build, CI, scaffolding and test code (
script/,crds/generator,tests/,templates/,kamelets-maven-plugin) - separately authored, not shipped to a runtime. -
Reports from automated scanners with no proof of a concrete trust-boundary breach through a shipped template.
These look like vulnerabilities at first glance but are documented design points. They may be tightened over time through the normal upgrade-guide channel.
-
The
exec-sinkargument path is intentional. It reads an untrusted inbound header into command arguments by design; the Kamelet is literally named "Exec Sink" and lives in theSystemnamespace. The mitigation is operator placement, not a template change. -
Kafka source Kamelets default
deserializeHeaders: true. Inbound Kafka message headers are converted to their String representation by a fixedKafkaHeaderDeserializerbean (CAMEL-21843). This is a documented default with a per-Kamelet opt-out property; it is a String conversion, not Java object deserialisation. -
A
pattern:regex on a property is shape validation, not an attack control. It constrains what an operator may type (e.g. a URL must starthttp/https); it does not make an attacker-controlled bound value safe and is not an SSRF defence. See the false-friend note below. -
kamelet.verified=trueis a functional-test marker, not a security audit. It records that Citrus tests assert the Kamelet’s behaviour; it makes no security assertion. -
A Kamelet inherits the security posture of its underlying component. A report must show the template, not the Camel component, is the cause.
-
There are no global build-time or compile flags that change the security envelope. The catalog is data (YAML); the only security-relevant "variants" are per-Kamelet defaults and the explicitly-named insecure-convenience Kamelets, both covered above. "The project" is the catalog as released, not a configurable family of binaries.
Single highest-value note for an integrator:
-
An "action" Kamelet between an untrusted source and a sink is not a sanitiser, WAF, or trust boundary. It transforms or filters per its documented purpose only.
predicate-filter-action/header-matches-filter-actiondecide pass/drop on a JSONPath/header; they do not neutralise hostile content. -
A
pattern:regex looks like input security; it is operator-typo containment. It restricts scheme/shape, not trust. -
-secured-in a Kamelet name means "auth options exist", not "auth is on by default". The operator must configure them. -
kamelet.verified=truelooks like a security seal; it is a test marker.
For these assumptions to hold, the route author and operator must:
-
Treat a deployed Kamelet exactly like a route they wrote - it runs with their privileges and trust.
-
Load Kamelets only from a trusted, integrity-checked catalog. An entity that can add or modify a Kamelet definition has arbitrary code execution by design.
-
Bind every property from trusted configuration - never bind
{{template}}/{{query}}/{{expression}}/{{url}}/{{executable}}/ credentials / file paths from untrusted message data. -
Strip
Camelheaders from untrusted producers* before a sink Kamelet, even though many templates also do this for the dispatch headers they know:- from: uri: "platform-http:///ingest" steps: - removeHeaders: { pattern: "Camel*" } - to: "kamelet:http-sink?url=https://trusted/backend"
-
Not place command/transfer Kamelets (
exec-sink,ssh-*,scp-sink) downstream of untrusted input. -
Secure inbound source Kamelets with network controls and, where offered, the
-secured-auth options. -
Resolve credentials through a Camel vault, not plaintext Kamelet properties.
-
Pin the catalog and Camel versions and follow Camel security announcements.
When contributing or reviewing a Kamelet, these questions decide whether the change matches this model:
-
Does the template map an untrusted inbound header or body into a dispatch-controlling position? If so it must strip or fix every Camel-internal header it does not deliberately consume, before the dispatching step.
-
Does the template pass message data (not a
{{property}}) to an expression/template/query evaluator? If yes, that is the in-scope injection class - the evaluated input must be a bound property, not the body/headers. -
Does the template add a component with a security-relevant default? Ship the safe default; if a Kamelet must relax one, name it (e.g.
-not-secured-), document it, and get PMC sign-off. -
Does a property carry a secret? Mark it
format: passwordwithx-descriptors: [urn:camel:group:credentials]. -
Does a free-form property feed an endpoint URI or resource? Add a
pattern:to contain operator error - and remember it is not a trust control. -
Does the change relax a default or widen what a template forwards? It needs an upgrade-guide entry and PMC review.
The Kamelet Catalog uses the standard Apache Camel / ASF vulnerability process:
-
Read Apache Camel Security.
-
Email
private-security@camel.apache.orgwith the affected catalog version(s), the specific Kamelet, and a proof of concept that demonstrates the trust-boundary breach through a shipped template in its default configuration. -
Do not open a public issue, pull request, or mailing-list/social post about an unpublished vulnerability. Follow the ASF Security team’s instructions.
Reports matching In-scope vulnerability classes are triaged on the private list, fixed in a coordinated release, and published as a CVE advisory under the Camel project. Reports matching Out of scope or Known limitations are closed with a reference to this page.
The closed set of outcomes for a report, scanner finding, or AI analysis:
| Disposition | Meaning | Licensed by |
|---|---|---|
|
A shipped template, in default configuration, turns untrusted data into execution / redirection / unsafe deserialisation / remote-resource fetch / auth bypass that the template - not the operator’s wiring - introduced. |
In-scope vulnerability classes |
|
No property above is broken, but a template could reasonably strip a header,
tighten a |
Missing or incorrect secret / constraint metadata |
|
Requires attacker control of a |
Out of scope, item 1 |
|
Requires the Kamelet to do the dangerous thing it is explicitly named for, or network exposure of a source. |
Out of scope, items 2-4 |
|
The defect is in the |
Component families, last row |
|
Lands in |
Component families / Out of scope |
|
Concerns a behaviour Known limitations documents (Kafka header
deserialisation, |
Known limitations |
|
Underlying Camel component or transitive dependency CVE not caused by the template. |
Out of scope, item 5 |
|
Cannot be routed to any of the above - triggers a revision of this model rather than an ad-hoc call. |
this section |
Revise this document when: a new Kamelet introduces a sink-side dispatch
surface or evaluates message data as an expression/template by default; a
template ships an insecure component default; the catalog gains a runtime that
parses untrusted Kamelet YAML; camel-kamelets-utils returns to this
repository; a script/ / example artifact is promoted into shipped runtime; or
a report arrives that cannot be cleanly assigned a disposition above.
The structural inferences in the initial draft were put to the Apache Camel PMC and confirmed on 2026-05-15. They are now folded into the body as fact; this record preserves the chain of authority so a triager can cite "(maintainer, 2026-05)" when closing a report.
| Question put to the PMC | Ratified answer (now in the body) |
|---|---|
Is the catalog covered by Camel’s existing security process, with this page as the Kamelet-specific annex? |
Yes. |
Must a sink/action template that maps untrusted input into a dispatch position strip the dispatch headers it does not consume - committed property or per-Kamelet practice? |
Committed property. Every such new or changed template must satisfy it. (Security properties / Guidance for Kamelet authors and reviewers.) |
Is loading a Kamelet from an untrusted/user-writable source "attacker is a trusted route author - RCE by design, out of scope"? |
Yes. (Trust boundaries; Downstream responsibilities.) |
Is |
Yes - supported default, String conversion only, per-Kamelet opt-out
documented; a report against it is |
Are the |
Out of scope as a "vulnerability" - documented dev/test convenience, explicit in the name. (Out of scope.) |
Is |
Out of model - the deserialiser is the consumer’s Kubernetes client / Fabric8, not this repository’s code. (Component families.) |
Document placement and pointers (this page, root |
Confirmed and in place. (Related documents.) |
Publish a machine-readable triage sidecar (per-Kamelet trust / in-out / dispositions) for automated review? |
Deferred by PMC decision - revisit once the prose model has lived through a few triage cycles. This is a deliberate non-goal for now, not an open question. (Conditions that would change this model.) |
A future revision is triggered by the events listed under
Conditions that would change this model - in particular a report that cannot
be assigned a disposition, which is treated as a MODEL-GAP and a prompt to
revise this page rather than make an ad-hoc call.
-
Apache Camel Security Model - the parent model this page specialises.
-
Kamelets Developer Guide - how Kamelets are authored.
-
Kamelet CRD specification - the YAML contract.
-
Apache Camel Security - the public advisory index and reporting process.
-
SECURITY.md(repository root) - the GitHub-rendered security pointer.