Red Hat Jboss Enterprise Application Platform Xp
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in Red Hat Jboss Enterprise Application Platform Xp.
By the Year
In 2026 there have been 22 vulnerabilities in Red Hat Jboss Enterprise Application Platform Xp with an average score of 7.5 out of ten. Last year, in 2025 Jboss Enterprise Application Platform Xp had 1 security vulnerability published. That is, 21 more vulnerabilities have already been reported in 2026 as compared to last year. However, the average CVE base score of the vulnerabilities in 2026 is greater by 1.62.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 22 | 7.52 |
| 2025 | 1 | 5.90 |
It may take a day or so for new Jboss Enterprise Application Platform Xp vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Red Hat Jboss Enterprise Application Platform Xp Security Vulnerabilities
Netty HTTP/2 Header Field Injection Vulnerability (CVE-2026-93579)
CVE-2026-93579
6.5 - Medium
- September 18, 2026
A flaw was found in Netty's HTTP/2 stack. This vulnerability allows a remote attacker to inject prohibited characters, such as NUL, Line Feed, and Carriage Return, into HTTP/2 header field values due to insufficient validation. When these values cross an HTTP/2 to HTTP/1.1 translation boundary, they can be exploited for request smuggling, header injection, or response splitting. This could lead to unauthorized access, data manipulation, or other security bypasses.
OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities
Red Hat: HTTP/2/3 EXT CONNECT Downgrade in Apache HTTPd
CVE-2026-93568
7.5 - High
- September 18, 2026
A flaw was found in Netty. A remote attacker could exploit this vulnerability by sending specially crafted HTTP/2 or HTTP/3 Extended CONNECT requests. Netty's HTTP-object conversion path incorrectly processes these requests as regular HTTP/1.1 CONNECT requests, leading to a loss of critical protocol and path information. This misinterpretation can allow attackers to bypass security policies, such as routing or authorization logic, in applications that rely on Netty for HTTP/2 or HTTP/3 communication, resulting in integrity loss.
Improper Input Validation
Netty HTTP/1HTTP/2 Host Header Conflict Allows Unauthorized Access
CVE-2026-93569
8.2 - High
- September 18, 2026
A flaw was found in Netty. A remote unauthenticated attacker can exploit a vulnerability in Netty's HTTP/1 to HTTP/2 conversion process. When an HTTP/1 request includes both an absolute-form request-target and a conflicting Host header, Netty incorrectly prioritizes the Host header for the HTTP/2 :authority field, discarding the original request-target authority. This inconsistency can allow an attacker to bypass security controls in Netty-based proxies or gateways, potentially leading to unauthorized access, cache poisoning, or misrouting of requests.
HTTP Request Smuggling
Netty HTTP/2 CONNECT Host Header Exploit Bypass Tunnel Allow-List
CVE-2026-93567
7.5 - High
- September 18, 2026
A flaw was found in Netty's HTTP/2 codec. When converting HTTP/1 CONNECT requests to HTTP/2, the component incorrectly uses the Host header instead of the CONNECT authority-form request-target for the tunnel authority. A remote attacker can exploit this by supplying a different Host header, leading to a malformed HTTP/2 CONNECT request. This can bypass security controls such as tunnel allow-lists or egress policies, resulting in integrity loss.
Improper Input Validation
Netty HpackEncoder DoS via oversized SETTINGS MAX_HEADER_TABLE_SIZE
CVE-2026-93492
5.3 - Medium
- September 18, 2026
A flaw was found in Netty's HTTP/2 HpackEncoder. A remote attacker can exploit this by sending HTTP/2 SETTINGS frames with a very large MAX_HEADER_TABLE_SIZE. This causes the HpackEncoder to store an excessive number of unique headers, leading to increased CPU usage and memory consumption, ultimately resulting in a Denial of Service (DoS).
OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities
RESTEasy CorsFilter CORS Misconfig Enables Credentialed CrossOrigin Access
CVE-2026-89058
7.4 - High
- September 18, 2026
A flaw was found in RESTEasy's CorsFilter, which, when configured to allow all origins ("*"), reflects the request's Origin header back in the Access-Control-Allow-Origin response together with Access-Control-Allow-Credentials: true. This permissive cross-origin policy allows a malicious website to make credentialed cross-origin requests and read authenticated responses from a victim's session, resulting in a loss of confidentiality.
Origin Validation Error
RESTEasy IIOImageProv Unbounded Image Dimension DoS
CVE-2026-89059
7.5 - High
- September 18, 2026
A flaw was found in RESTEasy's IIOImageProvider, which decodes attacker-supplied image request bodies without enforcing any limit on the declared image dimensions or pixel count. A remote, unauthenticated attacker can send a small crafted image declaring enormous dimensions to trigger a very large memory allocation, exhausting the JVM heap and resulting in a denial of service.
Data Amplification
XXE in RESTEasy SourceProvider Enables Remote File Read
CVE-2026-17615
7.5 - High
- August 31, 2026
A flaw was found in RESTEasy's SourceProvider. This vulnerability allows an unauthenticated attacker to perform an unauthenticated remote file read. By sending a specially crafted XML body with a DOCTYPE declaration referencing external entities to an endpoint that accepts application/xml and returns Source or StreamSource, the server can be tricked into resolving the entity and including sensitive file contents in the HTTP response. This is due to the SourceProvider.writeTo() method creating a SAXParser without disabling external entity resolution, leading to an XML External Entity (XXE) vulnerability.
XXE
Netty OOM via RedisArrayAggregator pre-4.1.135/4.2.15
CVE-2026-50011
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, RedisArrayAggregator pre-allocates ArrayList with initial capacity equal to the RESP array element count declared in an array header. That count is taken from the wire before the corresponding child messages exist. A small malicious header can claim a huge initial capacity. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Resource Exhaustion
Netty 4.1/4.2 X509MT Wrapper Bug: No Hostname Verification
CVE-2026-50010
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Improper Verification of Cryptographic Signature
Netty <4.1.135 / <4.2.15 HAProxy PROXY v2 codec memory leak (PP2_TYPE_SSL)
CVE-2026-48059
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested `PP2_TYPE_SSL` TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the `HAProxyMessage` normally. Yet the underlying cumulation buffer (a pooled, potentially direct `ByteBuf` allocated by the channel) remains permanently pinned. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Memory Leak
Netty netty-codec-http2 HTTP2 Decompressor Resource Leak pre 4.1.135/4.2.15
CVE-2026-48043
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. In netty-codec-http2 prior to versions 4.1.135.Final and 4.2.15.Final, the `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Resource Exhaustion
Netty 4.1/4.2: RedisArrayAggregator DirectMemory Leak (Pre4.1.135/4.2.15)
CVE-2026-48006
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Memory Leak
Netty <=4.2.15 DNS Cache Poisoning via DnsResolveContext
CVE-2026-47691
8.7 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Insufficient Verification of Data Authenticity
Netty DoS via unbounded CompositeByteBuf chain (4.1.135/4.2.15)
CVE-2026-46340
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. In versions of netty-transport-sctp prior to 4.1.135.Final and 4.2.15.Final, for each non-complete SctpMessage fragment the handler does `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))`, wrapping the previous accumulator and the new slice into a *new* CompositeByteBuf every time. After N fragments the accumulator is an N-deep chain of composites, each holding references and component arrays; readableBytes()/getBytes() on the final buffer recurse N levels. There is no limit on N, on total bytes, or on the number of streamIdentifiers an attacker can open (each gets its own map entry). A peer that never sets the `complete` flag can grow this structure indefinitely from tiny 1-byte DATA chunks. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Allocation of Resources Without Limits or Throttling
Netty DnsResolveContext CNAME Bailiwick Validation Flaw (before 4.1.135,4.2.15)
CVE-2026-45674
8.7 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Insufficient Verification of Data Authenticity
Netty <4.1.135 / <4.2.15 TLS ClientHello Buffer Overflow
CVE-2026-45416
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Allocation of Resources Without Limits or Throttling
Netty netty-codec-haproxy 4.1.x/4.2.x Memory Leak via HAProxyMessage TLV
CVE-2026-44893
7.5 - High
- June 12, 2026
Netty is a network application framework for development of protocol servers and clients. In netty-codec-haproxy prior to versions 4.1.135.Final and 4.2.15.Final, when decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Improper Check or Handling of Exceptional Conditions
Netty NetCodecRedis DoS pre4.1.135/4.2.15
CVE-2026-44890
7.5 - High
- June 11, 2026
Netty is a network application framework for development of protocol servers and clients. In netty-codec-redis prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\r\n`. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Resource Exhaustion
Netty netty-codec-redis DoS via Deeply Nested Redis Arrays before 4.1.135/4.2.15
CVE-2026-44250
7.5 - High
- June 11, 2026
Netty is a network application framework for development of protocol servers and clients. In netty-codec-redis prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Resource Exhaustion
Netty IpSubnetFilterRule IPv6 Bypass < 4.1.135/4.2.15
CVE-2026-44249
8.1 - High
- June 11, 2026
Netty is a network application framework for development of protocol servers and clients. In netty-handler prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Authorization
Netty 4.x HttpContentDecompressor OOM DoS via br, zstd, snappy bypass
CVE-2026-42587
7.5 - High
- May 13, 2026
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpContentDecompressor accepts a maxAllocation parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via ZlibDecoder, but is silently ignored when the content encoding is br (Brotli), zstd, or snappy. An attacker can bypass the configured decompression limit by sending a compressed payload with Content-Encoding: br instead of Content-Encoding: gzip, causing unbounded memory allocation and out-of-memory denial of service. The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Resource Exhaustion
Narayana LRA Coor DoS via Concurrent Cancel/Join
CVE-2024-8447
5.9 - Medium
- January 02, 2025
A security issue was discovered in the LRA Coordinator component of Narayana. When Cancel is called in LRA, an execution time of approximately 2 seconds occurs. If Join is called with the same LRA ID within that timeframe, the application may crash or hang indefinitely, leading to a denial of service.
Deadlock
Stay on top of Security Vulnerabilities
Want an email whenever new vulnerabilities are published for Red Hat Jboss Enterprise Application Platform Xp or by Red Hat? Click the Watch button to subscribe.
