Netty netty-codec-socks CVE-2026-62380

Exploitation requires that attacker-controlled data reaches the domain address field (Socks4ClientEncoder or Socks5ClientEncoder) or the authentication username/password fields (Socks5ClientEncoder) of the Netty SOCKS client. This condition is met when an application accepts external user input - such as a proxy destination hostname or SOCKS credentials - and passes that input without prior sanitization into Netty's SOCKS encoder. The CVSS 4.0 AT:P attribute confirms that specific attack requirements (attacker field control) must be satisfied. Exploitation is limited to the SOCKS client path only; server-side Netty handlers and non-SOCKS codec modules are not affected. Applications that use hardcoded or internally-generated SOCKS destinations and credentials are not exploitable regardless of the Netty version. The CVSS PR:N indicates no authentication is required on the attacker's side to submit the malicious input, but the application must expose a pathway through which that input reaches the encoder.

The CVSS 4.0 base score of 6.3 reflects a moderate real-world risk profile: the AT:P attribute (attack requirements present) captures the critical limiting factor - exploitation depends on the attacker's ability to inject controlled values into the SOCKS domain or authentication fields of an application using Netty as a SOCKS client. This is not a default-configuration remote exploit; it requires a trust boundary where attacker-controlled data flows into the encoder, such as a web proxy or tunneling service that allows user-specified destinations. The impact metrics VC:N/VI:N/VA:N/SC:N/SI:L/SA:N confirm the damage is limited: no confidentiality loss, no availability impact, and only a low subsequent-system integrity effect - meaning the spoofed or injected data affects the SOCKS proxy's routing decisions, not the Netty host itself. EPSS data is not provided, and KEV status is negative, so there is no confirmed exploitation signal. The absence of a POC and the moderate exploitation complexity mean that, while the fix should be prioritized in the next maintenance cycle, this does not warrant emergency patching for most operators. Organizations running Netty-based SOCKS proxy gateway services where end-user input reaches the encoder should treat this with higher urgency than those using Netty for internal-only SOCKS tunneling with trusted inputs.

An attacker targets a Java application that accepts user-specified proxy destinations and uses Netty's SOCKS5 client encoder to connect through a corporate SOCKS proxy. By supplying a domain name containing an embedded CRLF sequence (e.g., legitimate.host\r\nevil.host), the attacker causes Socks5ClientEncoder to produce a malformed SOCKS5 CONNECT request, potentially redirecting the proxy connection to an attacker-controlled host while appearing to target the legitimate one. No public exploit code has been identified at time of analysis, so this scenario requires independent implementation by an attacker familiar with the SOCKS protocol wire format.