RHSA-2026:70229HighCVSS 8.8

Red Hat Security Advisory: Red Hat JBoss Enterprise Application Platform 8.1.8 security update

Published
September 22, 2026
Last Modified
November 1, 2026

🔗 CVE IDs covered (35)

CVE-2026-50632 →CVE-2026-56745 →CVE-2026-56746 →CVE-2026-62243 →CVE-2026-85511 →CVE-2026-15561 →CVE-2026-44417 →CVE-2026-54512 →CVE-2026-57967 →CVE-2026-10832 →CVE-2026-15563 →CVE-2026-49362 →CVE-2026-55831 →CVE-2026-59889 →CVE-2026-15562 →CVE-2026-46581 →CVE-2026-59899 →CVE-2026-73508 →CVE-2026-3505 →CVE-2026-14180 →CVE-2026-49363 →CVE-2026-49875 →CVE-2026-15567 →CVE-2026-59649 →CVE-2026-5680 →CVE-2026-15565 →CVE-2026-49364 →CVE-2026-54513 →CVE-2026-54515 →CVE-2026-55833 →CVE-2026-86404 →CVE-2026-15555 →CVE-2026-15560 →CVE-2026-68494 →CVE-2026-15554 →

📋 Description

CVE-2026-3505 — bouncycastle: BC-JAVA: unbounded PGP AEAD chunk size leads to pre-auth resource exhaustion CVE-2026-5680 — undertow-core: Undertow: Denial of Service via WebSocket permessage-deflate processing CVE-2026-10832 — org.wildfly.security/wildfly-elytron-asn1: Unbounded Memory Allocation in WildFly Elytron ASN.1 DERDecoder via Crafted DER Payload CVE-2026-14180 — undertow-core: Undertow:HTTP request smuggling via oversized chunk-size bit overlap CVE-2026-15554 — undertow-core: Undertow: Authentication Bypass via AJP ssl_cert/is_ssl Forgery CVE-2026-15555 — jboss-marshalling-river: wildfly-clustering-infinispan-marshalling: Jboss Deserialization RCE via Unfiltered River Unmarshaller CVE-2026-15560 — openjdk-orb: unauthed class loading via IIOP in EAP CVE-2026-15561 — undertow-core: OOM via missing limits in chunked trailer in EAP's Undertow CVE-2026-15562 — jboss-remoting: jboss-remoting: integer overflow in MessageReader leads to pre-authentication denial of service CVE-2026-15563 — wildfly-iiop-openjdk: Missing authentication on EAP's IIOP NameService leads to MITM or DoS CVE-2026-15565 — undertow: undertow-websockets: Undertow: Pre-Auth DoS on websocket endpoint with @ServerEndpoint class with any @OnMessage method CVE-2026-15567 — wildfly: wildfly-iiop: wildfly-jacorb: Wildfly: Pre-auth denial of service on the IIOP listener CVE-2026-44417 — org.apache.cxf/cxf-rt-transports-jms: Apache CXF: Remote Code Execution via untrusted JMS configuration CVE-2026-46581 — wildfly-clustering-faces-mojarra: com.sun.faces:jsf-impl: org.glassfish:jakarta.faces: mojarra: Unauthenticated RCE in EAP JSF applications via EL injection in ui:include CVE-2026-49362 — artemis-server: undertow-core: wildfly-messaging-activemq-subsystem: artemis core protocol permits unauthed queue creation CVE-2026-49363 — artemis-server: artemis-server: Pre-auth topology disclosure via CORE SUBSCRIBE_TOPOLOGY_V2 on channel0 CVE-2026-49364 — wildfly-messaging-activemq-subsystem: artemis-server: jgroups: artemis cluster password leak via jgroups spoof CVE-2026-49875 — cxf: org.apache.cxf/cxf-core: Apache CXF: Information disclosure via out-of-band external entity resolution due to missing JAXP hardening CVE-2026-50632 — cxf: org.apache.cxf/cxf-rt-transports-jms: Apache CXF: Arbitrary code execution via untrusted JMS configuration 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-54515 — jackson-databind: jackson-databind: Ignored properties can be unexpectedly modified 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-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-57967 — artemis-server: Apache Artemis — session hijack via missing authentication CVE-2026-59649 — org.bouncycastle/bcpg-fips: org.bouncycastle/bcpg-jdk15on: org.bouncycastle/bcpg-jdk18on: Bouncy Castle for Java: Denial of Service due to unbounded OpenPGP user-attribute subpacket length CVE-2026-59889 — com.fasterxml.jackson.core/jackson-databind: Jackson-databind: Privilege escalation via improper handling of @JsonUnwrapped properties CVE-2026-59899 — io.netty/netty-codec-http: Netty: Memory exhaustion in netty-codec-http (decompression bomb) CVE-2026-62243 — io.netty/netty-handler: Netty: TLS hostname verification bypass via OpenSSL client path misconfiguration 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-73508 — io.netty/netty-codec-dns: Netty: Denial of Service via Memory Leak in DNS Record Decoder with Malformed Domain Names CVE-2026-85511 — wildfly-elytron-realm-token: parameter injection in EAP's elytron oauth2 CVE-2026-86404 — artemis-server: artemis-jms-client: artemis-core-client: undertow-core: wildfly-messaging-activemq-subsystem: artemis messaging handlers in Red Hat EAP permit deserialization by default

