CVE-2025-27111

What it actually does

Rack::Sendfile in affected Rack versions writes the X-Sendfile-Type request header value to application logs without sufficiently sanitizing control characters. A remote client that can send HTTP requests to a Rack-based application using this middleware can include newline, carriage return, terminal escape, or other control sequences in that header. This can forge additional log entries, alter the visual rendering of logs, confuse parsers, or hide the attacker’s real request context. The flaw is log integrity impact rather than direct code execution, authentication bypass, or data exfiltration.

Why it matters to the business

The primary risk is loss of trust in application and security logs. An attacker may make incident response, audit review, alerting, and forensic timelines less reliable by injecting misleading records or breaking downstream log parsing. Because Rack is a common Ruby web interface component, exposure can appear indirectly through Ruby applications and frameworks that include vulnerable Rack versions. The current public exploitation signal is low: EPSS is low, it is not listed in CISA KEV, and no mature public exploit is indicated; however, remediation is still important where logs are used for compliance, fraud investigation, or security monitoring.

How an attack unfolds

An attacker identifies a Rack-based web application that includes the Rack::Sendfile middleware and runs a vulnerable Rack version. The attacker sends an HTTP request containing a crafted X-Sendfile-Type header with embedded control characters such as carriage return and newline sequences or terminal escape codes. When the middleware logs the header value, the unsanitized content is written into the application log. The injected content may appear as a separate forged log line, corrupt the structure of JSON or text logs, manipulate terminal display output, or interfere with SIEM ingestion and parsing. The attacker can then use the polluted logs to obscure reconnaissance, make requests appear to originate from different paths or statuses, create false indicators, or complicate later investigation.

How to fix it

Upgrade Rack to a fixed release: 2.2.12 or later for the 2.2.x line, 3.0.13 or later for the 3.0.x line, or 3.1.11 or later for the 3.1.x line. For source-based deployments, include the upstream fix at commit 78296637d7b35dcd357a64e8c76bd7f664c1cdbf or a later trusted commit. Rebuild and redeploy all Ruby applications that vendor or bundle Rack, including transitive dependencies through frameworks. If immediate upgrade is not possible, add compensating controls to reject or normalize X-Sendfile-Type values containing control characters before they reach the application, and configure logging pipelines to escape CR, LF, ANSI escape, and other non-printable characters. Avoid relying on log filtering alone as the long-term fix because the vulnerable application code can still emit untrusted content.

How to confirm the fix worked

Confirm deployed applications resolve Rack to a fixed version by checking dependency manifests and runtime package listings, such as Gemfile.lock, bundle list, gem list rack, or container software bills of materials. Validate that no running artifact contains Rack versions earlier than 2.2.12, 3.0.13, or 3.1.11 within the applicable release line. As a functional test in a non-production environment, send a request with an X-Sendfile-Type header containing CR/LF or escaped control characters and confirm logs either reject the request, safely escape the characters, or record the value on a single sanitized line. Verify SIEM parsers continue to parse the event as one record and do not create attacker-controlled fields or separate events.

Typical attack path

1. Identify a Ruby/Rack application exposed over HTTP that uses Rack::Sendfile or a framework stack including the affected middleware.
2. Confirm the application accepts arbitrary request headers and that X-Sendfile-Type reaches Rack logging behavior.
3. Send a request with X-Sendfile-Type containing newline, carriage return, ANSI escape, or other control characters.
4. Cause the application or web server log pipeline to record the unsanitized header value.
5. Use the injected log content to forge entries, disrupt parsing, mislead analysts, or hide surrounding malicious activity.

How to detect it

Review application access logs, Rack/Rails application logs, reverse proxy logs, WAF logs, and SIEM raw events for requests containing the X-Sendfile-Type header with encoded or literal control characters. Focus on carriage return, newline, tab-heavy padding, ANSI escape sequences, percent-encoded control characters, and log entries where a single HTTP request appears to create multiple records. Look for malformed timestamps, duplicated log prefixes, unexpected status codes embedded inside header values, broken JSON log records, parser errors, or events that contain X-Sendfile-Type followed by text resembling a new access-log or application-log entry. If centralized logging stores both raw and parsed events, compare raw message bodies against parsed fields to identify field injection or record splitting. Investigate nearby requests from the same source address, user agent, session, or API token because log injection may have been used to conceal broader probing or exploitation activity.

• X-Sendfile-Type
• X-Sendfile-Type: %0a
• X-Sendfile-Type: %0A
• X-Sendfile-Type: %0d
• X-Sendfile-Type: %0D
• X-Sendfile-Type: %0d%0a
• X-Sendfile-Type: %0D%0A
• X-Sendfile-Type: \r
• X-Sendfile-Type: \n
• X-Sendfile-Type: \r\n
• X-Sendfile-Type: \x0a
• X-Sendfile-Type: \x0d
• X-Sendfile-Type: %1b
• X-Sendfile-Type: %1B
• X-Sendfile-Type: \x1b
• X-Sendfile-Type: \u001b
• X-Sendfile-Type: \033
• X-Sendfile-Type: [
• Invalid X-Sendfile-Type header
• malformed log record
• log parser error
• unexpected newline in header
• control character in header

What your security team should do

• Inventory Ruby and Rack-based applications, including containers and vendored dependencies, and identify any Rack versions below 2.2.12, 3.0.13, or 3.1.11.
• Prioritize upgrades for internet-facing applications and systems whose logs feed security monitoring, fraud detection, audit evidence, or compliance reporting.
• Deploy the fixed Rack release through normal dependency management and rebuild application images or packages to ensure the vulnerable gem is removed.
• Add temporary request validation at reverse proxies, WAFs, or application middleware to block X-Sendfile-Type values containing CR, LF, ANSI escape, or other control characters.
• Harden log ingestion pipelines to preserve log integrity by escaping control characters and alerting on malformed or multi-line header-derived fields.
• Search historical logs for suspicious X-Sendfile-Type values to determine whether log pollution attempts occurred before patching.
• Do not treat absence from CISA KEV or low EPSS as a reason to ignore the issue where audit-quality logging is a business requirement.