CVE-2026-47076
Analyzed Analyzed - Analysis Complete
Server Side Request Forgery in hackney

Publication date: 2026-05-25

Last updated on: 2026-05-27

Assigner: EEF

Description
Interpretation Conflict vulnerability in benoitc hackney allows Server Side Request Forgery. hackney_url:normalize/2 URL-decodes the host component after the URL has been parsed into a #hackney_url{} record. OTP's uri_string:parse/1 and inet:parse_address/1 do not decode percent-escapes in the host, so a URL such as http://%31%32%37%2E%30%2E%30%2E%31/ is seen by a caller's allowlist validator with host %31%32%37%2E%30%2E%30%2E%31 (not an IP address), which passes the allowlist check. hackney's normalizer then decodes the host to 127.0.0.1 and opens a TCP connection to loopback. Because hackney:request/5 always calls hackney_url:normalize/2 with no opt-out, every request that takes a binary or list URL is affected. The same technique reaches cloud instance metadata services (169.254.169.254), RFC1918 networks, and any admin interface listening on localhost. This issue affects hackney: from 0.13.0 before 4.0.1.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-25
Last Modified
2026-05-27
Generated
2026-06-15
AI Q&A
2026-05-26
EPSS Evaluated
2026-06-14
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
benoitc hackney From 0.13.0 (inc) to 4.0.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-918 The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
CWE-436 Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability is an Interpretation Conflict in the benoitc hackney library that allows Server Side Request Forgery (SSRF). The issue arises because hackney_url:normalize/2 URL-decodes the host component after the URL has been parsed, while OTP's uri_string:parse/1 and inet:parse_address/1 do not decode percent-escapes in the host. This discrepancy means that a URL like http://%31%32%37%2E%30%2E%30%2E%31/ appears to an allowlist validator as a non-IP address string, passing the check, but hackney then decodes it to 127.0.0.1 and opens a TCP connection to the loopback address. Since hackney:request/5 always calls hackney_url:normalize/2 without an opt-out, every request using a binary or list URL is vulnerable. This technique can be used to reach internal services such as cloud instance metadata services, RFC1918 networks, and admin interfaces on localhost.

Impact Analysis

This vulnerability can allow an attacker to bypass allowlist checks and make unauthorized requests from the vulnerable server to internal or protected network resources. This can lead to exposure of sensitive internal services such as cloud instance metadata endpoints, private network addresses, or administrative interfaces that are normally inaccessible externally. Exploiting this SSRF vulnerability could result in information disclosure, unauthorized access, or further attacks within the internal network.

Compliance Impact

CVE-2026-47076 is a Server-Side Request Forgery (SSRF) vulnerability that allows attackers to bypass allowlist protections and access internal resources such as localhost, cloud metadata services, and RFC1918 networks.

This kind of vulnerability can lead to unauthorized access to sensitive internal systems and data, which may result in data breaches or exposure of confidential information.

Such unauthorized access and potential data exposure could negatively impact compliance with data protection regulations and standards like GDPR and HIPAA, which require safeguarding personal and sensitive data against unauthorized access.

However, the provided information does not explicitly discuss compliance impacts or specific regulatory consequences.

Detection Guidance

This vulnerability involves the decoding of percent-encoded hostnames in URLs after allowlist checks, which can be exploited by URLs containing percent-encoded IP addresses such as http://%31%32%37%2E%30%2E%30%2E%31/ (which decodes to 127.0.0.1). Detection can focus on identifying requests or logs containing such percent-encoded IP addresses that bypass allowlist validations.

To detect potential exploitation attempts, you can search your network or application logs for URLs with percent-encoded IP addresses in the host component. For example, using command-line tools like grep or similar on logs:

  • grep -E '%[0-9A-Fa-f]{2}' /path/to/logfile | grep -E '%31%32%37|%31%36%39|%31%37%32' # Searching for percent-encoded IP patterns like 127, 169, 172
  • Use network monitoring tools to inspect HTTP requests for percent-encoded hosts that decode to internal IP addresses such as 127.0.0.1 or 169.254.169.254.

Additionally, reviewing application logs for hackney library usage and checking if versions prior to 4.0.1 are in use can help identify vulnerable systems.

Mitigation Strategies

The primary mitigation step is to upgrade the hackney library to version 4.0.1 or later, where the vulnerability has been fixed by rejecting hosts that decode to IP literals after normalization.

If upgrading immediately is not possible, consider implementing additional validation on URLs before passing them to hackney, ensuring that percent-encoded hosts are properly decoded and checked against allowlists.

Monitor and restrict outbound requests from your application to internal IP ranges such as 127.0.0.1, 169.254.169.254, and RFC1918 addresses to prevent SSRF exploitation.

Review and tighten allowlist validation logic to decode percent-encoded hosts before validation to prevent bypass.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-47076. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart