RUSTSEC-2026-0447: Unbounded decompression can exhaust memory and CPU resources

Q: Which applications are exposed to this denial-of-service issue?

Applications are affected if they decode untrusted gzip, deflate, Brotli, or Zstandard request or response bodies with the corresponding compression feature enabled. Actix Web applications are affected when they read compressed request bodies through body extractors.

Q: What does an attacker need to exploit this issue?

An attacker needs control of a compressed request or response body that the application decodes. A small compressed payload can expand into a large output buffer, consuming memory and CPU before configured body-size limits are enforced.

Q: Are extractor body-size limits sufficient protection?

No. In affected Actix Web versions, extractors do not pass their size limits to the decompression layer, so allocation can occur before the decoded body is rejected.

Q: What can be done if upgrades cannot be applied immediately?

Reject compressed request bodies at a reverse proxy or in middleware before body extraction. For direct use of encoding::Decoder, configure Decoder::limit() to constrain decompression output.

Q: What versions address the issue?

Upgrade actix-http to 3.20.1 or later. Actix Web users should also upgrade actix-web to 4.18.2 or later so extractor limits are passed to decompression.

Published Nov 6, 2026

Updated

Body extractors do not pass their size limits to the decompression layer. A small compressed request can therefore cause a large allocation before the extractor rejects the decoded body. A remote attacker can use this to exhaust memory or CPU resources and cause denial of service.

This affects applications that read compressed request bodies with the corresponding compression feature enabled.

Upgrade to actix-web 4.18.2 or later with actix-http 3.20.1 or later. As a workaround, reject compressed request bodies at a reverse proxy or in middleware before body extraction.

Other sources

The encoding::Decoder stream can expand compressed input into a large output buffer before a caller can enforce its body size limit. An attacker who controls a compressed request or response can cause excessive memory allocation and CPU use, resulting in denial of service.

This affects applications that decode untrusted gzip, deflate, Brotli, or Zstandard bodies with the corresponding compression feature enabled.

Upgrade to actix-http 3.20.1 or later and configure Decoder::limit() when using the decoder directly. Actix Web users must also upgrade to actix-web 4.18.2 or later so that extractors pass their limits to the decoder.

— OSV

Affected Software

2 affected componentsFixes available

rust/actix-http>=0.0.0-0<3.20.1

3.20.1

rust/actix-web>=0.0.0-0<4.18.2

4.18.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade rust/actix-http to a version that resolves this vulnerability.
Fixed in 3.20.1
Upgrade
Upgrade rust/actix-web to a version that resolves this vulnerability.
Fixed in 4.18.2
Upgrade
Upgrade actix-http to a version that resolves this vulnerability.
Fixed in 3.20.1
Upgrade
Upgrade actix-web to a version that resolves this vulnerability.
Fixed in 4.18.2
Configuration
Configure Decoder::limit() when using the decoder directly so decompressed output is bounded.
actix-http encoding::Decoder Decoder::limit() = body size limit
Compensating control
Reject compressed request bodies at a reverse proxy or in middleware before body extraction.

Frequently Asked Questions

Which applications are exposed to this denial-of-service issue?

Applications are affected if they decode untrusted gzip, deflate, Brotli, or Zstandard request or response bodies with the corresponding compression feature enabled. Actix Web applications are affected when they read compressed request bodies through body extractors.

What does an attacker need to exploit this issue?

An attacker needs control of a compressed request or response body that the application decodes. A small compressed payload can expand into a large output buffer, consuming memory and CPU before configured body-size limits are enforced.

Are extractor body-size limits sufficient protection?

No. In affected Actix Web versions, extractors do not pass their size limits to the decompression layer, so allocation can occur before the decoded body is rejected.

What can be done if upgrades cannot be applied immediately?

Reject compressed request bodies at a reverse proxy or in middleware before body extraction. For direct use of encoding::Decoder, configure Decoder::limit() to constrain decompression output.

What versions address the issue?

Upgrade actix-http to 3.20.1 or later. Actix Web users should also upgrade actix-web to 4.18.2 or later so extractor limits are passed to decompression.

RUSTSEC-2026-0447: Unbounded decompression can exhaust memory and CPU resources

Other sources

Affected Software

Remediation

Frequently Asked Questions

Which applications are exposed to this denial-of-service issue?

What does an attacker need to exploit this issue?

Are extractor body-size limits sufficient protection?

What can be done if upgrades cannot be applied immediately?

What versions address the issue?

Company

Resources

Contact

Frequently Asked Questions

Which applications are exposed to this denial-of-service issue?

What does an attacker need to exploit this issue?

Are extractor body-size limits sufficient protection?

What can be done if upgrades cannot be applied immediately?

What versions address the issue?