RHSA-2026:48118HighCVSS 8.2

Red Hat Security Advisory: Red Hat Build of Apache Camel 4.18.3 for Quarkus 3.33 update is now available (RHBQ 3.33.2.SP3)

Published
July 30, 2026
Last Modified
July 30, 2026

🔗 CVE IDs covered (14)

CVE-2026-46592 →CVE-2026-46726 →CVE-2026-54399 →CVE-2026-54428 →CVE-2026-55831 →CVE-2026-55851 →CVE-2026-56745 →CVE-2026-56746 →CVE-2026-56819 →CVE-2026-59899 →CVE-2026-15075 →CVE-2026-15076 →CVE-2026-40859 →CVE-2026-46584 →

📋 Description

CVE-2026-15075 — vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects 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-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-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-55831 — io.netty/netty-codec-http: Netty: Denial of Service via SPDY SETTINGS frame processing 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-56819 — io.netty/netty-codec-http2: Netty: Denial of Service via HTTP/2 DATA frame memory leak 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 for Quarkus 3.33

✅ Remediation

Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on. The References section of this erratum contains a download link (you must log in to download the update). 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: 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: 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: 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.

🔗 References (31)