RHSA-2026:63302HighCVSS 8.8

Red Hat Security Advisory: Red Hat Build of Apache Camel 4.18 for Quarkus 3.33 update is now available (RHBQ 3.33.3.SP1)

Published
September 3, 2026
Last Modified
September 10, 2026

🔗 CVE IDs covered (9)

CVE-2026-71290 →CVE-2026-17615 →CVE-2026-64607 →CVE-2026-66274 →CVE-2026-12894 →CVE-2026-18710 →CVE-2026-62243 →CVE-2026-66257 →CVE-2026-66273 →

📋 Description

CVE-2026-12894 — io.quarkus:quarkus-qute: quarkus-qute:Server-Side Template Injection (SSTI) vulnerability in ReflectionValueResolver of the Quarkus Qute template engine CVE-2026-17615 — resteasy-core: RESTeasy SourceProvider remote unauthenticated file read CVE-2026-18710 — org.mongodb/mongodb-driver: MongoDB Driver: Credential disclosure via cleartext logging during client initialization CVE-2026-62243 — io.netty/netty-handler: Netty: TLS hostname verification bypass via OpenSSL client path misconfiguration 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-71290 — org.apache.httpcomponents.client5/httpclient5: Apache HttpComponents Client: Server impersonation via improper TLS hostname verification

🎯 Affected products1

  • Red Hat Build of Apache Camel 3.33 for Quarkus 3.33.3.SP1

✅ 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: Applications utilizing the Quarkus Qute template engine should ensure that untrusted input is not directly incorporated into template content. Restricting access to the application's template rendering functionality to trusted sources can reduce the attack surface. Workaround: To mitigate this issue, avoid exposing RESTEasy endpoints that return Source or StreamSource types. Alternatively, implement a custom MessageBodyWriter for Source types that explicitly applies XML security features to the SAXParserFactory before parsing. Changes to application configuration or code typically require an application redeployment or restart to take effect. Workaround: To mitigate this issue, ensure that access to application logs and any downstream log aggregation storage is strictly controlled. Implement robust access control mechanisms to prevent unauthorized parties from reading log output, as this is where sensitive credentials may be exposed in cleartext during MongoDB driver client initialization. Regularly review and audit log access permissions. 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: 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, 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.

🔗 References (20)