CVE-2026-109682 in Metasploit Framework
Summary
by MITRE • 10/21/2026
Metasploit Framework versions before 6.5.7 allow HTTP requests made through send_request_cgi! to follow redirects to a different host without restricting the redirect destination. A malicious HTTP server can cause the system running Metasploit to make requests to arbitrary HTTP services reachable from the operator's network, including internal services that are not otherwise accessible to the attacker.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in versions of the Metasploit Framework prior to 6.5.7 stems from an insecure handling of HTTP redirects within the send_request_cgi! function. This core component is frequently utilized by penetration testers and security researchers to interact with web applications during assessment engagements. The flaw lies in the library's default behavior, which automatically follows HTTP redirect responses such as status codes 301 Moved Permanently or 302 Found without validating whether the new destination URL resides on the same origin as the initial request. This lack of strict host validation allows an attacker who controls a malicious web server to manipulate the redirection chain and force the Metasploit instance to issue subsequent requests to arbitrary hosts.
From a technical perspective, this behavior constitutes a classic Server-Side Request Forgery (SSRF) vulnerability. When the framework processes a redirect response, it does not enforce same-origin policies or restrict the destination IP addresses to those explicitly defined in safe lists. Consequently, if an operator interacts with a compromised or malicious web application that returns a crafted redirect header pointing to an internal network address, such as 127.0.0.1 or a private subnet range like 192.168.x.x, the Metasploit process will blindly follow this instruction. This mechanism effectively bypasses local firewall rules and access control lists that would normally prevent external entities from reaching these internal services directly.
The operational impact of this vulnerability is significant for organizations conducting security assessments using affected versions of Metasploit. An attacker with the ability to serve malicious content can leverage this flaw to probe the operator's network infrastructure, potentially discovering sensitive internal services such as database management interfaces, administrative panels, or IoT devices that are not exposed to the public internet. This capability transforms a standard web interaction into an attack vector for lateral movement and reconnaissance within the target environment. The risk is exacerbated in scenarios where Metasploit is run on systems with broad network access or when operators use default configurations without additional proxying or sandboxing measures.
This vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws resulting from insufficient validation of user-supplied URLs. Furthermore, it maps to the ATT&CK technique T1560.002, known as Archive via Cloud or External Services, although in this specific context, it is more accurately categorized under network reconnaissance and exploitation techniques that leverage SSRF for internal service discovery. The lack of strict destination validation allows the attacker to use the Metasploit framework itself as a proxy to reach otherwise inaccessible resources.
To mitigate this risk, organizations must upgrade immediately to Metasploit Framework version 6.5.7 or later, where developers have implemented stricter controls over redirect handling. Operators should also consider implementing network-level mitigations such as egress filtering rules that restrict outbound connections from the system running Metasploit to only necessary external endpoints. Additionally, using a dedicated proxy server with strict URL validation policies can provide an additional layer of defense by intercepting and inspecting HTTP traffic before it reaches the framework. Security teams should also review their operational procedures to ensure that sensitive internal services are not inadvertently exposed during penetration testing activities involving untrusted web content.