CVE-2026-7381
Received Received - Intake
Path Traversal in Plack::Middleware::XSendfile

Publication date: 2026-04-29

Last updated on: 2026-04-30

Assigner: CPANSec

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-29
Last Modified
2026-04-30
Generated
2026-05-07
AI Q&A
2026-04-30
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
tatsuhiko_miyagawa plack_middleware_xsendfile to 1.0053 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-913 The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.
CWE-200 The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
CWE-441 The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided context and resources do not explicitly discuss the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

This vulnerability exists in Plack::Middleware::XSendfile versions through 1.0053 for Perl. It allows a client to control path rewriting by setting the X-Sendfile-Type header. Specifically, a malicious client can set this header to "X-Accel-Redirect" to target services running behind nginx reverse proxies and then use the X-Accel-Mapping header to map the path to an arbitrary file on the server.

This means that the middleware does not properly restrict how the sendfile type and path mappings are controlled, enabling an attacker to potentially access files they should not be able to.

Since version 1.0053, Plack::Middleware::XSendfile is deprecated and will be removed in future releases.


How can this vulnerability impact me? :

This vulnerability can allow a malicious client to access arbitrary files on the server by manipulating the X-Sendfile-Type and X-Accel-Mapping headers. This could lead to unauthorized disclosure of sensitive information or files that should be protected.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, avoid allowing clients to set the X-Sendfile-Type header in Plack::Middleware::XSendfile. Since version 1.0053, this middleware is deprecated and will be removed in future releases, so upgrading to a version without this middleware or using alternative secure methods is recommended.

Additionally, ensure that the middleware constructor or Plack environment does not permit client-controlled path rewriting via the X-Sendfile-Type or X-Accel-Mapping headers, especially when running services behind nginx reverse proxies.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves client-controlled path rewriting via the X-Sendfile-Type and X-Accel-Mapping headers in Plack::Middleware::XSendfile. To detect potential exploitation attempts on your network or system, you should monitor HTTP requests for suspicious or unexpected values in these headers.

  • Inspect incoming HTTP requests for the presence of the header 'X-Sendfile-Type' set to 'X-Accel-Redirect'.
  • Check for the 'X-Accel-Mapping' header in requests, especially if it maps paths to arbitrary or sensitive locations on the server.

You can use command-line tools like tcpdump, tshark, or curl combined with grep to detect these headers in network traffic or logs.

  • Example tcpdump command to capture HTTP headers containing 'X-Sendfile-Type': tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -i 'X-Sendfile-Type'
  • Example grep command to search web server access or proxy logs for suspicious headers: grep -i 'X-Sendfile-Type: X-Accel-Redirect' /var/log/nginx/access.log
  • Use curl to manually test endpoints by sending crafted headers: curl -H 'X-Sendfile-Type: X-Accel-Redirect' -H 'X-Accel-Mapping: /internal/path=/etc/passwd' http://yourserver/endpoint

Monitoring for these headers and unusual path mappings can help detect attempts to exploit this vulnerability.


Can you explain this vulnerability to me?

This vulnerability exists in Plack::Middleware::XSendfile versions through 1.0053 for Perl. It allows a malicious client to control path rewriting by setting the X-Sendfile-Type header to "X-Accel-Redirect" and manipulating the X-Accel-Mapping header. This can cause the middleware to map the path to an arbitrary file on the server, potentially exposing unintended files.

The issue arises because the middleware allows the client to specify the sendfile type via headers if not properly restricted in the middleware constructor or environment. Although some mitigations exist, such as disallowing regular expressions in the mapping and applying the mapping only for the "X-Accel-Redirect" type, the vulnerability still permits client-controlled path rewriting.

This vulnerability is similar to CVE-2025-61780 affecting Rack::Sendfile, but with some differences in mitigation.


How can this vulnerability impact me? :

An attacker exploiting this vulnerability can manipulate headers to cause the server to serve arbitrary files by rewriting paths. This can lead to unauthorized access to sensitive files on the server, potentially exposing confidential information.

Since the middleware delegates file serving to the web server based on client-controlled headers, an attacker might bypass intended access controls and retrieve files that should not be accessible.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves the manipulation of the X-Sendfile-Type and X-Accel-Mapping headers by a client to perform path rewriting. Detection can focus on monitoring HTTP requests for unusual or unexpected values in these headers.

  • Inspect incoming HTTP requests for the presence of the X-Sendfile-Type header set to "X-Accel-Redirect".
  • Check for the X-Accel-Mapping header in requests, especially if it maps to arbitrary or suspicious file paths.
  • Use network traffic capture tools like tcpdump or Wireshark to filter HTTP headers containing these values.
  • Example command to capture HTTP headers with tcpdump: tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -i -E 'X-Sendfile-Type|X-Accel-Mapping'
  • On the server, review web server or application logs for requests containing these headers with suspicious values.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include preventing clients from controlling the X-Sendfile-Type and X-Accel-Mapping headers and upgrading the affected module.

  • Upgrade Plack::Middleware::XSendfile to a version later than 1.0053 or remove it, as it is deprecated and planned for removal in future releases.
  • Configure the middleware constructor or Plack environment to disallow client control over the X-Sendfile-Type header.
  • If using nginx as a reverse proxy, ensure it properly validates or strips these headers from client requests to prevent misuse.
  • Monitor and filter incoming HTTP requests to block those with suspicious X-Sendfile-Type or X-Accel-Mapping headers.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart