RHSA-2026:54622HighCVSS 8.2

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

Published
August 13, 2026
Last Modified
August 13, 2026

🔗 CVE IDs covered (25)

CVE-2026-55223 →CVE-2026-55831 →CVE-2026-55833 →CVE-2026-55851 →CVE-2026-6860 →CVE-2026-15076 →CVE-2026-54428 →CVE-2026-54512 →CVE-2026-54513 →CVE-2026-56745 →CVE-2026-40859 →CVE-2026-43866 →CVE-2026-46584 →CVE-2026-46726 →CVE-2026-56746 →CVE-2026-56819 →CVE-2026-56820 →CVE-2026-59899 →CVE-2026-44891 →CVE-2026-46592 →CVE-2026-54399 →CVE-2026-56817 →CVE-2026-45205 →CVE-2026-50193 →CVE-2026-55153 →

📋 Description

CVE-2026-6860 — eclipse-vertx/vert.x: eclipse-vertx/vert.x: Denial of Service via TLS handshake with wildcard server name CVE-2026-15076 — io.vertx/vertx-web: Eclipse Vert.x Web Client: Information disclosure via improper cookie domain validation CVE-2026-40859 — org.apache.camel/camel-vertx-http: Apache Camel (camel-vertx-http): Remote Code Execution via Deserialization of Untrusted Data CVE-2026-43866 — camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection CVE-2026-44891 — io.netty/netty-codec-stomp: Netty: Denial of Service vulnerability in STOMP decoder CVE-2026-45205 — commons-configuration: Apache Commons Configuration: Denial of Service via uncontrolled recursion with crafted YAML input CVE-2026-46584 — org.apache.camel/camel-mail: Apache Camel Mail Component: Credential exposure and information disclosure via improper input validation of mail headers CVE-2026-46592 — org.apache.camel/camel-cxf: Apache Camel CXF SOAP: Remote attacker can execute unintended operations via header manipulation CVE-2026-46726 — camel-vertx-websocket: Apache Camel Vertx Websocket: Server-Side Request Forgery and sensitive data exposure CVE-2026-50193 — jackson-databind: Jackson-databind: Denial of Service via deeply nested JSON processing CVE-2026-54399 — org.apache.httpcomponents.core5/httpcore5: Apache HttpComponents Core: Denial of Service via excessive HTTP headers CVE-2026-54428 — org.apache.httpcomponents.core5/httpcore5-h2: Apache HttpComponents Core: Denial of Service via oversized HTTP/2 HPACK header blocks CVE-2026-54512 — jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass CVE-2026-54513 — jackson-databind: Jackson-databind: Security bypass allows arbitrary code execution CVE-2026-55153 — com.mchange/mchange-commons-java: mchange-commons-java: Remote code execution via JNDI injection CVE-2026-55223 — c3p0: c3p0: Remote code execution via deserialization vulnerability CVE-2026-55831 — io.netty/netty-codec-http: Netty: Denial of Service via SPDY SETTINGS frame processing CVE-2026-55833 — netty: io.netty/netty-codec-http: Netty: Denial of Service via SPDY header decompression amplification CVE-2026-55851 — io.netty/netty-codec-haproxy: Netty codec-haproxy: Denial of Service via crafted PROXY protocol v2 message CVE-2026-56745 — netty: io.netty/netty-codec-http: Netty: Denial of Service via memory exhaustion in SPDY-to-HTTP codec CVE-2026-56746 — io.netty/netty-codec-http: Netty: Security control bypass allows unauthorized requests via null origin header CVE-2026-56817 — io.netty/netty-codec-xml: Netty: Information disclosure via XML External Entity (XXE) vulnerability CVE-2026-56819 — io.netty/netty-codec-http2: Netty: Denial of Service via HTTP/2 DATA frame memory leak CVE-2026-56820 — io.netty/netty-handler-ssl-ocsp: Netty: Certificate revocation bypass via OCSP response replay attack CVE-2026-59899 — io.netty/netty-codec-http: Netty: Memory exhaustion in netty-codec-http (decompression bomb)

