On May 2024, a new vulnerability was discovered in NGINX, specifically when running the HTTP/3 QUIC module. Known as CVE-2024-32760, this flaw can cause NGINX worker processes to unexpectedly terminate, opening up denial-of-service (DoS) risks and potentially other unforeseen impacts. In this post, I’ll break down what this vulnerability is, how an attacker could exploit it, and what you can do to stay safe—using clear, simple terms for everyone.

What is CVE-2024-32760?

NGINX is a widely used open-source web server and reverse proxy. The HTTP/3 module allows NGINX to speak QUIC—a newer, faster protocol largely built on top of UDP rather than the old reliable TCP. CVE-2024-32760 impacts NGINX Plus and NGINX OSS (Open Source Software) when configured to use this HTTP/3 QUIC module.

The issue

If NGINX receives an *undisclosed sequence* of HTTP/3 encoder instructions from a client, it can make a worker process crash because of an unexpected error in how it decodes those instructions. This can be triggered using specifically crafted network packets.

Key Points

- Vulnerable: NGINX OSS/Plus with HTTP/3 QUIC module enabled
- Non-vulnerable: NGINX setups not using HTTP/3 or QUIC

Digging Deeper: Why Does This Matter?

NGINX isolates workloads among worker processes. If an attacker is able to repeatedly crash these processes, it can:

Technical Details & Example Exploit

At the core, the problem lies in the QUIC module’s HTTP/3 encoder decoder logic. Crafty clients can send malformed (or just unusual) instructions, exploiting an undisclosed bug before a patch was released.

Here's what an affected nginx.conf might look like

http {
    server {
        listen 443 quic reuseport;
        ssl_protocols TLSv1.3;
        ssl_certificate     /etc/nginx/ssl/domain.crt;
        ssl_certificate_key /etc/nginx/ssl/domain.key;
        quic_chunk_size 120;
        # Enable HTTP/3
        http3 on;
    }
}

Attack Vector

An attacker sends malicious HTTP/3 requests to the server—these requests contain a specific series of HTTP/3 encoder instructions (the "recipe" to make the bug happen is not public, so it's "undisclosed").

Example: Sending Malformed Frames

You can use qcon (a Go QUIC client) or quiche-client to craft custom packets.

Sample Python snippet using the aioquic library (for educational/legit use!)

from aioquic.asyncio.client import connect
import asyncio

async def main():
    async with connect(
        "your.vuln.nginx.server", 443, alpn_protocols=["h3"]
    ) as client:
        # Send custom malformed HTTP/3 encoder frame
        req_event = client.build_request_headers(
            ":method", "GET", ":path", "/", ":scheme", "https", ":authority", "your.vuln.nginx.server"
        )
        # Manipulate headers or encoded instructions here to trigger bug
        # This is *not* the real exploit code (which remains undisclosed)
        await client.send_events([req_event])

asyncio.run(main())

Note: You’ll need to craft the packet carefully to reproduce the crash—details are omitted here for safety and legality.

Are you running NGINX with listen ... quic and http3 on?

- Is your NGINX version affected? Look up your exact release on the official CVE page and NGINX security advisories.

Patch Immediately

Update to the latest version of NGINX OSS or NGINX Plus—patches were released swiftly after disclosure.

2. Disable HTTP/3 QUIC
If you don’t need HTTP/3/QUIC right now, comment out or remove http3 on; and listen ... quic from your config, reload NGINX.

Monitor Logs

Watch your system journal and NGINX error logs for any mysterious worker process segfaults or respawns.

4. WAF/Rate Limiting

References

- CVE-2024-32760 at NIST NVD
- Original NGINX Security Advisory
- NGINX HTTP3/QUIC Documentation
- Understanding QUIC Protocol (Cloudflare)

Conclusion

CVE-2024-32760 shows that new protocols like HTTP/3 and QUIC need careful handling—new code often means new bugs. Right now, updating NGINX and being cautious with bleeding-edge features is the safest bet. If you must serve content over HTTP/3, keep watch for new advisories and test your setup.

For most users, a simple update and a quick config check can keep your NGINX server safe and fast.

Timeline

Published on: 05/29/2024 16:15:10 UTC
Last modified on: 06/10/2024 18:15:34 UTC