CVE-2026-85247Medium· 5.9▾ SunlitImproper 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 wa…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 32.5 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
org.apache.camel:camel-knative >= 4.0.0 < 4.18.5org.apache.camel:camel-knative >= 4.19.0 < 4.22.1Upgrade 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.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-84181Medium· 5.9Apache Camel: Camel-Shiro Authentication Bypass via Skipped Credential Verification on Subject Reuse
CVE-2026-84178Medium· 6.1Apache Camel: Camel-OAuth Login Cross-Site Request Forgery via Missing State Binding in the Authorization Code Flow
CVE-2026-85243Medium· 5.9Apache Camel: Camel-Crypto-PGP Integrity Verification Downgrade via Attacker-Controlled Message Structure
CVE-2026-85260Medium· 5.5Apache Camel: Camel-MLLP Protected Health Information Disclosure to Logs by Default
CVE-2026-84180Medium· 5.3Apache Camel: Camel-Knative Information Disclosure via Unmuted Consumer Exceptions
CVE-2026-102508Critical· 9.2Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to …