CVE-2023-5379: Red Hat JBoss EAP DoS Vulnerability

CVE-2023-5379 Overview

A flaw was found in Undertow, the lightweight web server used by Red Hat JBoss Enterprise Application Platform (EAP). When an AJP (Apache JServ Protocol) request is sent that exceeds the max-header-size attribute configured in the ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd. This causes JBoss EAP to close the TCP connection without returning an AJP response.

The vulnerability occurs 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, which stops forwarding traffic to that instance. A malicious user could exploit this vulnerability by repeatedly sending requests that exceed the max-header-size, causing a sustained Denial of Service (DoS) condition.

Critical Impact

This vulnerability allows unauthenticated remote attackers to cause Denial of Service by sending oversized AJP requests, potentially taking down critical enterprise application servers and disrupting business operations.

Affected Products

• Red Hat JBoss Enterprise Application Platform 7.0.0 and related versions
• Red Hat Single Sign-On 7.0
• Red Hat Undertow

Discovery Timeline

• December 12, 2023 - CVE-2023-5379 published to NVD
• October 25, 2025 - Last updated in NVD database

Technical Details for CVE-2023-5379

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The flaw resides in how Undertow handles AJP requests with oversized headers. When an AJP request arrives with headers exceeding the configured max-header-size limit, the server fails to properly respond before closing the TCP connection.

The improper error handling creates a cascading failure condition. Instead of gracefully rejecting the malformed request and maintaining operational status, the server abruptly terminates the connection. The mod_proxy_cluster module interprets this behavior as a backend failure and marks the JBoss EAP instance as an unhealthy worker node.

The vulnerability can be exploited remotely without authentication, requiring no user interaction. An attacker with network access to the AJP listener port can repeatedly send crafted requests to trigger the error condition. The attack results in availability impact only, with no effect on confidentiality or integrity.

Root Cause

The root cause lies in improper resource handling and error response generation within Undertow's AJP listener implementation. When processing requests that exceed the max-header-size threshold, the server closes the TCP connection without first sending an appropriate AJP error response. This violates the expected protocol behavior that mod_proxy_cluster relies upon to determine backend health status.

The absence of a proper error response before connection termination causes the load balancer module to misinterpret the situation as a critical backend failure rather than a recoverable request rejection.

Attack Vector

The attack is executed over the network, targeting the AJP listener port (typically port 8009). An attacker constructs AJP requests with HTTP headers that exceed the configured max-header-size limit. When these requests reach the vulnerable Undertow instance, the following sequence occurs:

1. The attacker sends an AJP request with oversized headers to the target server
2. Undertow detects the header size violation but fails to send an AJP error response
3. The TCP connection is closed abruptly from the backend side
4. mod_proxy_cluster marks the JBoss EAP instance as an error worker
5. Traffic forwarding to the affected instance stops
6. Repeated attacks can systematically disable all backend workers

The attack requires no special privileges or user interaction, making it accessible to any attacker with network connectivity to the AJP listener.

Detection Methods for CVE-2023-5379

Indicators of Compromise

• Sudden increase in TCP connection resets on AJP listener ports (default 8009)
• mod_proxy_cluster logs showing backend workers being marked as unhealthy or in error state
• Unusual volume of requests with abnormally large HTTP headers in access logs
• Application availability degradation correlating with connection anomalies on AJP ports

Detection Strategies

• Monitor AJP listener ports for connection patterns indicating repeated oversized request attempts
• Configure alerting on mod_cluster health status changes to detect rapid backend worker state transitions
• Implement network traffic analysis to identify requests with header sizes exceeding normal application thresholds
• Review JBoss EAP server logs for connection termination events without corresponding response entries

Monitoring Recommendations

• Deploy network intrusion detection rules to flag AJP traffic with anomalously large header content
• Establish baseline metrics for normal header sizes and alert on significant deviations
• Monitor cluster health dashboards for unexpected backend worker failures
• Enable detailed logging on AJP listeners to capture header size information for forensic analysis

How to Mitigate CVE-2023-5379

Immediate Actions Required

• Apply the latest security patches from Red Hat for JBoss EAP, Single Sign-On, and Undertow components
• Review and restrict network access to AJP listener ports to trusted proxy servers only
• Implement rate limiting on AJP connections to reduce the impact of repeated attack attempts
• Consider using HTTP connectors instead of AJP where feasible as a temporary measure

Patch Information

Red Hat has released security advisories addressing this vulnerability. Administrators should apply the patches referenced in the following advisories:

• Red Hat Security Advisory RHSA-2023:4509
• Red Hat Security Advisory RHSA-2025:9582
• Red Hat Security Advisory RHSA-2025:9583

Additional details can be found in the Red Hat CVE Advisory and Red Hat Bugzilla #2242099.

Workarounds

• Restrict AJP listener access using firewall rules to allow connections only from authorized mod_cluster/mod_proxy nodes
• Increase the max-header-size value in the AJP listener configuration to reduce false triggers while maintaining security
• Implement a web application firewall (WAF) to filter requests with excessively large headers before they reach the AJP listener
• Deploy health check monitoring to quickly detect and restart affected instances during an active attack

# Example: Restrict AJP listener access using iptables
# Allow AJP traffic only from trusted proxy server IPs
iptables -A INPUT -p tcp --dport 8009 -s 10.0.0.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 8009 -s 10.0.0.11 -j ACCEPT
iptables -A INPUT -p tcp --dport 8009 -j DROP

# Example: Adjust max-header-size in standalone.xml (JBoss EAP)
# Locate ajp-listener and modify max-header-size attribute
# <ajp-listener name="ajp" socket-binding="ajp" max-header-size="65536"/>