CVE-2026-120651: CGI versions before 5.00 for Perl allow an infinite loop on a short request body when $DISABLE_UPLOADS is set

Q: Which deployments are exposed to this denial-of-service condition?

Deployments using CGI for Perl before version 5.00 are affected when CGI::DISABLE_UPLOADS is set and either CGI::PUTDATA_UPLOAD or an upload hook is configured. The affected request path handles request bodies that are not form submissions.

Q: What must an attacker send to trigger the loop?

The attacker must send a non-form request body whose actual length is shorter than the declared Content-Length. After the supplied body ends, reads return 0 while the code continues waiting for the declared number of bytes.

Q: What is the operational impact of exploitation?

A single crafted request can keep a server process spinning indefinitely. This creates a denial-of-service risk through exhaustion of available server processes or CPU resources.

Q: What can be done if upgrading is not immediately possible?

The provided information identifies the vulnerable condition as requiring CGI::DISABLE_UPLOADS together with CGI::PUTDATA_UPLOAD or an upload hook. Avoiding that affected configuration removes the described trigger path until CGI is updated to version 5.00 or later.

Published Nov 3, 2026

Updated

CGI versions before 5.00 for Perl allow an infinite loop on a short request body when $DISABLEUPLOADS is set.

When $CGI::PUTDATAUPLOAD or an upload hook is set, readpostdataputdata takes a request body that is not a form submission. With $CGI::DISABLEUPLOADS set, it discards the body by reading until Content-Length bytes have arrived. Once a body shorter than its Content-Length runs out, every read returns 0, so the loop never ends.

A client can keep a server process spinning with one such request.

Affected Software

4 affected components

debian/libcgi-pm-perl*

debian/libcgi-pm-perl<=4.55-1, <=4.68-1, <=4.72-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade CGI for Perl to a version that resolves this vulnerability.
Fixed in 5.00

Event History

Nov 3, 2026

CVE Published

via MITRE·11:41 PM

Data Sourced

via MITRE·11:41 PM

RemedyDescriptionWeakness

Nov 4, 2026

Data Sourced

via NVD·12:17 AM

DescriptionWeakness

Data Sourced

via OSV·12:17 AM

DescriptionAffected Software

Frequently Asked Questions

Which deployments are exposed to this denial-of-service condition?

Deployments using CGI for Perl before version 5.00 are affected when CGI::DISABLE_UPLOADS is set and either CGI::PUTDATA_UPLOAD or an upload hook is configured. The affected request path handles request bodies that are not form submissions.

What must an attacker send to trigger the loop?

The attacker must send a non-form request body whose actual length is shorter than the declared Content-Length. After the supplied body ends, reads return 0 while the code continues waiting for the declared number of bytes.

What is the operational impact of exploitation?

A single crafted request can keep a server process spinning indefinitely. This creates a denial-of-service risk through exhaustion of available server processes or CPU resources.

What can be done if upgrading is not immediately possible?

The provided information identifies the vulnerable condition as requiring CGI::DISABLE_UPLOADS together with CGI::PUTDATA_UPLOAD or an upload hook. Avoiding that affected configuration removes the described trigger path until CGI is updated to version 5.00 or later.

CVE-2026-120651: CGI versions before 5.00 for Perl allow an infinite loop on a short request body when $DISABLE_UPLOADS is set

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are exposed to this denial-of-service condition?

What must an attacker send to trigger the loop?

What is the operational impact of exploitation?

What can be done if upgrading is not immediately possible?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this denial-of-service condition?

What must an attacker send to trigger the loop?

What is the operational impact of exploitation?

What can be done if upgrading is not immediately possible?