This is an automated email from the ASF dual-hosted git repository.
davsclaus 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 fcb828d23fdd chore(docs): escape wildcards in monospace so pages
render valid HTML (#26380)
fcb828d23fdd is described below
commit fcb828d23fdd6f90dbee324b5eb0f1e9004d8b97
Author: Adriano Machado <[email protected]>
AuthorDate: Mon Sep 14 00:34:03 2026 -0400
chore(docs): escape wildcards in monospace so pages render valid HTML
(#26380)
A * or # inside a single-backtick span is still parsed as a formatting
mark, so spans such as `mail.smtp.*` or `core/camel-*` pair up with a
later * and produce mis-nested HTML like <code>…<strong></code>…</strong>.
Browsers tolerate it, but the website's HTML-to-Markdown step then loses
article.doc and skips the page, so its .md mirror (linked from llms.txt)
returns 404 (apache/camel-website#1746).
Use literal monospace (`+…+`) for those spans, double backticks where a
span is followed by a quote, and `++/model ++` for a span with a
trailing space. Also fixes spans that stayed valid HTML but still
rendered bold text instead of the * characters. Catalog doc copies are
synced.
_Claude Code on behalf of Adriano Machado (@ammachado)_
_This was generated by an AI agent and may contain inaccuracies.
Please verify before relying on it._
---
.../camel/catalog/docs/ai-tool-component.adoc | 6 +--
.../apache/camel/catalog/docs/mail-component.adoc | 4 +-
.../org/apache/camel/catalog/docs/mcp-server.adoc | 8 ++--
.../org/apache/camel/catalog/docs/mdc.adoc | 4 +-
.../apache/camel/catalog/docs/opa-component.adoc | 2 +-
.../org/apache/camel/catalog/docs/yaml-dsl.adoc | 2 +-
.../src/main/docs/ai-tool-component.adoc | 6 +--
.../camel-mcp-server/src/main/docs/mcp-server.adoc | 8 ++--
.../camel-mail/src/main/docs/mail-component.adoc | 4 +-
components/camel-mdc/src/main/docs/mdc.adoc | 4 +-
.../camel-opa/src/main/docs/opa-component.adoc | 2 +-
.../ROOT/pages/camel-4x-upgrade-guide-4_14.adoc | 10 ++---
.../ROOT/pages/camel-4x-upgrade-guide-4_18.adoc | 16 +++----
.../ROOT/pages/camel-4x-upgrade-guide-4_19.adoc | 6 +--
.../ROOT/pages/camel-4x-upgrade-guide-4_21.adoc | 36 ++++++++--------
.../ROOT/pages/camel-4x-upgrade-guide-4_22.adoc | 4 +-
.../ROOT/pages/camel-4x-upgrade-guide-4_23.adoc | 16 +++----
.../modules/ROOT/pages/camel-jbang-mcp.adoc | 2 +-
.../modules/ROOT/pages/camel-jbang-tui.adoc | 8 ++--
.../modules/ROOT/pages/security-model.adoc | 50 +++++++++++-----------
.../camel-yaml-dsl/src/main/docs/yaml-dsl.adoc | 2 +-
21 files changed, 100 insertions(+), 100 deletions(-)
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
index 911e5feb21c9..13e9da463c4e 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
@@ -147,7 +147,7 @@ YAML::
=== Complex Parameters with argSchema
-Use `argSchema` when the flat `parameter.*` syntax is not expressive enough
for nested objects, arrays, or other advanced JSON Schema constructs.
`argSchema` is mutually exclusive with `parameter.*`.
+Use `argSchema` when the flat `+parameter.*+` syntax is not expressive enough
for nested objects, arrays, or other advanced JSON Schema constructs.
`argSchema` is mutually exclusive with `+parameter.*+`.
[tabs]
====
@@ -199,7 +199,7 @@ The root schema must be a JSON Schema object with a
top-level `properties` map.
=== Structured Tool Output (outputSchema)
-MCP tools can declare an `outputSchema` and return `structuredContent` (typed
JSON) so clients parse tool results reliably instead of re-interpreting free
text. Use `outputParameter.*` for flat field definitions or `outputSchema` for
raw JSON Schema (mirroring the input-side `parameter.*` / `argSchema` pattern).
The two options are mutually exclusive.
+MCP tools can declare an `outputSchema` and return `structuredContent` (typed
JSON) so clients parse tool results reliably instead of re-interpreting free
text. Use `+outputParameter.*+` for flat field definitions or `outputSchema`
for raw JSON Schema (mirroring the input-side `+parameter.*+` / `argSchema`
pattern). The two options are mutually exclusive.
When an output schema is declared, the route body must be JSON (a JSON string,
`Map`, or `List`). Camel parses it into structured content and forwards it
through the MCP bridge as `CallToolResult.structuredContent`. The text
representation remains available for LLM adapters (LangChain4j, Spring AI) that
consume string tool results.
@@ -232,7 +232,7 @@ YAML::
----
====
-Flat `outputParameter.*` options use the same sub-option syntax as input
`parameter.*`:
+Flat `+outputParameter.*+` options use the same sub-option syntax as input
`+parameter.*+`:
* `outputParameter.NAME=TYPE` — field type (`string`, `integer`, `number`,
`boolean`)
* `outputParameter.NAME.description=TEXT` — field description in the generated
JSON Schema
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
index a614e7fd5e8a..71ff5a3698f9 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
@@ -899,11 +899,11 @@ For example, to provide a dynamic uuid in
`mail.smtp.from` (SMTP MAIL command):
NOTE: This is only supported when *not* using a custom `JavaMailSender`.
WARNING: This feature is *disabled by default* and must be explicitly enabled
with
-`useJavaMailSessionPropertiesFromHeaders=true`. The `mail.smtp.*` /
`mail.smtps.*` keys are a
+`useJavaMailSessionPropertiesFromHeaders=true`. The `+mail.smtp.*+` /
`+mail.smtps.*+` keys are a
Camel-internal namespace that is not filtered by any `HeaderFilterStrategy`,
so if these headers can
originate from data crossing a trust boundary (for example HTTP query
parameters, or JMS/Kafka
messages from untrusted producers) an attacker could weaken transport security
(such as
`mail.smtp.ssl.trust` or `mail.smtp.starttls.enable`) or redirect the SMTP
connection. Only enable
the option when these headers are set exclusively by trusted route logic, and
strip the namespace
-with `removeHeaders("mail.smtp.*", "mail.smtps.*")` before the producer when
bridging an untrusted
+with `+removeHeaders("mail.smtp.*", "mail.smtps.*")+` before the producer when
bridging an untrusted
source. See the xref:manual::security-model.adoc[Camel Security Model] for the
general pattern.
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
index 78ed283ed140..244c4f304a53 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
@@ -51,9 +51,9 @@ Engine resolution mirrors the platform-http engine: a bean of
type
`McpServerEngine` in the Camel registry wins; otherwise the engine is
discovered on the classpath. Other runtimes plug native engines through the
same SPI: on Quarkus the `camel-quarkus-mcp-server` extension serves through
-the Quarkiverse `quarkus-mcp-server` (configured via `quarkus.mcp.server.*`),
+the Quarkiverse `quarkus-mcp-server` (configured via `+quarkus.mcp.server.*+`),
and on Spring Boot the starter serves through the Spring AI MCP server
-(configured via `spring.ai.mcp.server.*`). Bridge behavior — tag selection,
+(configured via `+spring.ai.mcp.server.*+`). Bridge behavior — tag selection,
timeout, sanitization — is identical on every runtime and verified by a shared
conformance test kit.
@@ -163,8 +163,8 @@ camel.server.mcp-instructions = Use these tools to operate
the integration.
camel.server.mcp-server-icons =
[{"src":"https://example.com/icon.png","mimeType":"image/png","sizes":["48x48"],"theme":"light"}]
----
-Tag patterns support wildcards: use `*` to expose all tagged tools, or a
-prefix pattern like `crm*` to expose all tags starting with `crm`:
+Tag patterns support wildcards: use `+*+` to expose all tagged tools, or a
+prefix pattern like `+crm*+` to expose all tags starting with `crm`:
The MCP endpoint is then served at `http://<host>:<port>/mcp` on the Camel
main HTTP server. Any MCP client can connect over streamable HTTP, for
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
index 708d9ca4a8d0..fcaae53169ac 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
@@ -70,6 +70,6 @@ The configuration properties for the MDC component are:
|=======================================================================
|Option |Default |Description
|`camel.mdc.enabled`| false | Enable the MDC logging.
-|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would
like to trace in MDC. Use `*` value as a wildcard to include more exchange
headers at once, for example `CAMEL_HTTP_*` or only the `*` to include all
available exchange headers.
-|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you
would like to trace in MDC. Use `*` value as a wildcard to include more
exchange properties at once, for example `property_*` or only the `*` to
include all available exchange properties.
+|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would
like to trace in MDC. Use `+*+` value as a wildcard to include more exchange
headers at once, for example `+CAMEL_HTTP_*+` or only the `+*+` to include all
available exchange headers.
+|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you
would like to trace in MDC. Use `+*+` value as a wildcard to include more
exchange properties at once, for example `+property_*+` or only the `+*+` to
include all available exchange properties.
|=======================================================================
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
index e57b5c85ee49..b20e097915a9 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
@@ -180,7 +180,7 @@ allow if {
}
------------------------------------------------------------
-`includeProperties` takes a comma-separated list, or `*` for all of them, and
matches names case-insensitively.
+`includeProperties` takes a comma-separated list, or `+*+` for all of them,
and matches names case-insensitively.
Unlike `includeHeaders` it is *empty by default*: exchange properties are
mostly used to carry state between
processors, so sending them all would be noise the policy has to wade through.
Only custom properties are sent —
Camel's own internal exchange properties are never included.
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
index 6773f8a975c4..e8d9b667269a 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
@@ -837,7 +837,7 @@ a simpler, more predictable schema structure. The classic
schema remains the def
=== Using the schemas with IDEs
The classic schema is registered in the https://www.schemastore.org/[JSON
Schema Store] and is automatically
-used by IDEs like VS Code and IntelliJ for files matching `*.camel.yaml` and
`*.camelk.yaml`.
+used by IDEs like VS Code and IntelliJ for files matching `+*.camel.yaml+` and
`+*.camelk.yaml+`.
To use the canonical schema instead, configure your IDE to point to the
canonical schema URL:
diff --git
a/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
b/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
index 911e5feb21c9..13e9da463c4e 100644
--- a/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
+++ b/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
@@ -147,7 +147,7 @@ YAML::
=== Complex Parameters with argSchema
-Use `argSchema` when the flat `parameter.*` syntax is not expressive enough
for nested objects, arrays, or other advanced JSON Schema constructs.
`argSchema` is mutually exclusive with `parameter.*`.
+Use `argSchema` when the flat `+parameter.*+` syntax is not expressive enough
for nested objects, arrays, or other advanced JSON Schema constructs.
`argSchema` is mutually exclusive with `+parameter.*+`.
[tabs]
====
@@ -199,7 +199,7 @@ The root schema must be a JSON Schema object with a
top-level `properties` map.
=== Structured Tool Output (outputSchema)
-MCP tools can declare an `outputSchema` and return `structuredContent` (typed
JSON) so clients parse tool results reliably instead of re-interpreting free
text. Use `outputParameter.*` for flat field definitions or `outputSchema` for
raw JSON Schema (mirroring the input-side `parameter.*` / `argSchema` pattern).
The two options are mutually exclusive.
+MCP tools can declare an `outputSchema` and return `structuredContent` (typed
JSON) so clients parse tool results reliably instead of re-interpreting free
text. Use `+outputParameter.*+` for flat field definitions or `outputSchema`
for raw JSON Schema (mirroring the input-side `+parameter.*+` / `argSchema`
pattern). The two options are mutually exclusive.
When an output schema is declared, the route body must be JSON (a JSON string,
`Map`, or `List`). Camel parses it into structured content and forwards it
through the MCP bridge as `CallToolResult.structuredContent`. The text
representation remains available for LLM adapters (LangChain4j, Spring AI) that
consume string tool results.
@@ -232,7 +232,7 @@ YAML::
----
====
-Flat `outputParameter.*` options use the same sub-option syntax as input
`parameter.*`:
+Flat `+outputParameter.*+` options use the same sub-option syntax as input
`+parameter.*+`:
* `outputParameter.NAME=TYPE` — field type (`string`, `integer`, `number`,
`boolean`)
* `outputParameter.NAME.description=TEXT` — field description in the generated
JSON Schema
diff --git a/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
b/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
index 78ed283ed140..244c4f304a53 100644
--- a/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
+++ b/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
@@ -51,9 +51,9 @@ Engine resolution mirrors the platform-http engine: a bean of
type
`McpServerEngine` in the Camel registry wins; otherwise the engine is
discovered on the classpath. Other runtimes plug native engines through the
same SPI: on Quarkus the `camel-quarkus-mcp-server` extension serves through
-the Quarkiverse `quarkus-mcp-server` (configured via `quarkus.mcp.server.*`),
+the Quarkiverse `quarkus-mcp-server` (configured via `+quarkus.mcp.server.*+`),
and on Spring Boot the starter serves through the Spring AI MCP server
-(configured via `spring.ai.mcp.server.*`). Bridge behavior — tag selection,
+(configured via `+spring.ai.mcp.server.*+`). Bridge behavior — tag selection,
timeout, sanitization — is identical on every runtime and verified by a shared
conformance test kit.
@@ -163,8 +163,8 @@ camel.server.mcp-instructions = Use these tools to operate
the integration.
camel.server.mcp-server-icons =
[{"src":"https://example.com/icon.png","mimeType":"image/png","sizes":["48x48"],"theme":"light"}]
----
-Tag patterns support wildcards: use `*` to expose all tagged tools, or a
-prefix pattern like `crm*` to expose all tags starting with `crm`:
+Tag patterns support wildcards: use `+*+` to expose all tagged tools, or a
+prefix pattern like `+crm*+` to expose all tags starting with `crm`:
The MCP endpoint is then served at `http://<host>:<port>/mcp` on the Camel
main HTTP server. Any MCP client can connect over streamable HTTP, for
diff --git a/components/camel-mail/src/main/docs/mail-component.adoc
b/components/camel-mail/src/main/docs/mail-component.adoc
index a614e7fd5e8a..71ff5a3698f9 100644
--- a/components/camel-mail/src/main/docs/mail-component.adoc
+++ b/components/camel-mail/src/main/docs/mail-component.adoc
@@ -899,11 +899,11 @@ For example, to provide a dynamic uuid in
`mail.smtp.from` (SMTP MAIL command):
NOTE: This is only supported when *not* using a custom `JavaMailSender`.
WARNING: This feature is *disabled by default* and must be explicitly enabled
with
-`useJavaMailSessionPropertiesFromHeaders=true`. The `mail.smtp.*` /
`mail.smtps.*` keys are a
+`useJavaMailSessionPropertiesFromHeaders=true`. The `+mail.smtp.*+` /
`+mail.smtps.*+` keys are a
Camel-internal namespace that is not filtered by any `HeaderFilterStrategy`,
so if these headers can
originate from data crossing a trust boundary (for example HTTP query
parameters, or JMS/Kafka
messages from untrusted producers) an attacker could weaken transport security
(such as
`mail.smtp.ssl.trust` or `mail.smtp.starttls.enable`) or redirect the SMTP
connection. Only enable
the option when these headers are set exclusively by trusted route logic, and
strip the namespace
-with `removeHeaders("mail.smtp.*", "mail.smtps.*")` before the producer when
bridging an untrusted
+with `+removeHeaders("mail.smtp.*", "mail.smtps.*")+` before the producer when
bridging an untrusted
source. See the xref:manual::security-model.adoc[Camel Security Model] for the
general pattern.
diff --git a/components/camel-mdc/src/main/docs/mdc.adoc
b/components/camel-mdc/src/main/docs/mdc.adoc
index 708d9ca4a8d0..fcaae53169ac 100644
--- a/components/camel-mdc/src/main/docs/mdc.adoc
+++ b/components/camel-mdc/src/main/docs/mdc.adoc
@@ -70,6 +70,6 @@ The configuration properties for the MDC component are:
|=======================================================================
|Option |Default |Description
|`camel.mdc.enabled`| false | Enable the MDC logging.
-|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would
like to trace in MDC. Use `*` value as a wildcard to include more exchange
headers at once, for example `CAMEL_HTTP_*` or only the `*` to include all
available exchange headers.
-|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you
would like to trace in MDC. Use `*` value as a wildcard to include more
exchange properties at once, for example `property_*` or only the `*` to
include all available exchange properties.
+|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would
like to trace in MDC. Use `+*+` value as a wildcard to include more exchange
headers at once, for example `+CAMEL_HTTP_*+` or only the `+*+` to include all
available exchange headers.
+|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you
would like to trace in MDC. Use `+*+` value as a wildcard to include more
exchange properties at once, for example `+property_*+` or only the `+*+` to
include all available exchange properties.
|=======================================================================
diff --git a/components/camel-opa/src/main/docs/opa-component.adoc
b/components/camel-opa/src/main/docs/opa-component.adoc
index e57b5c85ee49..b20e097915a9 100644
--- a/components/camel-opa/src/main/docs/opa-component.adoc
+++ b/components/camel-opa/src/main/docs/opa-component.adoc
@@ -180,7 +180,7 @@ allow if {
}
------------------------------------------------------------
-`includeProperties` takes a comma-separated list, or `*` for all of them, and
matches names case-insensitively.
+`includeProperties` takes a comma-separated list, or `+*+` for all of them,
and matches names case-insensitively.
Unlike `includeHeaders` it is *empty by default*: exchange properties are
mostly used to carry state between
processors, so sending them all would be noise the policy has to wade through.
Only custom properties are sent —
Camel's own internal exchange properties are never included.
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
index 1c5d0639007a..2799ad236521 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
@@ -1047,12 +1047,12 @@ without changes. Routes that set the headers by their
literal string value
Because the renamed prefixes now begin with `Camel`, they are stripped by the
standard transport `HeaderFilterStrategy` (`HttpHeaderFilterStrategy`, etc.)
-when crossing a transport boundary, by design — `Camel*` headers are
+when crossing a transport boundary, by design — `+Camel*+` headers are
framework-internal and are not propagated over the wire. Routes that bridge an
external transport (HTTP, JMS, ...) into a `solr:` producer and want to drive
Solr document fields or query parameters from a header supplied by the sender
must therefore carry the value in a non-`Camel`-prefixed application header and
-map it to the appropriate `CamelSolrField.*` / `CamelSolrParam.*` header in the
+map it to the appropriate `+CamelSolrField.*+` / `+CamelSolrParam.*+` header
in the
route between the transport `from` and the `solr:` `to`.
=== camel-dapr - potential breaking change
@@ -1263,9 +1263,9 @@ effect from 4.14.9 onwards; see the
entry below.
====
-`UndertowHeaderFilterStrategy` now also filters the legacy `websocket.*`
-Exchange-header prefix (in addition to the `Camel*` / `camel*` /
-`org.apache.camel.*` prefixes it already filtered). This applies to both the
+`UndertowHeaderFilterStrategy` now also filters the legacy `+websocket.*+`
+Exchange-header prefix (in addition to the `+Camel*+` / `+camel*+` /
+`+org.apache.camel.*+` prefixes it already filtered). This applies to both the
in (wire -> exchange) and out (exchange -> wire) directions and follows the
dedicated-filter-strategy shape used by CAMEL-23532 for
`camel-vertx-websocket` / `camel-atmosphere-websocket` / `camel-iggy`.
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
index 8787e26c2f1e..c4923b32658c 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
@@ -186,7 +186,7 @@ and any type a cluster peer sent was routed.
When no explicit pattern is configured, the JVM-wide `jdk.serialFilter` is
honoured if set,
otherwise a conservative default allow-list is applied
-(`!java.net.**;java.**;javax.**;org.apache.camel.**;!*`), matching the default
the other components
+(`+!java.net.**;java.**;javax.**;org.apache.camel.**;!*+`), matching the
default the other components
that can receive Java-serialized payloads have applied since 4.18.3. Routes
that exchange their own
classes over the cluster must widen it through the new `deserializationFilter`
endpoint option, for
example:
@@ -633,7 +633,7 @@ messages from untrusted producers) could override
transport-security settings su
`mail.smtp.ssl.trust` or `mail.smtp.starttls.enable`, or redirect the SMTP
connection.
This behaviour is now disabled by default. Routes that legitimately rely on
per-message
-`mail.smtp.*` / `mail.smtps.*` headers must opt back in on the endpoint:
+`+mail.smtp.*+` / `+mail.smtps.*+` headers must opt back in on the endpoint:
._Java-only: opting in to JavaMail session properties from headers_
[source,java]
@@ -642,7 +642,7 @@ This behaviour is now disabled by default. Routes that
legitimately rely on per-
----
Even with the opt-in, route authors should still strip the namespace with
-`removeHeaders("mail.smtp.*", "mail.smtps.*")` between any untrusted ingress
and the mail producer.
+`+removeHeaders("mail.smtp.*", "mail.smtps.*")+` between any untrusted ingress
and the mail producer.
In addition, the inbound `MailHeaderFilterStrategy` now blocks the
`mail.smtp.` / `mail.smtps.`
prefix as well, so an external mail message can no longer inject these into a
downstream exchange.
@@ -1394,12 +1394,12 @@ without changes. Routes that set the headers by their
literal string value
Because the renamed prefixes now begin with `Camel`, they are stripped by the
standard transport `HeaderFilterStrategy` (`HttpHeaderFilterStrategy`, etc.)
-when crossing a transport boundary, by design — `Camel*` headers are
+when crossing a transport boundary, by design — `+Camel*+` headers are
framework-internal and are not propagated over the wire. Routes that bridge an
external transport (HTTP, JMS, ...) into a `solr:` producer and want to drive
Solr document fields or query parameters from a header supplied by the sender
must therefore carry the value in a non-`Camel`-prefixed application header and
-map it to the appropriate `CamelSolrField.*` / `CamelSolrParam.*` header in the
+map it to the appropriate `+CamelSolrField.*+` / `+CamelSolrParam.*+` header
in the
route between the transport `from` and the `solr:` `to`.
=== camel-dapr - potential breaking change
@@ -1802,9 +1802,9 @@ effect from 4.18.4 onwards; see the
entry below.
====
-`UndertowHeaderFilterStrategy` now also filters the legacy `websocket.*`
-Exchange-header prefix (in addition to the `Camel*` / `camel*` /
-`org.apache.camel.*` prefixes it already filtered). This applies to both the
+`UndertowHeaderFilterStrategy` now also filters the legacy `+websocket.*+`
+Exchange-header prefix (in addition to the `+Camel*+` / `+camel*+` /
+`+org.apache.camel.*+` prefixes it already filtered). This applies to both the
in (wire -> exchange) and out (exchange -> wire) directions and follows the
dedicated-filter-strategy shape used by CAMEL-23532 for
`camel-vertx-websocket` / `camel-atmosphere-websocket` / `camel-iggy`.
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
index 5e4a331e4066..ffb0c2d2daa4 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
@@ -323,9 +323,9 @@ After:
</dependency>
----
-You will also need to change any imports of classes in
`org.apache.camel.test.junit5.*` to `import org.apache.camel.test.junit6.*`.
+You will also need to change any imports of classes in
`+org.apache.camel.test.junit5.*+` to `+import org.apache.camel.test.junit6.*+`.
-Similarly, for camel-test-main-junit5 you would need to change any imports of
classes in `org.apache.camel.test.main.junit5.*` to
`org.apache.camel.test.main.junit6.*`, and the dependency in your pom.xml would
change from:
+Similarly, for camel-test-main-junit5 you would need to change any imports of
classes in `+org.apache.camel.test.main.junit5.*+` to
`+org.apache.camel.test.main.junit6.*+`, and the dependency in your pom.xml
would change from:
Before:
[source,xml]
@@ -349,7 +349,7 @@ After:
</dependency>
----
-Finally, for camel-test-spring-junit5 any imports would change from
`org.apache.camel.test.spring.junit5.*` to `import
org.apache.camel.test.spring.junit6.*` and the dependency change would be :
+Finally, for camel-test-spring-junit5 any imports would change from
`+org.apache.camel.test.spring.junit5.*+` to `+import
org.apache.camel.test.spring.junit6.*+` and the dependency change would be :
Before:
[source,xml]
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
index 94472b7edfa8..ed522d0008c1 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
@@ -408,9 +408,9 @@ Set `validateAuth=false` explicitly only when intentionally
serving unauthentica
=== camel-kafka / Spring Boot
-When using `camel-kafka-starter` with Spring Boot, the standard
`spring.kafka.*` properties are now automatically
+When using `camel-kafka-starter` with Spring Boot, the standard
`+spring.kafka.*+` properties are now automatically
bridged to the Camel Kafka component configuration (CAMEL-22760). This means
you no longer need to duplicate
-Kafka settings under both `spring.kafka.*` and `camel.component.kafka.*`.
+Kafka settings under both `+spring.kafka.*+` and `+camel.component.kafka.*+`.
The bridged properties include `bootstrap-servers`, `security.protocol`,
SSL/TLS settings (keystore, truststore),
`consumer.group-id`, `client-id`, and SASL properties (`sasl.mechanism`,
`sasl.jaas.config`, `sasl.kerberos.service.name`).
@@ -427,8 +427,8 @@ camel.component.kafka.bridge-spring-kafka-properties=false
=== Default deserialization filter tightened
The default `ObjectInputFilter` pattern that ships with the components listed
below has been tightened
-to explicitly deny classes under `java.net.**` before allowing the rest of
`java.**`, `javax.**` and
-`org.apache.camel.**`. The previous default did not deny `java.net.**`, which
meant classes whose
+to explicitly deny classes under `+java.net.**+` before allowing the rest of
`+java.**+`, `+javax.**+` and
+`+org.apache.camel.**+`. The previous default did not deny `+java.net.**+`,
which meant classes whose
`hashCode`/`equals` methods perform network I/O (notably `java.net.URL` and
`java.net.InetAddress`)
could be deserialized by the in-code default.
@@ -446,8 +446,8 @@ The new default is:
!java.net.**;java.**;javax.**;org.apache.camel.**;!*
----
-(or `!java.net.**;java.**;org.apache.camel.**;!*` for the aggregation
repository components, which
-do not include `javax.**`).
+(or `+!java.net.**;java.**;org.apache.camel.**;!*+` for the aggregation
repository components, which
+do not include `+javax.**+`).
The endpoint-level option `deserializationFilter` and the JVM-wide system
property
`-Djdk.serialFilter` continue to override this default. Applications that have
a legitimate need to
@@ -1018,12 +1018,12 @@ without changes. Routes that set the headers by their
literal string value
Because the renamed prefixes now begin with `Camel`, they are stripped by the
standard transport `HeaderFilterStrategy` (`HttpHeaderFilterStrategy`, etc.)
-when crossing a transport boundary, by design — `Camel*` headers are
+when crossing a transport boundary, by design — `+Camel*+` headers are
framework-internal and are not propagated over the wire. Routes that bridge an
external transport (HTTP, JMS, ...) into a `solr:` producer and want to drive
Solr document fields or query parameters from a header supplied by the sender
must therefore carry the value in a non-`Camel`-prefixed application header and
-map it to the appropriate `CamelSolrField.*` / `CamelSolrParam.*` header in the
+map it to the appropriate `+CamelSolrField.*+` / `+CamelSolrParam.*+` header
in the
route between the transport `from` and the `solr:` `to`.
=== camel-aws2-s3
@@ -1079,8 +1079,8 @@ The HTTP components (which share `camel-http-common`) now
apply a Java deseriali
`allowJavaSerializedObject` / `transferException` path, aligning them with
`camel-netty-http`, `camel-jms`
and `camel-vertx-http`. A new `deserializationFilter` component option (same
syntax as `jdk.serialFilter`)
can be set to customise it; when unset, the JVM-wide `jdk.serialFilter` is
used if present, otherwise a
-conservative default filter (denying `java.net.**`, allowing `java.**` /
`javax.**` /
-`org.apache.camel.**`, with JEP-290 graph-shape limits) is applied. This is a
defense-in-depth measure on
+conservative default filter (denying `+java.net.**+`, allowing `+java.**+` /
`+javax.**+` /
+`+org.apache.camel.**+`, with JEP-290 graph-shape limits) is applied. This is
a defense-in-depth measure on
an already opt-in path; a serialized payload that was accepted before may now
be rejected if it references
a denied class.
@@ -1485,9 +1485,9 @@ effect from 4.22.0 onwards; see the
entry in the 4.21 to 4.22 upgrade guide.
====
-`UndertowHeaderFilterStrategy` now also filters the legacy `websocket.*`
-Exchange-header prefix (in addition to the `Camel*` / `camel*` /
-`org.apache.camel.*` prefixes it already filtered). This applies to both the
+`UndertowHeaderFilterStrategy` now also filters the legacy `+websocket.*+`
+Exchange-header prefix (in addition to the `+Camel*+` / `+camel*+` /
+`+org.apache.camel.*+` prefixes it already filtered). This applies to both the
in (wire -> exchange) and out (exchange -> wire) directions and follows the
dedicated-filter-strategy shape used by CAMEL-23532 for
`camel-vertx-websocket` / `camel-atmosphere-websocket` / `camel-iggy`.
@@ -2154,10 +2154,10 @@ headers and are unchanged.
`KafkaConstants.OVERRIDE_TOPIC` and `KafkaConstants.OVERRIDE_TIMESTAMP` are
producer-read headers consulted by `KafkaProducer.evaluateTopic()` and the
timestamp override path. The rename also closes the cross-transport
-propagation gap where these headers, in their previous `kafka.*` form,
+propagation gap where these headers, in their previous `+kafka.*+` form,
would pass through `HttpHeaderFilterStrategy` (which only filters the
`Camel` prefix) on an upstream HTTP / REST consumer wired to a Kafka
-producer in the same route. With the new `CamelKafka*` values, the default
+producer in the same route. With the new `+CamelKafka*+` values, the default
filter strategy strips them at the transport boundary.
Routes that reference the constants symbolically (for example
@@ -2238,7 +2238,7 @@ at the old filenames; routes referencing the dataformats
by `name` are unaffecte
=== camel-platform-http-main
-Two new optional configuration properties are available on both
`camel.server.*` and `camel.management.*`
+Two new optional configuration properties are available on both
`+camel.server.*+` and `+camel.management.*+`
for the embedded HTTP server:
* `jwtIssuer` — when set, validates the `iss` (issuer) claim of incoming JWT
tokens.
@@ -2389,9 +2389,9 @@ The in-code default `ObjectInputFilter` shipped by the
following components now
The new defaults are:
-*
`!java.net.**;java.**;javax.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*`
+*
`+!java.net.**;java.**;javax.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*+`
(camel-infinispan, camel-mina, camel-netty, camel-netty-http,
camel-vertx-http)
-*
`!java.net.**;java.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*`
+*
`+!java.net.**;java.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*+`
(camel-leveldb, camel-cassandraql, camel-consul, camel-sql)
These limits provide defense-in-depth so that operators who have not set
`-Djdk.serialFilter` still get
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
index 565d85c70ada..a964fb36ea5b 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
@@ -1943,8 +1943,8 @@ from("direct:next")
----
The sibling websocket components are not affected by this change:
`camel-undertow`
-keeps the `websocket.*` values in `UndertowConstants` (as documented in the
4.18
-upgrade guide), and `camel-vertx-websocket` keeps its `CamelVertxWebsocket.*`
values.
+keeps the `+websocket.*+` values in `UndertowConstants` (as documented in the
4.18
+upgrade guide), and `camel-vertx-websocket` keeps its
`+CamelVertxWebsocket.*+` values.
Note that `WebsocketConstants.SEND_TO_ALL` is not read by this component.
Broadcast is
selected through the `sendToAll` endpoint option, not through the header; the
constant
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
index b87d2913d5d9..e8836d94d130 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
@@ -700,7 +700,7 @@ the Camel message. That strategy filters the `mail.smtp.`
and `mail.smtps.` pref
path in addition to `Camel*`/`camel*`, so the data format now filters the same
namespace the mail
consumer has filtered since 4.14.9/4.18.4/4.22.0.
-Routes that relied on `mail.smtp.*` or `mail.smtps.*` headers arriving on the
exchange from an
+Routes that relied on `+mail.smtp.*+` or `+mail.smtps.*+` headers arriving on
the exchange from an
unmarshalled MIME message must set those values explicitly on the route
instead. Ordinary
application headers are unaffected.
@@ -1037,8 +1037,8 @@ when an endpoint is created, so existing subclasses
continue to behave as before
=== camel-jetty
`enableCORS=true` added `new CrossOriginFilter()` with no init parameters, so
Jetty's own defaults
-applied: `allowedOrigins=*` together with `allowCredentials=true`. Since the
filter reflects the request's
-origin rather than sending `*`, that is the credentialed any-origin
configuration the fetch specification
+applied: `+allowedOrigins=*+` together with `allowCredentials=true`. Since the
filter reflects the request's
+origin rather than sending `+*+`, that is the credentialed any-origin
configuration the fetch specification
refuses to express — reflecting the origin being the usual way around that
rule. An option named "enable
CORS" should not mean "every origin, with credentials".
@@ -1653,10 +1653,10 @@ system property, or inject it from an external secret
store.
==== Starter configuration options that cannot be bound are reported
-The starters bind `camel.component.*`, `camel.dataformat.*` and
`camel.language.*` onto the Camel component,
+The starters bind `+camel.component.*+`, `+camel.dataformat.*+` and
`+camel.language.*+` onto the Camel component,
data format or language they configure. Two steps of that binding used to
discard a configured value without
reporting it, so a mistyped or unbindable option left the target at its
default and nothing appeared in the
-log. Both now report the value they cannot use, which matches what
`camel.rest.*` has always done.
+log. Both now report the value they cannot use, which matches what
`+camel.rest.*+` has always done.
An option of a complex (object) type is configured with a reference to a bean,
such as:
@@ -1665,11 +1665,11 @@ An option of a complex (object) type is configured with
a reference to a bean, s
camel.component.http.ssl-context-parameters = #bean:mySslContextParameters
----
-The generated converter used to return `null` for any value that did not start
with `#`, and for a value
+The generated converter used to return `null` for any value that did not start
with `+#+`, and for a value
naming a bean that does not exist. A typo in the bean id therefore produced a
component with the option
unset. Such a value now aborts startup with a message naming the value, the
target type and the
-configuration prefix it was set under. A plain bean id with no `#` prefix —
`mySslContextParameters` — is
-resolved rather than discarded, as are `#autowired` and `#type:com.foo.MyType`.
+configuration prefix it was set under. A plain bean id with no `+#+` prefix —
`mySslContextParameters` — is
+resolved rather than discarded, as are `+#autowired+` and
`+#type:com.foo.MyType+`.
These converters are registered with `@ConfigurationPropertiesBinding` and
therefore take part in every
`@ConfigurationProperties` binding in the application, not only in Camel's
own. A binding whose target class
diff --git a/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
b/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
index 7d7547aa00e6..daed2838a27d 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
@@ -186,7 +186,7 @@ The assistant discovers components, looks up documentation,
builds a YAML route,
=== Validation
-* _"Validate this endpoint: `kafka:myTopic?brkers=localhost:9092`"_ — detects
the typo and suggests `brokers`
+* _"Validate this endpoint: ``kafka:myTopic?brkers=localhost:9092``"_ —
detects the typo and suggests `brokers`
* _"Validate this YAML route"_ — checks against the YAML DSL JSON schema,
reports invalid elements
=== Understanding, security, and testing
diff --git a/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
b/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
index 730c49973b5c..c44e615e4382 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
@@ -174,7 +174,7 @@ right panel with full syntax highlighting.
For Camel source files (YAML, XML, Java routes, and `application.properties`),
press *i* to toggle
inline documentation. The TUI uses the Camel catalog to look up every
component, EIP, language,
and data format used in your route and shows their documentation right next to
the source code.
-For properties files, it resolves `camel.component.*` and `camel.main.*` keys
to their catalog
+For properties files, it resolves `+camel.component.*+` and `+camel.main.*+`
keys to their catalog
descriptions. This makes it easy to understand unfamiliar routes without
leaving the terminal.
Additional features:
@@ -200,8 +200,8 @@ Camel routes:
* *Word navigation* -- *Ctrl+Left/Right* to jump by word
* *Smart Home* -- *Home* key alternates between content indent and column 0
* *Tab completion* -- press *Tab* for context-aware completion:
-** In `application.properties`: Camel configuration options (`camel.main.*`,
`camel.component.*`, etc.)
- and Spring Boot auto-configuration properties (`server.*`, `spring.*`,
`management.*`, etc.)
+** In `application.properties`: Camel configuration options (`+camel.main.*+`,
`+camel.component.*+`, etc.)
+ and Spring Boot auto-configuration properties (`+server.*+`, `+spring.*+`,
`+management.*+`, etc.)
resolved from starter JARs in the local Maven repository — works even for
stopped projects
** In YAML DSL routes: EIP names, component URIs, option keys and values
@@ -931,7 +931,7 @@ returns that section only; pass `sections` to list what the
document contains. S
When the AI panel is open, input that starts with `/` runs a local panel
command instead of sending a question to the configured AI provider.
`/provider` and `/model` are unavailable while a response or command is already
in progress; the panel shows a message asking you to wait.
-Press *Tab* to complete a command name. After `/model ` *Tab* completes the
model name against the
+Press *Tab* to complete a command name. After `++/model ++` *Tab* completes
the model name against the
models the current provider reports (the list is fetched in the background on
the first press, so
press *Tab* again once it has arrived), and after `/tools ` it completes
`auto`, `core` or `full`.
With several matches *Tab* fills in the common prefix and then cycles through
them; *Shift+Tab*
diff --git a/docs/user-manual/modules/ROOT/pages/security-model.adoc
b/docs/user-manual/modules/ROOT/pages/security-model.adoc
index 6245a25b1ced..35cb0904133f 100644
--- a/docs/user-manual/modules/ROOT/pages/security-model.adoc
+++ b/docs/user-manual/modules/ROOT/pages/security-model.adoc
@@ -228,7 +228,7 @@ which protective property it breaks.
| Critical (CVSS 9.0-10.0)
| Untrusted data cannot redirect the route to a different endpoint, bean,
method or command
-| A control header injected from the wire changes where the exchange is
dispatched, which operation runs, or which transport and credentials are used -
whether it is spelled inside the internal namespace (`CamelBeanMethodName`,
`CamelExecCommandExecutable`, `CamelHttpUri`, `CamelJmsDestinationName`, ...)
or outside it (`websocket.connectionKey`, `gridfs.*`, `irc.sendTo`,
`operationName`, `mail.smtp.*`, ...)
+| A control header injected from the wire changes where the exchange is
dispatched, which operation runs, or which transport and credentials are used -
whether it is spelled inside the internal namespace (`CamelBeanMethodName`,
`CamelExecCommandExecutable`, `CamelHttpUri`, `CamelJmsDestinationName`, ...)
or outside it (`websocket.connectionKey`, `+gridfs.*+`, `irc.sendTo`,
`operationName`, `+mail.smtp.*+`, ...)
| Critical (CVSS 9.0-9.8)
| Untrusted data is never deserialised into arbitrary Java types
@@ -319,11 +319,11 @@ against core code, and the triager needs the core-side
statement to judge it.
| Out of scope (no engine guarantee)
|===
-A candidate located in a `core/camel-*` module is judged against these
+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
+`+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.
@@ -422,14 +422,14 @@ the misunderstanding can be closed against the correct
contract.
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
+* *`+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.
It also does not match a control header spelled outside the namespace -
- `websocket.connectionKey`, `gridfs.*`, `irc.sendTo`, `operationName`,
- `mail.smtp.*`. Those are the framework's responsibility to filter and
+ `websocket.connectionKey`, `+gridfs.*+`, `irc.sendTo`, `operationName`,
+ `+mail.smtp.*+`. Those are the framework's responsibility to filter and
have been fixed as advisories where they were reachable, but a route
running against a release that predates the relevant fix needs the
namespace stripped explicitly as well.
@@ -619,7 +619,7 @@ it is called, when it selects any of:
CVE-2026-46453 `camel-elasticsearch-rest-client`);
* *the transport or its credentials* - which host, protocol, TLS posture or
authentication the component uses (CVE-2026-46584 `camel-mail`, where
- attacker-supplied `mail.smtp.*` / `mail.smtps.*` headers were applied as
+ attacker-supplied `+mail.smtp.*+` / `+mail.smtps.*+` headers were applied as
JavaMail session properties, weakening SMTP transport security and, before
4.19.0, redirecting the connection and disclosing the configured
credentials).
@@ -648,7 +648,7 @@ needs an effective strategy:
headers of the message being unmarshalled onto the `Exchange` with no
filter at all. CAMEL-24419 then showed the second half of the lesson - the
data format had been given a plain `DefaultHeaderFilterStrategy`, which
- knows only `Camel*` / `camel*`, so the `mail.smtp.*` namespace that the
+ knows only `+Camel*+` / `+camel*+`, so the `+mail.smtp.*+` namespace that the
*consumer* path deliberately filters was still admitted through the
unmarshal path. An entry point that filters a narrower namespace than its
sibling entry point is a gap, not a difference in configuration.
@@ -677,19 +677,19 @@ outcome. Presence of a defence in the source is not
evidence that it executes;
both the reporter and the triager have to establish that the guard is on the
live path.
-The prefixed headers of the API-based components - `CamelFhir.*`,
-`CamelBox.*`, `CamelOlingo4.*`, `CamelAs2.*` and the other
+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
+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". 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*")`,
+`+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.
@@ -1021,7 +1021,7 @@ they are, the change is announced through the normal
upgrade-guide channel.
side the inbound `Camel*` `HeaderFilterStrategy` is applied by default since
4.21 (CAMEL-23543), and component authors must not opt out of it.
* *The framework's automatic header filtering is scoped to the internal
- `Camel*` namespace.* Since 4.21 (CAMEL-23543) `DefaultHeaderFilterStrategy`
+ `+Camel*+` namespace.* Since 4.21 (CAMEL-23543) `DefaultHeaderFilterStrategy`
filters that namespace case-insensitively *by default, in both directions,
for every consumer and producer that uses it*, with no per-component
configuration; it does not, and cannot, filter
@@ -1094,7 +1094,7 @@ Disposition is `KNOWN-NON-FINDING` (see _Triage
dispositions_).
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*` header controls dispatch, therefore
+* *"A `+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
@@ -1118,8 +1118,8 @@ Disposition is `KNOWN-NON-FINDING` (see _Triage
dispositions_).
it is a control header, it is in scope however it is spelled, and the
disposition is not `KNOWN-NON-FINDING` - see the control-header
definition under the Camel-header class in _In-scope vulnerability
- classes_, and the advisories cited there for `websocket.*`, `gridfs.*`,
- `irc.*`, `operationName` and `mail.smtp.*`. The absence of a `Camel`
+ classes_, and the advisories cited there for `+websocket.*+`, `+gridfs.*+`,
+ `+irc.*+`, `operationName` and `+mail.smtp.*+`. The absence of a `Camel`
prefix decides nothing on its own.
* *"`DefaultHeaderFilterStrategy` can be bypassed by changing the case
(`caMEL`, `CAMEL`)."* The default strategy is case-insensitive out of
@@ -1179,11 +1179,11 @@ Disposition is `KNOWN-NON-FINDING` (see _Triage
dispositions_).
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
+* *"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*")`,
+ untrusted source straight through without `+removeHeaders("Camel*")+`,
the disposition is the route-author position in _Out of scope_.
=== Triage dispositions
@@ -1463,13 +1463,13 @@ YAML::
----
====
* *On older releases, also strip the control-header namespaces of the
- components in the route.* The framework filters the `Camel*` namespace by
+ components in the route.* The framework filters the `+Camel*+` namespace by
default and has fixed the non-prefixed control headers it shipped
- (`websocket.*`, `gridfs.*`, `irc.*`, `operationName`, `mail.smtp.*`) as
+ (`+websocket.*+`, `+gridfs.*+`, `+irc.*+`, `operationName`, `+mail.smtp.*+`)
as
those were found; each fix names its affected and fixed versions in the
corresponding advisory at link:/security/[]. Where a deployment cannot yet
move to a release that carries them, add the relevant prefixes to the
- `removeHeaders` pattern at the trust boundary alongside `Camel*`.
+ `removeHeaders` pattern at the trust boundary alongside `+Camel*+`.
* *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
diff --git a/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
b/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
index 6773f8a975c4..e8d9b667269a 100644
--- a/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
+++ b/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
@@ -837,7 +837,7 @@ a simpler, more predictable schema structure. The classic
schema remains the def
=== Using the schemas with IDEs
The classic schema is registered in the https://www.schemastore.org/[JSON
Schema Store] and is automatically
-used by IDEs like VS Code and IntelliJ for files matching `*.camel.yaml` and
`*.camelk.yaml`.
+used by IDEs like VS Code and IntelliJ for files matching `+*.camel.yaml+` and
`+*.camelk.yaml+`.
To use the canonical schema instead, configure your IDE to point to the
canonical schema URL:
![https://example.com/icon.png","mimeType":"image/png","sizes":["48x48"],"theme":"light"}](https://example.com/icon.png","mimeType":"image/png","sizes":["48x48"],"theme":"light"}){kind=link}