CVE-2026-102722 in NetX Duo
Summary
by MITRE • 09/29/2026
In the IPv4 PASV path, the FTP Client accepts whatever address was sent in the server's `227` reply. Validation only covers the parse and the non-zero values, thus a malicious server can name any address and direct the Client there.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability described involves a critical flaw in the implementation of the File Transfer Protocol passive mode within an IPv4 environment. FTP operates using two separate TCP connections: one for control commands and another for data transfer. In active mode, the client specifies its own IP address and port to which the server will connect. However, due to firewall restrictions often present on modern networks, passive mode was introduced as a more accessible alternative. In this configuration, the server provides an IP address and port number in response to the PASV command via the 227 reply code. The client is then responsible for initiating the data connection to that specified endpoint. This design inherently trusts the server's provided network information, creating a potential attack vector if validation mechanisms are insufficient.
The core technical flaw lies in the lack of strict address verification by the FTP client software. Upon receiving the 227 reply containing an IP address and port number, the client performs only basic syntactic checks to ensure the string can be parsed correctly and that the values are non-zero integers. It fails to validate whether the provided IP address belongs to a legitimate range or matches expected network boundaries. This absence of semantic validation allows a malicious FTP server to inject arbitrary IP addresses into the 227 response, effectively hijacking the client's data connection initiation process. The client blindly accepts this input and attempts to establish a TCP connection to the attacker-controlled destination without any sanity checks regarding address legitimacy or scope.
This vulnerability enables several severe operational impacts for users of the affected FTP client software. Most notably, it facilitates Server-Side Request Forgery attacks where an attacker can force the vulnerable client to make network connections to internal resources that are not directly accessible from the internet but may be reachable by the server hosting the malicious FTP service. This is particularly dangerous in enterprise environments where internal services might rely on implicit trust based on source IP addresses or lack additional authentication mechanisms for specific ports. Additionally, attackers can use this flaw for port scanning purposes against internal networks by observing connection attempts and error responses from the client system. It also opens avenues for phishing attacks if the attacker controls a domain that resolves to an address they wish to direct traffic toward, although the primary risk remains network reconnaissance and unauthorized access to backend services.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the application fails to verify whether user-controllable input meets expected criteria before processing it. Specifically, it relates to CWE-918 Server-Side Request Forgery since the vulnerability allows an external actor to induce the server-side component (the FTP client acting on behalf of a potentially compromised or misconfigured network segment) to make requests to arbitrary destinations. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1046 Network Service Discovery, as it can be used for internal port scanning and service enumeration within private networks that are otherwise isolated from direct external access.
Mitigation strategies must focus on implementing robust input validation at the application layer. Developers should enforce strict checks on IP addresses received in FTP control responses, ensuring they fall within expected ranges such as RFC 1918 private address spaces if internal connectivity is intended, or rejecting loopback and link-local addresses unless explicitly required by specific use cases. Implementing a whitelist of allowed destination IPs for data connections can significantly reduce the attack surface. Furthermore, network-level controls should be employed to restrict outbound FTP data connections from originating hosts to only those destinations that are authorized. Users affected by this vulnerability should consider upgrading to patched versions of their FTP client software if available or switching to more secure protocols like SFTP or SCP which do not suffer from this specific passive mode trust model flaw, thereby eliminating the risk associated with untrusted server-provided connection endpoints.