There are 6 open security issues in trixie.
5 issues left for the package maintainer to handle:
- CVE-2026-110332:
(needs triaging)
- CVE-2026-110333:
(needs triaging)
- CVE-2026-110334:
(needs triaging)
- CVE-2026-110335:
(needs triaging)
- CVE-2026-115825:
(needs triaging)
HTTP::Server::PSGI versions before 1.0056 for Perl allow a single request to crash the server by declaring a large Content-Length. The request body is read with sysread() calls sized by the remaining Content-Length. Perl grows the read buffer to the requested length before any data arrives, so the server tries to allocate as much memory as the client declares. A remote attacker can send one request with a large Content-Length and a few body bytes, and perl exits with an out-of-memory error before the application is called. HTTP::Server::PSGI runs as a single process, so the server stays down until restarted.
You can find information about how to handle these issues in the security team's documentation.
1 ignored issue:
- CVE-2026-7381:
Plack::Middleware::XSendfile versions through 1.0053 for Perl can allow client-controlled path rewriting. Plack::Middleware::XSendfile allows the variation setting (sendfile type) to be set by the client via the X-Sendfile-Type header, if it is not considered in the middleware constructor or the Plack environment. A malicious client can set the X-Sendfile-Type header to "X-Accel-Redirect" to services running behind nginx reverse proxies, and then set the X-Accel-Mapping to map the path to an arbitrary file on the server. Since 1.0053, Plack::Middleware::XSendfile is deprecated and will be removed from future releases of Plack. This is similar to CVE-2025-61780 for Rack::Sendfile, although Plack::Middleware::XSendfile has some mitigations that disallow regular expressions to be used in the mapping, and only apply the mapping for the "X-Accel-Redirect" type.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/libp/libplack-perl.png){kind=link}