oscerd opened a new pull request, #23416: URL: https://github.com/apache/camel/pull/23416
## Backport of #23362 Cherry-pick of #23362 onto `camel-4.14.x` (Jira: [CAMEL-23522](https://issues.apache.org/jira/browse/CAMEL-23522), fixVersion `4.14.8`). **Original PR:** #23362 — CAMEL-23522: camel-mail - gate JavaMail session properties from headers behind opt-in **Original author:** @oscerd **Target branch:** `camel-4.14.x` ## Branch-specific adjustments - `MailProducer.getSender` on 4.14.x predates CAMEL-22900 — only the `mail.smtp.` prefix is extracted (no `mail.smtps.` fallback) — and CAMEL-23308 (no `configureJavaMailSender(customSender)` on the per-message sender). The opt-in gate is added on top of the existing 4.14.x extraction shape (single `mail.smtp.` prefix, hardcoded suffix in `addAdditionalJavaMailProperty`); the new code does **not** introduce the `mail.smtps.` fallback on this branch. - The `security = "insecure:ssl"` attribute was removed from `@UriParam` (the attribute is part of the security-policy enforcement framework introduced in CAMEL-23250, which lives only on `main` / 4.21). Categorisation is preserved through `label = "producer,advanced,security"`. - The corresponding `core/camel-util/SecurityUtils` change was dropped for the same reason — the file does not exist on this branch. - The upgrade-guide entry was added to `camel-4x-upgrade-guide-4_14.adoc` under "Upgrading from 4.14.7 to 4.14.8" (the 4_21 file used on `main` does not exist on this branch). - The `xref:manual::security-model.adoc[…]` cross-link in `mail-component.adoc` was dropped (security-model.adoc was introduced on `main` only via CAMEL-23496 and is not present on 4.14.x). - `MailSessionPropertiesFromHeadersTest` was trimmed to assert only the `mail.smtp.` namespace (no `mail.smtps.` cases) since the 4.14.x producer never extracted that prefix; the `MailHeaderFilterStrategyTest` keeps the `mail.smtps.` filter assertion because the filter change does add both prefixes on the inbound path as forward-looking defense in depth. - The new test class imports `org.apache.camel.test.junit5.CamelTestSupport` (instead of the `junit6` package used on `main`). A separate doc-sync PR will mirror the 4.14 upgrade-guide entry onto `main`, per the project's "Backport upgrade-guide policy" in CLAUDE.md. ## Verification on `camel-4.14.x` - [x] `mvn test` in `components/camel-mail` — 7 new tests green (`MailSessionPropertiesFromHeadersTest` + `MailHeaderFilterStrategyTest`); 218 total in the module suite. One pre-existing flake (`MimeMultipartAlternativeWithLongerFilenameTest`) fails when run with the full suite but passes in isolation — unrelated to this change. - [x] Full-reactor `mvn clean install -DskipTests` exits 0 with all generated catalog mirrors, DSL builder factories, endpoint DSL, and component metadata regenerated and committed. ## Original description (from #23362) `MailProducer.getSender` extracted `mail.smtp.*` exchange headers and applied them as JavaMail session properties on a per-message custom sender. The namespace is Camel-internal (only `MailProducer` interprets it) and is not filtered by any `HeaderFilterStrategy`. A route chaining an untrusted producer (e.g. `platform-http` query parameters, JMS/Kafka from untrusted producers) into `smtp` without an explicit `removeHeaders` between them therefore let an attacker drive transport-security settings: `mail.smtp.ssl.trust`, `mail.smtp.ssl.checkserveridentity`, `mail.smtp.starttls.enable`, `mail.smtp.socks.host`, etc. This is the same conceptual pattern as the `Camel*` header-injection family (CAMEL-23222 / CVE-2025-27636), with a namespace that was missed in that sweep. The fix makes the per-message override opt-in (`useJavaMailSessionPropertiesFromHeaders`, default `false`). --- _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