🎯 Affected products1

  • Red Hat build of Apache Camel 4.18.3 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: 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: To mitigate this issue, avoid enabling `transferException=true` or `allowJavaSerializedObject=true` on Apache Camel `camel-vertx-http` producer endpoints that communicate with untrusted or network-reachable backend services. Ensure all producer connections utilize TLS (HTTPS) to prevent man-in-the-middle attacks. If enabling these options is necessary, configure a strict deserialization filter using the `-Djdk.serialFilter` JVM system property, for example: `-Djdk.serialFilter="java.**;org.apache.camel.**;!*"`. This will restrict the classes allowed during deserialization, limiting the potential impact. Workaround: Restrict publish access to JMS queues and topics consumed by Camel applications via broker authorization. Note that a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes within the org.apache.camel namespace. Workaround: To reduce the risk of this denial of service, restrict network access to any services that expose a STOMP endpoint and use Netty's `StompSubframeDecoder`. Implement firewall rules or network access controls to permit connections only from trusted sources. This action limits the ability of untrusted remote clients to exploit the vulnerability. Workaround: To mitigate this issue, restrict Apache Commons Configuration to process only trusted YAML configuration files. Implement strict input validation for any YAML content originating from untrusted sources to prevent the parsing of malformed input with cyclical references. This operational control reduces the exposure to denial of service attacks. Workaround: To mitigate this vulnerability, ensure that any Camel routes processing untrusted input and forwarding it to the mail producer explicitly strip the `mail.smtp.*` and `mail.smtps.*` header namespaces. This can be achieved by adding `removeHeaders('mail.smtp.*')` and `removeHeaders('mail.smtps.*')` to the route definition between the untrusted ingress and the SMTP/SMTPS producer. Workaround: To mitigate this issue, ensure that the `operationName` and `operationNamespace` headers are not sourced from untrusted input when bridging an HTTP consumer to a `cxf:` producer in Apache Camel routes. Configure the route to explicitly strip these headers from any untrusted ingress before they reach the `cxf:` producer. Subsequently, set the intended SOAP operation from a trusted, internal source within the route. This prevents a remote attacker from manipulating backend service operations. Changes to route configurations may require a service restart to take effect. Workaround: Restrict access to exposed WebSocket endpoints with authentication. If unable to upgrade, strip Camel-internal headers from inbound WebSocket messages before they reach downstream producers (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route). 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: To mitigate this issue, configure an upstream proxy or web application firewall (WAF) to enforce limits on the number and length of HTTP headers. This prevents malformed requests from reaching and exhausting the vulnerable Apache HttpComponents Core component. Consult your proxy or WAF documentation for specific configuration. A service restart may be required for changes to take effect. Workaround: Upgrade to version 2.18.8, 2.21.4, or 3.1.4 or later to address this vulnerability. If upgrading is not immediately possible, remove BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() from the application’s ObjectMapper configuration to eliminate the affected deserialization path. Rebuild and restart the application to apply the configuration change. As an additional mitigation, disable polymorphic deserialization of untrusted data where possible by avoiding or removing default typing features such as activateDefaultTyping() or enableDefaultTyping(). When polymorphic deserialization is required, restrict allowed subtypes using a strict whitelist of trusted application packages and avoid broad or permissive type validation rules. Workaround: Upgrading to mchange-commons-java >= 0.6.0 is strongly recommended. Most applications that include mchange-commons-java do so to support the c3p0 JDBC connection pooling library. When upgrading mchange-commons-java, be sure to update c3p0 as well — upgrading to c3p0 >= 0.14.0 will bring in a patched mchange-commons-java transitively. As a general hardening measure, applications should avoid deserializing untrusted Java objects, and restrict JNDI lookups to trusted naming contexts only. Workaround: Any of the following can reduce the risk or render exploitation not-feasible: - Run applications on Java 16 or later, which restricts reflective access and partially blocks the JavaBean property lookup step of the attack chain. - Remove Apache Commons BeanUtils from the classpath if it is not required, eliminating the most common deserialization carrier. - Ensure the application does not deserialize untrusted input from network sources. Red Hat recommends updating c3p0 to version 0.14.0 or later when a fix is available, which adds explicit BeanInfo classes to exclude the dangerous properties from JavaBean introspection.

🔗 References (28)