Live › vulnerability › CVE-2026-85247
Go to dashboardWhen SSL is enabled on the Apache Camel Knative HTTP client without a configured truststore, the client trusts every presented certificate instead of the JVM default trust anchors. An attacker on the network path can terminate the connection and read the traffic.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that use the Apache Camel Knative component with SSL enabled on the Knative HTTP client and no truststore configured are exposed. Systems that do not use the Knative component, run without SSL, or explicitly configure a truststore are not affected by this default.
No product ranges from the sources yet.
mvn dependency:tree | grep camel-knative; affected versions are 4.0.0 to before 4.18.5 and 4.19.0 to before 4.22.1. - Search the configuration for Knative SSL settings enabled with no truststore configured.4.23.0. - On the 4.18.x LTS line, upgrade to 4.18.5. - On the 4.22.x LTS line, upgrade to 4.22.1. - Until upgraded, configure a truststore explicitly wherever SSL is enabled. - After upgrading, configure a truststore or set the trust.all property deliberately if the deployment relied on implicit trust-all.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-85247")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.