RHSA-2026:71675HighCVSS 9.1

Red Hat Security Advisory: Red Hat Build of Apache Camel 4.18.4 for Spring Boot release.

Published
September 24, 2026
Last Modified
October 2, 2026

🔗 CVE IDs covered (36)

CVE-2026-62243 →CVE-2026-66908 →CVE-2026-75595 →CVE-2026-87825 →CVE-2026-12860 →CVE-2026-66273 →CVE-2026-66274 →CVE-2026-87795 →CVE-2026-87824 →CVE-2026-73507 →CVE-2026-90852 →CVE-2026-10050 →CVE-2026-10051 →CVE-2026-59902 →CVE-2026-68494 →CVE-2026-68497 →CVE-2026-42527 →CVE-2026-48203 →CVE-2026-57818 →CVE-2026-59230 →CVE-2026-63621 →CVE-2026-63687 →CVE-2026-56624 →CVE-2026-57817 →CVE-2026-68079 →CVE-2026-87877 →CVE-2026-89046 →CVE-2026-58059 →CVE-2026-59296 →CVE-2026-66257 →CVE-2026-46457 →CVE-2026-64607 →CVE-2026-66909 →CVE-2026-90560 →CVE-2026-15075 →CVE-2026-46456 →

📋 Description

CVE-2026-10050 — jetty-security: Eclipse Jetty: Authentication bypass via Digest authentication encoding collision CVE-2026-10051 — jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections CVE-2026-12860 — org.bouncycastle/bc-java: org.bouncycastle/bc-lts-java: Bouncy Castle for Java: Cryptographic signature bypass in RSA PKCS#1 verification CVE-2026-15075 — vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects CVE-2026-42527 — camel-jms: camel-sjms: camel-amqp: camel-mina: camel-netty: camel-netty-http: camel-vertx-http: camel-infinispan: camel-leveldb: camel-cassandraql: camel-consul: camel-sql: Apache Camel: Information disclosure via deserialization of untrusted data CVE-2026-46456 — camel-aws2-sqs: Apache Camel: Camel-AWS2-SQS: Inbound message attributes are mapped into the Exchange without an inbound HeaderFilterStrategy, allowing a message sender to inject Camel control headers CVE-2026-46457 — camel-nats: Apache Camel: Camel-NATS: Inbound NATS message headers are mapped into the Exchange without a configured HeaderFilterStrategy, allowing a client that can publish to the subject to inject Camel control headers CVE-2026-48203 — camel-solr: Apache Camel: Camel-Solr: The SolrParam. and SolrField. Exchange header prefixes used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to inject Solr query parameters (server-side request forgery) and document fields CVE-2026-56624 — org.apache.sshd/sshd-core: Apache MINA SSHD: Unauthorized command execution due to improper certificate validation CVE-2026-57817 — org.apache.cxf/cxf: Apache CXF: Authorization Code Substitution via missing c_hash validation CVE-2026-57818 — org.apache.cxf/cxf: Apache CXF: Authorization Code Replay via Race Condition CVE-2026-58059 — org.bouncycastle/bc-java: Bouncy Castle for Java: Denial of Service via quadratic-time escaping of X.500 distinguished names CVE-2026-59230 — org.apache.camel/camel-mail: Apache Camel: Injected MIME headers can manipulate route behavior CVE-2026-59296 — io.micrometer/micrometer-registry-statsd: io.micrometer/micrometer-core: Micrometer: Line-protocol and log injection via unsanitized input allows metric and log spoofing CVE-2026-59902 — io.netty/netty-transport-sctp: Netty: Denial of Service via SCTP memory exhaustion CVE-2026-62243 — io.netty/netty-handler: Netty: TLS hostname verification bypass via OpenSSL client path misconfiguration CVE-2026-63621 — org.apache.camel/camel-knative: Apache Camel Knative: Header injection vulnerability allows server-side request forgery CVE-2026-63687 — cxf-rt-rs-security-oauth2: Apache CXF: Security bypass due to improper handling of authorization parameters CVE-2026-64607 — org.apache.httpcomponents.client5/httpclient5: Apache HttpComponents Client: Denial of Service due to connection leak CVE-2026-66257 — qpid-proton-j: Apache Qpid Proton-J: Denial of Service via unbounded symbol value caching CVE-2026-66273 — org.apache.qpid/proton-j: Apache Qpid Proton-J: Denial of Service due to excessive allocation CVE-2026-66274 — org.apache.qpid/proton-j: Apache Qpid Proton-J: Denial of Service via unbounded type nesting CVE-2026-66908 — org.apache.camel/camel-platform-http-main: org.apache.camel/camel-main: Apache Camel: Improper authentication allows JWT bypass in Platform HTTP Main component CVE-2026-66909 — org.apache.cxf/cxf: Apache CXF: Remote Code Execution via unsafe deserialization of JMS ObjectMessage CVE-2026-68079 — org.apache.cxf/cxf: Apache CXF: Authorization code replay due to flaw in DefaultEncryptingCodeDataProvider CVE-2026-68494 — com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via incomplete fix in async JSON parser CVE-2026-68497 — com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: CPU Denial of Service via unbounded numeric parsing CVE-2026-73507 — io.netty/netty-codec-xml: Netty: Denial of Service via CPU Exhaustion in XmlFrameDecoder CVE-2026-75595 — io.netty/netty-handler: Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext CVE-2026-87795 — com.github.luben/zstd-jni: zstd-jni: Out-of-bounds read in ZstdDictCompress constructor leads to denial of service CVE-2026-87824 — com.github.luben/zstd-jni: zstd-jni: Denial of Service (DoS) via out-of-bounds read in Zstd.trainFromBufferDirect CVE-2026-87825 — com.github.luben/zstd-jni: zstd-jni: Data corruption or denial of service via use-after-free vulnerability CVE-2026-87877 — com.github.luben/zstd-jni: zstd-jni: Use-After-Free vulnerability allows memory corruption and denial of service CVE-2026-89046 — zstd-jni: zstd-jni: Information disclosure or denial of service via out-of-bounds read CVE-2026-90560 — com.github.luben/zstd-jni: zstd-jni: Denial of Service via out-of-bounds read in ZstdDictDecompress CVE-2026-90852 — com.github.luben/zstd-jni: luben zstd-jni: Remote use-after-free vulnerability in dictionary sharing

