CVE-2026-115825
Description
A flaw was found in perl-Plack. The HTTP::Server::PSGI server pre-allocates memory for incoming request bodies based entirely on the declared Content-Length header before reading data. A remote attacker can exploit this flaw by sending an HTTP request with an excessively large Content-Length header, causing the server to exhaust memory and crash. This results in a Denial of Service (DoS), keeping the single-process server unavailable until it is restarted.
Statement
A flaw was found in the Plack Perl web application framework's standalone HTTP::Server::PSGI server. It pre-allocates memory for a request body based on the untrusted Content-Length header before reading data, so a single request with an excessively large Content-Length can cause an out-of-memory exit, leaving the single-process server unavailable until restarted. Upstream fixed this in Plack 1.0056 by capping body reads at 64 KiB.
Mitigation
Upgrade to perl-Plack 1.0056 or later. As a workaround, do not expose the standalone HTTP::Server::PSGI (a development/reference server) to untrusted networks; front it with a reverse proxy that limits request body size, or use a production handler such as FCGI or Starman.
--- CME Mitigation Guidance (2026-11-02) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to cap sysread chunk sizes during request body reads instead of allocating memory directly from untrusted Content-Length headers in HTTP::Server::PSGI: upgrade to perl-Plack 1.0056 (or the fixed Perl Plack builds), which cap request body sysread chunk sizes at 64 KiB and reject malformed, negative, duplicate, or overly long Content-Length headers with HTTP 400 Bad Request, closing excessively large Content-Length HTTP header declaration. Until patched, this is a concern on Linux systems running standalone HTTP::Server::PSGI directly exposed to the network without a request-limiting front-end reverse proxy, so Do not expose standalone HTTP::Server::PSGI directly to untrusted networks; front it with a reverse proxy enforcing request body limits or migrate to production handlers like FCGI or Starman. As a compensating measure, Monitor cgroup memory pressure signals and oom_kill counters to detect memory exhaustion and out-of-memory aborts, Configure systemd watchdog and automatic restart settings to recover availability when the single-process server terminates, and Enforce cgroups v2 memory limits on the service to restrict maximum memory consumption and protect host stability. These controls limit blast radius and contain exploitation, but they do not fix the underlying unbounded memory pre-allocation defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-1010 cgroup Memory Pressure Monitoring (memory.events / PSI) (medium)
Understanding the Weakness (CWE)
Availability
Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)
When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource. It can be easy for an attacker to consume many resources by rapidly making many requests or causing larger resources to be used than is needed.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
