Rack Rack::Directory – Directory Traversal Vulnerability
| Field | Value |
|---|---|
| CVE ID | CVE-2026-22860 |
| Affected Component | Rack – Rack::Directory middleware |
| Vulnerability Type | Directory Traversal (Improper Path Restriction – CWE-22) |
| CVSS v3.1 Score | 7.5 (High) |
| Severity | High |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Impact | Confidentiality: High; Integrity: None; Availability: None |
| Exploitability | Easily exploitable if Rack::Directory is exposed to untrusted users |
| Exploit Availability | No public weaponized exploit; can be reproduced using crafted HTTP requests |
Overview
A directory traversal issue was identified in the Rack::Directory middleware component of Rack. The vulnerability exists due to improper validation of filesystem paths when serving directory listings.
Path validation logic relied on a simple string prefix comparison to determine whether a requested path was within the configured root directory. Because only a basic start_with? string check was performed, sibling directories with similar prefixes could be incorrectly treated as valid subdirectories.
As a result, directory listings outside the intended web root could be exposed.
This issue does not directly allow code execution. However, sensitive information such as configuration files, source code, environment files, backup folders, and private assets could be disclosed.
Root Cause
The middleware expanded requested paths using filesystem normalization. After expansion, it verified whether the resulting path started with the configured root path.
The flaw existed because:
- The comparison did not enforce a directory boundary.
- Only string matching was used.
- Filesystem canonical validation was incomplete.
Example scenario:
Configured root:
/var/www/public
Existing directory:
/var/www/public_backup
Expanded path:
/var/www/public_backup/
Since /var/www/public_backup starts with /var/www/public, the validation incorrectly allowed access.
A proper boundary check should have ensured:
expanded_path.start_with?(root + File::SEPARATOR)
This boundary enforcement was missing in affected versions.
Affected Versions
Rack versions prior to:
- 2.2.22
- 3.1.20
- 3.2.5
Fixed Versions
- 2.2.22
- 3.1.20
- 3.2.5
Official Patch / Upgrade Link
https://github.com/rack/rack/security/advisories/GHSA-mxw3-3hh2-x2mh
Upgrading to the latest patched version is strongly recommended.
Impact Analysis
If successfully exploited, the following could occur:
- Directory listing exposure outside intended root
- Discovery of backup directories
- Exposure of configuration files
- Leakage of environment variables
- Disclosure of source code
- Mapping of internal file structure
While no write access or remote execution is provided directly, exposed information may enable follow-on attacks.
Exploitation Details (Educational Purpose Only)
The vulnerability may be reproduced in a lab environment where:
- Rack application exposes
Rack::Directory - The server contains directories with similar prefixes
- The service is reachable over HTTP
Example Exploitation Requests
Plain traversal attempt:
GET /../public_backup/ HTTP/1.1
Host: vulnerable.local
Encoded traversal attempts:
GET /..%2Fpublic_backup/ HTTP/1.1
GET /%2e%2e%2fpublic_backup/ HTTP/1.1
GET /%2e%2e/%2e%2e/public_backup/ HTTP/1.1
Double encoded variant:
GET /%252e%252e%252fpublic_backup/ HTTP/1.1
If vulnerable, a directory listing response (HTTP 200) will be returned instead of a 403 or 404.
Proof of Concept (Educational)
Minimal reproduction example:
require 'rack'
app = Rack::Builder.new do
use Rack::Directory, "./public"
end
Rack::Handler::WEBrick.run app, Port: 9292
Create directories:
public/
public_backup/
Access:
http://localhost:9292/../public_backup/
If vulnerable, contents of public_backup will be listed.
Detection Guidance
Log Sources
- Web server access logs (Nginx, Apache)
- Reverse proxy logs
- WAF logs
- Application logs
- IDS/IPS logs
- Load balancer logs
Indicators of Compromise
- Requests containing
../ - Encoded dot traversal patterns
- Access to unexpected sibling directories
- Directory listing responses from unexpected paths
- Repeated probing of filesystem paths
Detection Rules
Web Server Log Query
grep -Ei "\.\./|%2e%2e|%2e%2e%2f|%252e%252e" access.log
Elastic / OpenSearch Query
http.request.method:GET AND
(
http.request.uri:*"../"* OR
http.request.uri:*"%2e%2e"* OR
http.request.uri:*"%252e%252e"*
)
Splunk Query
index=web_logs
| search uri="*../*" OR uri="*%2e%2e*" OR uri="*%252e%252e*"
| stats count by src_ip, uri, status
Suricata Rule
alert http any any -> any any (
msg:"Possible Rack Directory Traversal Attempt";
flow:to_server,established;
http_uri;
pcre:"/(\.\.\/|%2e%2e%2f|%2e%2e\/|%252e%252e%252f)/i";
classtype:web-application-attack;
sid:2286001;
rev:1;
)
Snort Rule
alert tcp any any -> any 80 (
msg:"Directory Traversal Attempt - Rack";
flow:to_server,established;
content:"../";
http_uri;
nocase;
sid:2286002;
rev:1;
)
Mitigation Recommendations
- Upgrade Rack immediately to patched version.
- Disable
Rack::Directoryif not required. - Avoid exposing directory listing middleware to public networks.
- Place application behind a WAF.
- Enforce strict path normalization checks.
- Monitor and alert on traversal patterns.
- Remove backup directories from production servers.
Temporary Hardening (If Patch Cannot Be Applied Immediately)
- Rename directories to avoid prefix similarities.
- Restrict static file serving.
- Block traversal patterns at reverse proxy.
- Deny access to directory listing endpoints.
- Implement strict realpath boundary enforcement.
MITRE Mapping
CWE
CWE-22 – Improper Limitation of a Pathname to a Restricted Directory
ATT&CK
T1190 – Exploit Public-Facing Application
Risk Assessment
Internet-facing Rack applications serving static directories are at highest risk.
Internal systems remain vulnerable if exposed through reverse proxies or misconfigured access rules.
Because exploitation requires no authentication and low complexity, patch prioritization should be considered urgent.
Remediation Checklist
- Identify Rack version in use.
- Upgrade to fixed version.
- Restart application.
- Validate traversal no longer works.
- Review logs for historical exploitation attempts.
- Harden monitoring rules.
Final Recommendation
Immediate upgrade is the only complete remediation.
This issue stems from insufficient path boundary validation, and although impact is limited to information disclosure, exposed sensitive files may significantly increase risk of broader compromise.
Applying the official patch and implementing log-based detection should be considered mandatory for all affected deployments.