🎯 Affected products1

  • Red Hat build of Apache Camel 4.18.4 for Spring Boot 3.5.16

✅ Remediation

Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Workaround: To mitigate this vulnerability, ensure that all user passwords configured for HTTP Digest authentication in affected Eclipse Jetty deployments exclusively use characters within the Latin-1 character set. This prevents the character encoding collision that leads to authentication bypass. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: Enforce strict DigestInfo encoding checks requiring explicit ASN.1 NULL parameters in RSA PKCS#1 v1.5 signature verification, or mandate the use of RSA-PSS signature schemes in application TLS/crypto configuration. Workaround: To mitigate this issue, configure applications utilizing Vert.x HttpClient to strictly validate and restrict the URLs to which HTTP requests can be redirected. Implement allowlists for trusted domains and ensure that any user-supplied or external URLs processed by Vert.x HttpClient are thoroughly sanitized and validated to prevent redirection to attacker-controlled destinations. This may involve updating application-specific configurations or implementing custom URL validation logic. A service restart or reload may be required for changes to take effect. Workaround: To mitigate this issue, configure a JVM-wide deserialization filter to explicitly deny `java.net` classes. This can be achieved by setting the system property `-Djdk.serialFilter='!java.net.**;java.**;javax.**;org.apache.camel.**;!*'` when starting the Java Virtual Machine. For aggregation-repository components, use `'!java.net.**;java.**;org.apache.camel.**;!*'`. This may impact functionality if legitimate deserialization of `java.net` classes is required. A restart of the affected Apache Camel application is required for the changes to take effect. Workaround: To mitigate this issue, configure your Camel routes to strip Camel control headers from inbound messages before they reach any downstream producer. Additionally, restrict who can send messages to the consumed SQS queue by applying least-privilege `sqs:SendMessage` permissions on the queue resource policy. For example, add `removeHeaders('Camel*')` and `removeHeaders('camel*')` at the start of the route. Ensure that any changes to route configurations are properly deployed and services are reloaded or restarted if necessary for the changes to take effect. Workaround: To reduce exposure, configure Apache Camel routes to filter out Camel control headers from incoming NATS messages before they are processed by any downstream producer. Additionally, enable authentication on the NATS server to restrict publishing access to trusted clients only. Workaround: To prevent exploitation, configure Apache Camel routes to strip SolrParam.* and SolrField.* headers from untrusted ingress before they reach the solr: producer. Any required Solr parameters and fields should then be set from a trusted source within the route. This operational control limits the injection of malicious Solr query parameters and document fields. Workaround: Limit the maximum string length of incoming X.500 distinguished names at application or API gateway boundaries, or restrict the acceptance of unauthenticated client certificates containing complex distinguished names. Workaround: Users should upgrade to Apache Camel 4.14.9, 4.18.4, or 4.22.0, as applicable to their release stream. Where an upgrade is not immediately possible, keep headersInline=false unless inline MIME headers are required. If headersInline=true must remain enabled, remove Camel-internal headers immediately after the unmarshalling step, before any processor or producer reads Camel control headers. For example, routes may use removeHeaders("Camel*") as a defense-in-depth measure. Do not unmarshal MIME content from an untrusted sender into a route that dispatches or performs sensitive operations based on message header values. Treat MIME header names received from outside the trust boundary as untrusted input. Workaround: This vulnerability only affects applications that explicitly configure Netty to use the OpenSSL TLS provider (SslProvider.OPENSSL). The following mitigations can reduce exposure without applying a patch: 1) Use the default JDK SSL provider — Do not configure SslProvider.OPENSSL in your Netty SslContext setup. The default JDK SSL provider (SslProvider.JDK) is not affected by this vulnerability. Most applications use the JDK default unless explicitly overridden. 2) Use X509ExtendedTrustManager — If the OpenSSL provider is required, ensure the configured trust manager extends X509ExtendedTrustManager rather than the plain X509TrustManager interface. The extended variant performs hostname verification independently of the Netty wrapping logic. 3) Run on Java 24 or earlier — The vulnerable code path only triggers on Java 25+ where sun.misc.Unsafe-based trust-manager wrapping is unavailable. Running on earlier Java versions (e.g., Java 21 LTS) means the wrapping works correctly and hostname verification stays enabled. Workaround: To mitigate this issue, restrict network access to services utilizing Apache Qpid Proton-J to trusted clients and networks only. Implement firewall rules to limit inbound connections to the specific ports used by these services. This operational control reduces the attack surface by preventing untrusted external access, but may impact legitimate client connectivity if not carefully configured. Workaround: To mitigate this vulnerability, disable ObjectMessage deserialization in Apache CXF's JMS transport. This can typically be achieved through a configuration setting provided by the Apache CXF framework. Consult the Apache CXF documentation for specific instructions on how to disable ObjectMessage deserialization in your deployment. Disabling this feature may impact applications that rely on ObjectMessage for legitimate data transfer. Workaround: Upgrade com.fasterxml.jackson.core:jackson-core to a fixed version, such as 2.18.8 or later, 2.21.4 or later, or the first fixed release in the applicable 2.22.x stream. For Jackson 3.x, upgrade to 3.1.4 or later, or the first fixed release in the applicable 3.2.x stream. If upgrading is not immediately possible, do not expose the non-blocking parser to untrusted, incrementally streamed JSON. Where feasible, use a synchronous parser or buffer and enforce strict request-size, connection-timeout, and concurrency limits at the ingress layer. Apply the upgrade as soon as possible because ingress limits reduce exposure but do not correct the parser defect. Workaround: Upgrade jackson-databind to 2.18.10, 2.21.6, 2.22.2, or later fixed releases as applicable. Until updated, restrict untrusted JSON input size and complexity. Workaround: Red Hat products do not use the vulnerable XmlFrameDecoder component. No mitigation is required for standard product deployments. Custom applications built on Red Hat middleware that explicitly instantiate XmlFrameDecoder should avoid processing untrusted XML input or upgrade to netty-codec-xml 4.1.136.Final or later. Workaround: To mitigate this issue, ensure that application-layer certificate verification is implemented for services utilizing Netty with mutual TLS. This provides an additional layer of authentication beyond the TLS handshake, preventing unauthorized access even if the SNI routing is bypassed and a less restrictive default SslContext is used. Workaround: Update com.github.luben/zstd-jni to version 1.5.7-14 or later. Until updated, do not pass attacker-controlled offset or length values to ZstdDictCompress. Workaround: No complete workaround is currently available. As a tempor…

🔗 References (31)