oscerd opened a new pull request, #23362:
URL: https://github.com/apache/camel/pull/23362
## Summary
Companion to CAMEL-23222 / the CVE-2025-27636 header-injection family,
addressing a namespace missed in that sweep.
`MailProducer.getSender` extracted `mail.smtp.*` / `mail.smtps.*` 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`/`smtps` 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 PR makes the per-message override opt-in.
## Changes
- **`MailConfiguration`** — new `@UriParam`
`useJavaMailSessionPropertiesFromHeaders` (default `false`,
`label="producer,advanced,security"`, `security="insecure:ssl"`). Picked up
automatically by the `SECURITY-OPTIONS` generator and added to
`core/camel-util/SecurityUtils` so the project-wide security-policy framework
can govern it.
- **`MailProducer.getSender`** — returns the default sender unconditionally
when the flag is `false`. Existing extraction path preserved when the flag is
`true`.
- **`MailHeaderFilterStrategy`** — extends the inbound
`setInFilterStartsWith` set with `mail.smtp.` / `mail.smtps.` (defense in
depth, mirroring CAMEL-23222 for the `Camel*` namespace). Outbound filtering is
unchanged.
- **Docs** — `mail-component.adoc` documents the new opt-in URI and the
security caveat, with a cross-link to the project security model; pre-existing
`java.smtp.` typo in the same section corrected to `mail.smtp.`.
- **Upgrade guide** — new `camel-mail` entry in
`camel-4x-upgrade-guide-4_21.adoc` documenting the default tightening and the
opt-in URI.
- **Tests** — `MailSessionPropertiesFromHeadersTest` covers both flag values
plus the no-header path; `MailHeaderFilterStrategyTest` covers the new inbound
prefix filtering, retention of `Camel*` filtering, ordinary mail headers
passing through, and outbound being unaffected.
## Backwards compatibility
This is a **default-tightening breaking change**, intentionally aligned with
the CAMEL-23222 / CVE-2025-27636-family precedent of shipping default-secure
even in patch releases. Routes that legitimately rely on per-message
`mail.smtp.*` headers must opt back in on the endpoint:
```java
.to("smtp://mymailserver:1234?useJavaMailSessionPropertiesFromHeaders=true");
```
Even with the opt-in enabled, route authors should still strip the namespace
with `removeHeaders("mail.smtp.*", "mail.smtps.*")` between any untrusted
ingress and the mail producer — see the upgrade guide for the full rationale.
## Test plan
- [x] `mvn test` in `components/camel-mail` — 218/218 pass (4 skipped, no
regressions).
- [x] New focused tests: `MailSessionPropertiesFromHeadersTest` (3 tests),
`MailHeaderFilterStrategyTest` (4 tests).
- [x] Full-reactor `mvn clean install -DskipTests` from root — exit 0;
cross-module catalog mirrors, DSL builder factories, endpoint DSL, and
`SecurityUtils` regen all included in the commit.
## Backports
`fixVersions` on the Jira issue are `4.21.0`, `4.18.3`, `4.14.8`. The 4.18.x
and 4.14.x backports will need light adaptation:
- 4.18.x: same code shape as `main` post-PR; straightforward cherry-pick.
- 4.14.x: pre-dates CAMEL-22900 (no `mail.smtps.` fallback) and CAMEL-23308
(no `configureJavaMailSender` on the custom sender). The flag and the
`getSender` gate apply identically; the `MailHeaderFilterStrategy` change
applies identically.
Backport PRs to follow once this lands on `main`.
## Linked issue
https://issues.apache.org/jira/browse/CAMEL-23522
---
_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]
