Search
Search Results (6 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-115822 | 1 Miyagawa | 1 Starman | 2026-10-25 | N/A |
| Starman versions before 0.4019 for Perl allow CPU exhaustion via quadratic regex backtracking when parsing chunked request bodies. Starman decodes chunked request bodies before calling the application, matching each chunk-size line with `s/^(([0-9a-fA-F]+).*\015\012)//`. A line of hex digits followed by a bare LF and then CRLF never matches, because `.` does not match LF, and each failed attempt backtracks in time quadratic in the length of the hex run. Nothing limits the length of the line. A remote attacker can exhaust worker CPU by sending such requests to any route. | ||||
| CVE-2026-115817 | 1 Miyagawa | 1 Starman | 2026-10-25 | N/A |
| Starman versions before 0.4019 for Perl allow a stalled request body to hold a worker indefinitely, as read_timeout covers only the headers. Content-Length and chunked request bodies are read with blocking reads and no deadline. A client that sends complete headers and then stalls or trickles the body keeps the worker waiting until it disconnects. A remote attacker can take every worker with a few such connections, five with the default worker count, so the server stops answering requests. Version 0.4019 applies read_timeout to each wait for body data and adds a body_timeout limit, 300 seconds by default, on the total time to read a body. | ||||
| CVE-2026-115824 | 1 Miyagawa | 1 Starman | 2026-10-25 | N/A |
| Starman versions before 0.4019 for Perl allow memory exhaustion via unbounded buffering of chunked request bodies. The chunked body decoder keeps each chunk in memory until the whole chunk and its CRLF have arrived, and sets no limit on the length of a chunk-size line. A client that declares a huge chunk size and streams data, or sends a chunk-size line that never ends, grows the buffer for as long as it keeps sending. A remote attacker can exhaust worker memory with a single connection. | ||||
| CVE-2026-7381 | 1 Miyagawa | 2 Plack::middleware::xsendfile, Plack\ | 2026-05-07 | 9.1 Critical |
| 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. | ||||
| CVE-2026-40560 | 1 Miyagawa | 1 Starman | 2026-05-06 | 7.5 High |
| Starman versions before 0.4018 for Perl allows HTTP Request Smuggling via Improper Header Precedence. Starman incorrectly prioritizes "Content-Length" over "Transfer-Encoding: chunked" when both headers are present in an HTTP request. Per RFC 7230 3.3.3, Transfer-Encoding must take precedence. An attacker could exploit this to smuggle malicious HTTP requests via a front-end reverse proxy. | ||||
| CVE-2014-125112 | 1 Miyagawa | 2 Plack::middleware::session::cookie, Plack\ | 2026-05-06 | 9.8 Critical |
| Plack::Middleware::Session::Cookie versions through 0.21 for Perl allows remote code execution. Plack::Middleware::Session::Cookie versions through 0.21 has a security vulnerability where it allows an attacker to execute arbitrary code on the server during deserialization of the cookie data, when there is no secret used to sign the cookie. | ||||
Page 1 of 1.