Through a comprehensive security analysis conducted by OPSWAT's Red Team, security researchers Thai Do and Minh Pham identified multiple vulnerabilities impacting the Rack Ruby framework, specifically CVE-2025-25184, CVE-2025-27111, and CVE-2025-27610.
This article provides a detailed overview of these vulnerabilities, with a particular focus on CVE-2025-27610. It examines the root causes, evaluates potential impacts, and outlines effective mitigation strategies to secure applications relying on the Rack framework.
Overview of Rack
Rack is a modular interface that connects web servers to Ruby-based web applications. It standardizes the interaction between these components by wrapping HTTP requests and responses into a single method call, simplifying the development process and promoting compatibility across various frameworks and servers.
Rack is used by many Ruby web frameworks and libraries, such as Ruby on Rails and Sinatra. It is available as a Ruby Gem. The widespread global adoption of Rack, with more than one billion downloads globally, highlights its integral role within the Ruby development ecosystem. Middleware components such as Rack::Static and Rack::Sendfile enhance efficiency by handling static content delivery and optimizing file transmission. Due to this extensive integration, vulnerabilities discovered within Rack present substantial security implications, potentially affecting numerous applications and systems worldwide.
Security Vulnerability Discovery in Rack
During recent security research conducted on the Rack middleware framework, OPSWAT researchers Thai Do and Minh Pham identified several vulnerabilities that pose significant security risks to Ruby-based web applications:
- CVE-2025-25184: Thai Do discovered a vulnerability enables attackers to perform log injection via CRLF (Carriage Return Line Feed) characters, potentially manipulating log entries.
- CVE-2025-27111: Minh Pham uncovered a security flaw, which allows attackers to inject and manipulate log content through malicious header values.
- CVE-2025-27610: Minh Pham also identified a Path Traversal vulnerability, which could enable attackers to gain unauthorized access to files located outside the designated static file directory, posing a significant security threat.
Among these vulnerabilities, CVE-2025-27610 is particularly severe, as it could enable unauthenticated attackers to retrieve sensitive information, including configuration files, credentials, and confidential data, thereby leading to data breaches. This vulnerability has been assigned a CVSS score of 7.5, categorizing it as a high-severity risk.
Rack::Static and Local File Inclusion Vulnerability
Understanding Rack::Static
Rack::Static is an essential middleware in Rack applications used primarily to serve static files such as JavaScript, CSS, and images efficiently. By leveraging Rack::Static, developers can seamlessly integrate static content serving into Ruby applications without needing to rely on additional web server configuration.
When configuring Rack::Static, two essential options stand out - :urls and :root. Proper understanding and usage of these options significantly simplify and streamline the static file serving process.
1. The :urls Option
The :urls option specifies which URL paths the Rack application should handle as static assets. It is provided as an array of strings, each representing a path prefix that triggers static file handling.
For example:
In this configuration, requests to /images, /css, or /js are intercepted and processed by Rack::Static. Any file matching these paths will be directly served from the file system.
2. The :root Option
The :root option defines the base directory from which the static files will be served. This directory is relative to the current working directory of your Rack application.
Given the previous example:
When a request is made to /assets/logo.png, Rack::Static attempts to serve the file located at public/assets/logo.png.
Practical Example
Effective implementation of Rack::Static through the :urls and :root options delivers an organized and performant method for serving static content within Ruby web applications:
In this scenario, requests to /assets/* and /favicon.ico will automatically be handled by Rack::Static. All corresponding files should exist in the public/assets directory and public/favicon.ico respectively.
CVE-2025-27610 Technical Detail
During an extensive security analysis of Rack::Static, Minh Pham discovered a significant vulnerability related to improper handling of the :root option. Specifically, when the :root parameter is not explicitly defined, Rack defaults this value to the current working directory by assigning it the value of Dir.pwd, implicitly designating it as the web root directory for the Rack application.
Significantly, Rack::Static directly concatenates incoming URL paths with the specified :root directory without sufficient validation or sanitization. Consequently, if the :root option is either undefined or misconfigured relative to the :urls option, an unauthenticated attacker could exploit this vulnerability through path traversal techniques to access sensitive files outside the intended web directory.
The following section provides a detailed analysis of Rack::Static’s request-handling process, clearly illustrating how this vulnerability can be exploited.
Path Traversal and Local File Inclusion Vulnerability in Rack::Static
To gain a deeper understanding of how the Rack::Static middleware processes requests, Minh Pham conducted a thorough analysis of Rack's source code. During the initialization of the Rack::Static class, he observed that if the :root option is not explicitly defined, Rack::Static defaults to serving files from the current working directory (Dir.pwd). Consequently, omitting this option results in the middleware implicitly using the directory from which the application is executed.
Following initialization, it was determined that when Rack::Static receives an incoming HTTP request, the call method is invoked.
Subsequently, Rack::Static delegates the file-serving operation to Rack::Files, which attempts to locate and serve the file based on the constructed file path derived from the configured :root directory and the user-supplied PATH_INFO.
First, by invoking the methods can_serve(path) and overwrite_file_path(path), the middleware examines the env["PATH_INFO"] to determine whether the incoming request matches any of the configured URL prefixes (e.g., /static, /public).
If the condition is met, Rack::Static constructs the file path by combining the configured root directory (:root) with the user-supplied PATH_INFO. This construction occurs without adequate normalization or sanitization of the input path. Specifically, the middleware directly concatenates the PATH_INFO from the incoming request with the directory specified by the :root option, introducing a vulnerability due to insufficient validation of the supplied path
Minh Pham discovered that due to the absence of proper sanitization or validation in this workflow, if the user-supplied PATH_INFO contains directory traversal sequences, and the :root option is not explicitly defined, the constructed file path could resolve to a location outside of the intended root directory, potentially exposing sensitive files.
CVE-2025-27610 Proof of Concept
To demonstrate this vulnerability in Rack::Static, we developed a Ruby-based web application utilizing Rack version 3.1.10. In scenarios where the application does not explicitly define the :root option, an unauthenticated attacker can exploit this vulnerability to access sensitive data, such as credentials, configuration files, or database files, potentially leading to a significant data breach.
Please refer to the following video for a detailed demonstration of the significant impact associated with this vulnerability:
Mitigation and Guidance
To mitigate the vulnerabilities we discussed above, please ensure that your system is updated to the latest version of Rack.
MetaDefender Core using SBOM engine can detect this vulnerability.
OPSWAT MetaDefender Core, equipped with advanced SBOM (Software Bill of Materials) capabilities, enables organizations to take a proactive approach in addressing security risks. By scanning software applications and their dependencies, MetaDefender Core identifies known vulnerabilities, such as CVE-2025-27610, CVE-2025-27111 and CVE-2025-25184, within the listed components. This empowers development and security teams to prioritize patching efforts, mitigating potential security risks before they can be exploited by malicious actors.
Below is a screenshot of CVE-2025-27610, CVE-2025-27111 and CVE-2025-25184, which were detected by MetaDefender Core with SBOM:
