HTTP Response Splitting (Early Hints) in Puma

The core of this vulnerability lies in Puma's handling of early-hints headers. If an application using Puma accepts untrusted input within these headers, a malicious actor can exploit this by injecting a carriage return character. This effectively terminates the header prematurely, allowing the attacker to inject arbitrary content, such as additional headers or even a completely new response body. While not a direct attack vector itself, HTTP Response Splitting serves as a foundation for numerous other attacks. The most common consequence is cross-site scripting (XSS), where injected scripts can compromise user sessions and steal sensitive data. Furthermore, response splitting can be leveraged for cache poisoning, session hijacking, and other malicious activities, significantly expanding the potential blast radius of this vulnerability.

Applications built with Ruby on Rails or other Ruby frameworks that utilize Puma as their web server are at risk. Specifically, deployments using Puma versions 3.9.1 or earlier, especially those that accept user-supplied data in HTTP headers without proper validation, are highly vulnerable. Shared hosting environments where users have control over application configuration are also at increased risk.

• ruby / puma:

  grep -r 'early-hints' /path/to/puma/config.yml

• generic web:

  curl -I 'http://your-puma-app.com' | grep 'early-hints'

• generic web:

  grep -r 'early-hints' /var/log/nginx/access.log

1. 2020-03-03Disclosure

   disclosure

1. 已保留2020-01-02
2. 发布日期2020-03-03
3. 修改日期2026-02-04
4. EPSS 更新日期2026-04-02

The primary mitigation for CVE-2020-5249 is to upgrade Puma to version 3.12.4 or later, which includes the necessary fix. If an immediate upgrade is not feasible due to compatibility issues or breaking changes, consider implementing a temporary workaround by sanitizing or validating early-hints headers to prevent carriage return characters from being included. Web application firewalls (WAFs) can also be configured to filter out suspicious early-hints headers. Additionally, review application code to ensure that any user-supplied data included in HTTP headers is properly escaped to prevent injection attacks. After upgrading, confirm the fix by sending a request with a crafted early-hints header containing a carriage return and verifying that the response does not contain the injected content.