Severity:
CVSS 3.1: 5.9 (medium) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Affected versions:
- Apache Camel (org.apache.camel:camel-knative) 4.0.0 before 4.18.5
- Apache Camel (org.apache.camel:camel-knative) 4.19.0 before 4.22.1
- Apache Camel (org.apache.camel:camel-knative) 4.18.5 unaffected
- Apache Camel (org.apache.camel:camel-knative) 4.22.1 unaffected
- Apache Camel (org.apache.camel:camel-knative) 4.23.0 unaffected
Description:
Improper Certificate Validation vulnerability in Apache Camel Knative component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before
4.22.1.
When SSL was enabled on the Knative HTTP client but no truststore was
configured, the client options fell back to trusting every presented
certificate rather than to the JVM's default trust anchors. A deployment that
switched TLS on without also configuring a truststore therefore obtained an
encrypted connection with no peer authentication, which an attacker positioned
on the network path can terminate and read. The dangerous state is reached by
omission rather than by an explicit opt-in, which is what makes it a framework
defect: turning TLS on should not be the thing that turns certificate
validation off.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS
releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases
stream should upgrade to 4.22.1. With no truststore configured the trust
options are now left unset so the JVM default trust anchors apply, the same
fallback SSLContextParameters and the rest of Camel use. Trusting every
certificate is now reached only by asking for it explicitly through the
trust.all property, which remains available for development against a cluster
with a self-signed certificate. For deployments that cannot upgrade
immediately, configure a truststore explicitly wherever SSL is enabled. After
upgrading, a deployment that was relying on the implicit trust-all behaviour
must either configure a truststore or set the trust.all property deliberately.
Solution:
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS
releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases
stream should upgrade to 4.22.1. With no truststore configured the trust
options are now left unset so the JVM default trust anchors apply, the same
fallback SSLContextParameters and the rest of Camel use. Trusting every
certificate is now reached only by asking for it explicitly through the
trust.all property, which remains available for development against a cluster
with a self-signed certificate.
Work Arounds:
For deployments that cannot upgrade immediately, configure a truststore
explicitly wherever SSL is enabled. After upgrading, a deployment that was
relying on the implicit trust-all behaviour must either configure a truststore
or set the trust.all property deliberately.
Credit:
Claude Security (finder)
Andrea Cosentino (remediation developer)
References:
https://camel.apache.org/security/CVE-2026-85247.html
https://issues.apache.org/jira/browse/CAMEL-24443
https://github.com/apache/camel/pull/25824
https://github.com/apache/camel/pull/25944
https://github.com/apache/camel/pull/25946
https://camel.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-85247
