From 942d101fd75cccc79bc4038d10f9617a504b9cbd Mon Sep 17 00:00:00 2001 From: Andrea Cosentino Date: Mon, 31 Aug 2026 09:49:51 +0200 Subject: [PATCH 1/2] docs: upgrade notes for the camel-spring-boot 4.23 default changes Six starter defaults changed in camel-spring-boot for 4.23. Each is a deliberate change to what an application gets when it configures nothing, so a deployment relying on the previous default has to opt back in. Covers the jolokia bind address and origin checking, fail-closed vault property resolution, undertow-spring-security token issuer and audience validation, fileNameExtWhitelist enforcement in platform-http, the security policy check seeing environment variables, and the extended String conversion guard. Co-Authored-By: Claude Opus 5 (1M context) Signed-off-by: Andrea Cosentino --- .../pages/camel-4x-upgrade-guide-4_23.adoc | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) 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 ef2ecaa1589b7..b537244fa9d91 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 @@ -951,3 +951,96 @@ overrides it to `true`, so LRA interoperability is unchanged. A custom `CamelSagaService` that relies on the header to join sagas started by another participant must override the new method. Everything else is unaffected: the header is still set on the exchange, and routes reading it continue to work. + +=== camel-spring-boot + +A set of starter defaults changed in this release. Each is a deliberate change to what an application gets +when it configures nothing, so an existing deployment that relied on the previous default has to opt back in. + +==== camel-jolokia-starter binds to loopback + +The Jolokia agent's bind address now defaults to `127.0.0.1` instead of `0.0.0.0`, matching the default of the +Jolokia JVM agent this starter is an alternative to. The starter ships no authenticator, and TLS is configured +only when the Kubernetes service-account CA file is present, so the previous default put an unauthenticated +management endpoint on every interface as soon as the starter was on the classpath. + +Deployments that reach the agent from outside the host — including Kubernetes deployments scraping it over the +pod network — must set the bind address explicitly: + +[source,properties] +---- +camel.component.jolokia.server-config.host = 0.0.0.0 +---- + +Doing so should be paired with authentication or a network policy in front of the endpoint. + +`CamelRestrictor` also now rejects cross-origin browser requests, where before it inherited +`AllowAllRestrictor`'s behaviour of accepting every origin. Requests that carry no `Origin` or `Referer` +header are unaffected, so `curl`, Hawtio and the Jolokia CLI keep working. A browser-based client that drove +the agent cross-origin needs a custom `camel.component.jolokia.server-config.restrictorClass`. + +Operations on the allowed MBean domains are still permitted: managing Camel through Jolokia is what the +starter is for, and that capability is the reason the agent now binds to loopback. + +==== Vault and secrets starters fail closed on early property resolution + +The early-resolution parsers used by the `aws-secrets-manager`, `azure-key-vault`, `cyberark-vault`, +`google-secret-manager`, `hashicorp-vault`, `ibm-secrets-manager` and `spring-cloud-config` starters used to +swallow a per-property lookup failure at `DEBUG` and leave the placeholder in place. The literal +`{{aws:...}}` text then became the effective value of whatever it configured — a password, a token, a URL — +with nothing visible at the default log level. + +A placeholder that matched a vault prefix but could not be resolved now aborts startup. To restore the +previous tolerance: + +[source,properties] +---- +camel.vault.ignore-resolution-failures = true +---- + +The failure is then logged at `WARN` rather than `DEBUG`, so it is visible at the default log level. + +==== camel-undertow-spring-security-starter validates the token issuer and audience + +The JWT decoder was built with only a claim-set converter, so signature and timestamps were checked but the +`iss` claim was not, and the configured `clientId` was never bound to the token. Every client of a realm +shares the signing key, so a token minted for a different client of the same realm was accepted. + +The decoder now installs an issuer validator for the configured realm and requires the token to carry the +configured `clientId` in its `aud` or `azp` claim. A deployment that presents tokens minted for a different +client must either have that client added to the token's audience, or opt out: + +[source,properties] +---- +camel.security.undertow.keycloak.validate-audience = false +---- + +==== camel-platform-http-starter enforces fileNameExtWhitelist + +`fileNameExtWhitelist` was evaluated against the multipart field name rather than the submitted file name, so +it accepted uploads it was configured to reject. It now checks the submitted file name, treats a name with no +extension as not accepted while a whitelist is configured, and matches whole comma-separated extension tokens +instead of testing for a substring. + +Uploads that previously slipped through — a part whose field name carried no extension, or an extension that +was merely a substring of an allowed one — are now rejected. This is the control behaving as documented; a +deployment that depended on the previous behaviour should widen the whitelist explicitly. + +==== The security policy check sees properties set as environment variables + +`camel.security` evaluated only properties whose name a source reported with the `camel.` prefix, which +excluded every option set as an environment variable, since those are reported as `CAMEL_COMPONENT_FOO_BAR`. +Names are now canonicalized before the check. + +Applications running with `camel.security.policy=fail` that configure Camel through the environment may now +see startup fail on a violation that was previously invisible. That violation was always present; only the +reporting changed. + +==== String conversions to file-backed types are blocked + +`SpringTypeConverter` already refused to convert a `String` into an `InputStream`, because Spring's +`ObjectToObjectConverter` finds the `FileInputStream(String)` constructor and opens the value as a path +rather than treating it as content. `Reader`, `Writer` and `ZipFile` targets are now refused for the same +reason — notably `FileWriter(String)`, where the conversion previously succeeded and created the named file. + +`String` to `java.io.File` is unchanged: there the `String` genuinely is a path. From c9bdf3ecddf968d0aff3d7fc47752e9af18268e0 Mon Sep 17 00:00:00 2001 From: Andrea Cosentino Date: Mon, 31 Aug 2026 11:15:07 +0200 Subject: [PATCH 2/2] docs: correct the audience claim and the refused Reader type in the 4.23 notes Both spotted by Guillaume Nodet on the PR and verified against camel-spring-boot: - JwtAudienceValidator.validate() reads only token.getAudience(), so a matching azp does not satisfy it. The note claimed aud or azp. - SpringTypeConverter.isFileBackedTarget() checks FileReader, not Reader, so a String still converts to Reader and to non-file-backed subclasses such as StringReader. Writer stays broad, which the note already had right. Co-authored-by: Claude Opus 5 (1M context) --- .../ROOT/pages/camel-4x-upgrade-guide-4_23.adoc | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) 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 b537244fa9d91..530d7d6fcbfa2 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 @@ -1007,8 +1007,8 @@ The JWT decoder was built with only a claim-set converter, so signature and time shares the signing key, so a token minted for a different client of the same realm was accepted. The decoder now installs an issuer validator for the configured realm and requires the token to carry the -configured `clientId` in its `aud` or `azp` claim. A deployment that presents tokens minted for a different -client must either have that client added to the token's audience, or opt out: +configured `clientId` in its `aud` claim. A deployment that presents tokens minted for a different client +must either have that client added to the token's audience, or opt out: [source,properties] ---- @@ -1040,7 +1040,9 @@ reporting changed. `SpringTypeConverter` already refused to convert a `String` into an `InputStream`, because Spring's `ObjectToObjectConverter` finds the `FileInputStream(String)` constructor and opens the value as a path -rather than treating it as content. `Reader`, `Writer` and `ZipFile` targets are now refused for the same -reason — notably `FileWriter(String)`, where the conversion previously succeeded and created the named file. +rather than treating it as content. `FileReader`, `Writer` and `ZipFile` targets are now refused for the +same reason — notably `FileWriter(String)`, where the conversion previously succeeded and created the named +file. Converting a `String` to `Reader` itself, or to a non-file-backed subclass such as `StringReader`, is +unaffected. `String` to `java.io.File` is unchanged: there the `String` genuinely is a path.