A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).

A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).

Affected: openEuler:22.03-LTS-SP4: undertow, openEuler:22.03-LTS-SP3: undertow, openEuler:20.03-LTS-SP4: undertow, openEuler:22.03-LTS-SP1: undertow, openEuler:24.03-LTS: undertow

Java web server using non-blocking IO Security Fix(es): A flaw was found in Undertow. A buffer leak on the incoming WebSocket PONG message may lead to memory exhaustion. This flaw allows an attacker to cause a denial of service. The highest threat from this vulnerability is availability.(CVE-2021-3690) A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).(CVE-2023-5379)

wildfly: unsafe deserialization in Wildfly Enterprise Java Beans libthrift: potential DoS when processing untrusted payloads hibernate-core: SQL injection vulnerability when both hibernate.use_sql_comments and JPQL String literals are used wildfly-openssl: memory leak per HTTP session creation in WildFly OpenSSL undertow: special character in query results in server errors jackson-databind: denial of service via a large depth of nested objects jakarta-el: ELParserTokenManager enables invalid EL expressions to be evaluate netty-codec: Bzip2Decoder doesn't allow setting size restrictions for decompressed data netty-codec: SnappyFrameDecoder doesn't restrict chunk length and may buffer skippable chunks in an unnecessary way undertow: potential security issue in flow control over HTTP/2 may lead to DOS(incomplete fix for CVE-2021-3629) wildfly-elytron: possible timing attacks via use of unsafe comparator undertow: Server identity in https connection is not checked by the undertow client undertow: AJP Request closes connection exceeding maxRequestSize EAP: wildfly-elytron has a SSRF security issue

Affected: Ubuntu:Pro:16.04:LTS: undertow, Ubuntu:Pro:18.04:LTS: undertow, Ubuntu:Pro:20.04:LTS: undertow, Ubuntu:Pro:22.04:LTS: undertow, Ubuntu:Pro:24.04:LTS: undertow, Ubuntu:25.10: undertow, Ubuntu:26.04:LTS: undertow

A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).

Ein entfernter, anonymer Angreifer kann eine Schwachstelle in NetApp ActiveIQ Unified Manager ausnutzen, um einen Denial of Service Angriff durchzuführen.