GHSA-9fm9-hp7p-53mf CVE-2025-3864
Hackney fails to properly release HTTP connections to the pool
- Severity
- 0.0 / 10
- Low · CVSS 4.0
- Exploit chance (EPSS)
- 0.87%
- Chance of exploitation in the next 30 days. Higher than 58.84% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-772 Missing Release of Resource after Effective Lifetime
- Fix
1.24.0- Upgrade hackney to this version or later
Description
Hackney fails to properly release HTTP connections to the pool after handling 307 Temporary Redirect responses. Remote attackers can exploit this to exhaust connection pools, causing denial of service in applications using the library. Fix for this issue has been included in 1.24.0 release.
Affected versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| hackney | < 1.24.0 |
1.24.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
hackney Hex → 1.24.0
- mix
{:hackney, "~> 1.24.0"} # then: mix deps.update hackney
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- Passive
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-772: Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
- Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-97200 Unbounded response body buffering and decompression in hackney | Not rated yet | Also affects hackney |
| EEF-CVE-2026-115693 Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney | Not rated yet | Also affects hackney |
| EEF-CVE-2026-113440 HTTP/1.1 and HTTP/2 redirects resend basic_auth and cookie to a different scheme or port in hackney | Not rated yet | Also affects hackney |
| EEF-CVE-2026-115700 SSRF allowlist bypass via percent-encoded bracketed IPv6 or trailing-dot IP literal in hackney | Not rated yet | Also affects hackney |
| EEF-CVE-2026-112880 CRLF injection in Proxy-Authorization header built from proxy_auth_fun in hackney | Not rated yet | Also affects hackney |
| EEF-CVE-2026-47073 Unbounded memory consumption in WebSocket client in hackney | High | Also affects hackney |
| EEF-CVE-2026-47067 Atom table exhaustion via unrecognized URL schemes in hackney | High | Also affects hackney |
| EEF-CVE-2026-47072 CRLF injection in WebSocket upgrade request in hackney | High | Also affects hackney |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor