CVE-2022-1319 Overview
A flaw was found in Undertow, a lightweight web server written in Java that is used as the default web server in Red Hat JBoss Enterprise Application Platform. The vulnerability occurs in the Apache JServ Protocol (AJP) handling where, for an AJP 400 response, EAP 7 improperly sends two response packets with the reuse flag set even though JBoss EAP closes the connection. This results in a failure when the connection is reused after a 400 response by CPING, as it reads in the second SEND_HEADERS response packet instead of an expected CPONG response.
Critical Impact
This vulnerability can lead to denial of service conditions affecting application availability when AJP protocol connections are improperly reused following error responses.
Affected Products
- Red Hat Undertow (versions prior to fix, including 2.2.17, 2.2.17.SP1, 2.2.17.SP2, 2.2.19, 2.2.19.SP1, and 2.3.0.Alpha1)
- Red Hat OpenShift Application Runtimes
- Red Hat Single Sign-On 7.0
- NetApp Active IQ Unified Manager (Linux, VMware vSphere, Windows)
- NetApp Cloud Secure Agent
- NetApp OnCommand Insight
- NetApp OnCommand Workflow Automation
Discovery Timeline
- 2022-08-31 - CVE-2022-1319 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2022-1319
Vulnerability Analysis
This vulnerability stems from improper handling of AJP protocol response packets in Undertow's AjpReadListener.java implementation. The AJP (Apache JServ Protocol) is a binary protocol used for communication between a web server and an application server, commonly used in JBoss EAP deployments behind Apache HTTP Server with mod_jk or mod_proxy_ajp.
The core issue lies in the END_RESPONSE byte array definition where the reuse flag was incorrectly set to 1 instead of 0. When a 400 Bad Request response is generated, Undertow sends both a SEND_HEADERS packet and an END_RESPONSE packet. With the reuse flag set to 1, the protocol indicates that the connection should be kept alive for subsequent requests. However, JBoss EAP actually closes the connection after the 400 response, creating an inconsistent state.
When the front-end proxy attempts to reuse this connection and sends a CPING packet (a keep-alive probe), it expects a CPONG response. Instead, it receives the stale SEND_HEADERS packet from the previous failed request, causing connection handling to fail and resulting in service disruption.
Root Cause
The vulnerability is classified under CWE-252 (Unchecked Return Value). The root cause is a hardcoded misconfiguration in the END_RESPONSE byte array within AjpReadListener.java. The final byte in the array (the reuse flag) was set to 1, indicating connection reuse should occur, when it should have been 0 to properly signal that the connection should not be reused after error responses.
Attack Vector
An attacker can exploit this vulnerability remotely over the network without requiring authentication or user interaction. The attack scenario involves:
- Sending malformed requests that trigger 400 Bad Request responses from the Undertow server
- The dual response packets with incorrect reuse flags corrupt the AJP connection state
- Subsequent legitimate requests on the reused connection fail when CPING/CPONG handshakes malfunction
- Repeated exploitation can cause cascading connection failures leading to denial of service
// Security patch in AjpReadListener.java - Fix for UNDERTOW-2060
// Source: https://github.com/undertow-io/undertow/commit/1443a1a2bbb8e32e56788109d8285db250d55c8b
private static final byte[] CPONG = {'A', 'B', 0, 1, 9};
private static final byte[] SEND_HEADERS_INTERNAL_SERVER_ERROR_MSG = {'A', 'B', 0, 8, 4, (byte)((500 >> 8) & 0xFF) , (byte)(500 & 0xFF), 0, 0, '\0', 0, 0};
private static final byte[] SEND_HEADERS_BAD_REQUEST_MSG = {'A', 'B', 0, 8, 4, (byte)((400 >> 8) & 0xFF) , (byte)(400 & 0xFF), 0, 0, '\0', 0, 0};
- private static final byte[] END_RESPONSE = {'A', 'B', 0, 2, 5, 1};
+ private static final byte[] END_RESPONSE = {'A', 'B', 0, 2, 5, 0};
private final AjpServerConnection connection;
private final String scheme;
The fix changes the final byte of the END_RESPONSE array from 1 to 0, correctly signaling that the connection should not be reused after sending an error response.
Detection Methods for CVE-2022-1319
Indicators of Compromise
- Unusual spikes in AJP protocol connection errors in application server logs
- Repeated CPING timeout failures or unexpected response packet errors from load balancers or proxies
- Elevated rates of 400 Bad Request responses followed by connection failures
- Service disruptions occurring specifically after malformed request handling
Detection Strategies
- Monitor Undertow and JBoss EAP logs for AJP connection reuse failures and CPING/CPONG handshake errors
- Implement network-level monitoring for abnormal AJP protocol traffic patterns on port 8009
- Deploy application performance monitoring to detect increased connection establishment rates indicative of failed reuse attempts
- Review web server proxy logs (Apache mod_jk or mod_proxy_ajp) for connection pool exhaustion or stale connection errors
Monitoring Recommendations
- Configure alerting on JBoss EAP for AJP listener exceptions and connection state anomalies
- Establish baseline metrics for AJP connection reuse rates and alert on significant deviations
- Monitor for patterns of 400 responses immediately followed by connection failures
- Implement health checks that specifically test AJP connection reuse functionality
How to Mitigate CVE-2022-1319
Immediate Actions Required
- Upgrade Undertow to a patched version that includes the fix for UNDERTOW-2060
- Update JBoss EAP to the latest security patch release that incorporates the Undertow fix
- Review and apply patches for any NetApp products using vulnerable Undertow versions
- Consider temporarily switching to HTTP protocol instead of AJP if immediate patching is not possible
Patch Information
Red Hat has released security updates addressing this vulnerability. Patches are available through the following resources:
- Red Hat CVE-2022-1319 Advisory - Official Red Hat security advisory
- Red Hat Bug Report #2073890 - Bug tracking information
- GitHub Undertow Commit Update #1 - Primary fix commit
- GitHub Undertow Commit Update #2 - Merge commit for UNDERTOW-2060
- NetApp Security Advisory ntap-20221014-0006 - NetApp product advisory
Workarounds
- Disable AJP protocol and use HTTP/HTTPS for communication between the web server and application server
- Implement request rate limiting at the proxy layer to reduce the impact of potential DoS attacks
- Configure connection timeouts and maximum retry limits to prevent cascading failures
- Deploy web application firewalls to filter malformed requests before they reach the application server
# Example: Disable AJP listener in JBoss EAP standalone.xml
# Replace AJP configuration with HTTP-only setup
# Remove or comment out the AJP listener
# <ajp-listener name="ajp" socket-binding="ajp"/>
# Ensure HTTP/HTTPS listeners are configured
# <http-listener name="default" socket-binding="http" redirect-socket="https"/>
# <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm"/>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


