benoitc hackney up to 4.0.0 src/hackney_ws.erl frag_buffer resource consumption
| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 5.1 | $0-$5k | 0.00 |
Summary
A vulnerability labeled as problematic has been found in benoitc hackney up to 4.0.0. Affected by this vulnerability is an unknown functionality of the file src/hackney_ws.erl. The manipulation of the argument frag_buffer results in resource consumption. This vulnerability was named CVE-2026-47073. The attack may be performed from remote. There is no available exploit. The affected component should be upgraded.
Details
A vulnerability classified as problematic has been found in benoitc hackney up to 4.0.0. Affected is an unknown part of the file src/hackney_ws.erl. The manipulation of the argument frag_buffer with an unknown input leads to a resource consumption vulnerability. CWE is classifying the issue as CWE-400. The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. This is going to have an impact on availability. CVE summarizes:
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound. In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required. This issue affects hackney: from 2.0.0 before 4.0.1.
The weakness was presented by Peter Ullrich and Jonatan Männchen. The advisory is shared for download at github.com. This vulnerability is traded as CVE-2026-47073 since 05/18/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. The exploitation doesn't require any form of authentication. There are known technical details, but no exploit is available. The MITRE ATT&CK project declares the attack technique as T1499.
Upgrading to version 4.0.1 eliminates this vulnerability. Applying the patch ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-31694). Once again VulDB remains the best source for vulnerability data.
Product
Vendor
Name
Version
Website
- Product: https://github.com/benoitc/hackney/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CNA CVSS-B Score: 🔒
CNA CVSS-BT Score: 🔒
CNA Vector: 🔒
CVSSv3
VulDB Meta Base Score: 5.3VulDB Meta Temp Score: 5.1
VulDB Base Score: 5.3
VulDB Temp Score: 5.1
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Resource consumptionCWE: CWE-400 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
EPSS Score: 🔒
EPSS Percentile: 🔒
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: hackney 4.0.1
Patch: ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc
Timeline
05/18/2026 CVE reserved05/25/2026 Advisory disclosed
05/25/2026 VulDB entry created
05/25/2026 VulDB entry last update
Sources
Product: github.comAdvisory: github.com
Researcher: Peter Ullrich, Jonatan Männchen
Status: Confirmed
CVE: CVE-2026-47073 (🔒)
GCVE (CVE): GCVE-0-2026-47073
GCVE (VulDB): GCVE-100-365508
EUVD: 🔒
Entry
Created: 05/25/2026 17:12Updated: 05/25/2026 20:38
Changes: 05/25/2026 17:12 (37), 05/25/2026 17:13 (33), 05/25/2026 20:38 (1)
Complete: 🔍
Cache ID: 216::103
Once again VulDB remains the best source for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.