🎯 Affected products149

  • Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-0:2.40.0-8.redhat_00024.1.el9eap.src as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-cli-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-commons-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-core-client-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-dto-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-hornetq-protocol-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-hqclient-protocol-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-jakarta-client-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-jakarta-ra-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-jakarta-server-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-jakarta-service-extensions-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-jdbc-store-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-journal-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-selector-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-activemq-artemis-server-0:2.40.0-8.redhat_00024.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-apache-cxf-0:4.1.7-1.SP1_redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-apache-cxf-0:4.1.7-1.SP1_redhat_00001.1.el9eap.src as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-apache-cxf-rt-0:4.1.7-1.SP1_redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-apache-cxf-services-0:4.1.7-1.SP1_redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-apache-cxf-tools-0:4.1.7-1.SP1_redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-artemis-wildfly-integration-0:2.0.5-1.Final_redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-artemis-wildfly-integration-0:2.0.5-1.Final_redhat_00001.1.el9eap.src as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-bouncycastle-0:1.85.0-1.redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-bouncycastle-0:1.85.0-1.redhat_00001.1.el9eap.src as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-bouncycastle-jmail-0:1.85.0-1.redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-bouncycastle-pg-0:1.85.0-1.redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-bouncycastle-pkix-0:1.85.0-1.redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • eap8-bouncycastle-prov-0:1.85.0-1.redhat_00001.1.el9eap.noarch as a component of Red Hat JBoss EAP 8.1 for RHEL 9
  • +119 more not shown

✅ Remediation

Before applying the update, make sure all previously released errata relevant to your system have been applied. Also, back up your existing installation, including all applications, configuration files, databases and database settings. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Workaround: To mitigate this vulnerability, enforce payload size limits on all incoming PGP messages before processing them. Additionally, apply memory quotas to the JVM or container environment to prevent a complete system outage in the event of memory exhaustion. Workaround: To mitigate this issue, configure the PerMessageDeflateHandshake to limit the maximum decompressed buffer size. This can be achieved by setting the maxDecompressedBufferSize parameter to a reasonable value (e.g., 10 MB) in the PerMessageDeflateHandshake constructor. This action may require a restart of the affected application or service 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: Restrict direct TCP access to the Undertow AJP listener (default port 8009) so that only trusted reverse proxies can connect, for example by binding the AJP listener to localhost or applying firewall rules that limit access to the port to trusted hosts, since exploitation requires direct network access to the AJP port. Additionally, configure the AJP listener to require a shared secret so that AJP requests without proper authentication are rejected, as the flaw arises because forged ssl_cert and is_ssl attributes are honoured without any shared-secret authentication. Workaround: To reduce the risk, enable the AUTH protocol in the JGroups protocol stack configuration of all clustered EAP instances so that only authenticated nodes can join the cluster, and restrict network access to the JGroups cluster traffic (bind port range and multicast/TCP discovery addresses) so that only trusted hosts can reach it. These measures prevent untrusted network-adjacent hosts from joining the cluster and injecting crafted serialized session data. The complete remediation is to install the updated packages as they become available through the product's update channels. 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. Users of affected JBoss EAP streams should apply the openjdk-orb updates provided for their supported EAP version through the usual update channels. Workaround: Deploy a re-framing layer-7 reverse proxy such as nginx, HAProxy in http mode, or an AWS Application Load Balancer in front of the affected JBoss EAP listener. Because such a proxy terminates and re-frames the HTTP/1.1 chunked request, an oversized chunked trailer cannot be passed through to Undertow, which fully mitigates this issue. Direct-edge and layer-4/TCP load-balanced deployments lack this protection; for those deployments, no other workaround meeting Red Hat Product Security criteria is available, and the fixes being delivered for the affected EAP streams should be applied when released. Workaround: Option 1 — Server-wide configuration to disable websockets handshake: <!-- Remove <websockets/> from standalone.xml servlet-container --> <servlet-container name="default"> <jsp-config/> <!-- <websockets/> ← remove this line entirely --> </servlet-container> isWebsocketsEnabled() returns false → no WebSocket upgrade accepted for any deployment. Option 2 — Per-application configuration to disable websockets handshake: <!-- WEB-INF/jboss-web.xml inside the WAR --> <jboss-web> <enable-websockets>false</enable-websockets> </jboss-web> Only that specific WAR's @ServerEndpoint classes are not registered. Workaround: To mitigate this issue, ensure that only trusted users have permissions to configure Java Message Service (JMS) for Apache CXF. Restrict access to configuration files and management interfaces that control JMS settings. If JMS functionality is not required, consider disabling it to remove the attack vector. Workaround: 1. Remove Core protocol from internet-facing acceptors -- configure the protocols parameter to exclude Core protocol on any acceptor receiving untrusted connections. In EAP, the :8080 HTTP-upgrade acceptor supports Core by default; restricting to AMQP/STOMP/OpenWire prevents the attack entirely. 2. Enable mutual TLS -- configure sslEnabled=true with needClientAuth=true on all Core protocol acceptors. TLS handshake failure occurs before any protocol-level packet can be sent. 3. Disable HTTP-upgrade for Core protocol if not required -- remove the http-upgrade element from the Artemis acceptor configuration to eliminate the :8080 attack surface. Workaround: To mitigate this issue, ensure that only trusted administrators have the necessary permissions to configure Java Message Service (JMS) for Apache CXF. Restricting access to JMS configuration prevents untrusted users from exploiting this vulnerability. Review and enforce strict access controls on systems where Apache CXF is deployed with JMS transport. 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: 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: If CORS short-circuit functionality is not required, disable the shortCircuit() configuration in the CorsHandler. Alternatively, implement application-level origin validation to reject requests with null Origin headers. A web application firewall (WAF) can also be configured to block requests with null or missing Origin headers. Workaround: Red Hat is not aware of a mitigation for this flaw other than updating the affected Bouncy Castle component to a fixed version (bc-java 1.85, LTS 2.73.12, or BC-FJA bcpg-fips 1.0.13/2.0.13/2.1.13) once available for the affected product. 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., Ja…

🔗 References (73)