CVE-2026-62380 is a high severity (CVSS 7.5) input validation flaw in Netty's netty-codec-socks module. The SOCKS4 and SOCKS5 client encoders accept null bytes and CRLF in address and credential fields, so values can be truncated or altered. Upgrade to 4.2.17.Final or 4.1.137.Final.
What's affected
The record and the GitHub advisory (GHSA-cc6x-ffm5-83wf) agree on the affected set: io.netty:netty-codec-socks from 4.2.0.Final through 4.2.16.Final, and 4.1.x through 4.1.136.Final. Patched releases are 4.2.17.Final and 4.1.137.Final.
The weakness is CWE-626 (null byte interaction error). Socks4ClientEncoder and Socks5ClientEncoder do not validate the domain address or the username and password fields. An attacker who controls those values can truncate or alter them, which the advisory ties to domain spoofing, SOCKS4 user id truncation, authentication data injection and protocol confusion.
Source conflict on severity and versions. The record and the GitHub advisory say High, 7.5 on CVSS 3.1. The VulnCheck advisory rates it medium with a 6.3 score on CVSS 4.0, and its page title says versions before 4.2.16.Final while its text says through 4.2.16 with the fix in 4.2.17.Final. Follow the GitHub advisory for versions: 4.2.17.Final and 4.1.137.Final.
How to check if you're exposed
Netty is usually a transitive dependency, so check the resolved version rather than only your declared one.
mvn dependency:tree -Dincludes=io.netty:netty-codec-socks
./gradlew dependencies --configuration runtimeClasspath | grep netty-codec-socks
If the output shows a version below 4.1.137.Final on the 4.1 line or below 4.2.17.Final on the 4.2 line, you are on an affected release. Check container images and fat jars too, since a shaded copy will not show up in the dependency tree. The free in-browser dependency scan at gold.safeguard.sh/scan can list the matching dependencies in a manifest or lockfile you paste in.
What to do now
- Find every service that depends on netty-codec-socks, directly or through a client library such as an HTTP or database driver.
- Raise the Netty version to 4.2.17.Final or 4.1.137.Final, or to the Netty BOM that includes them, and rebuild.
- Validate any host name, user name or password that your code passes into a SOCKS proxy client. Reject null bytes and line breaks before they reach the encoder.
- Redeploy and confirm the new version in the running artifact, not only in source.
- Add a dependency check to CI so a transitive downgrade of Netty is caught.
Why it matters
A null byte ends a string in many protocols. If one layer treats it as data and another treats it as the end, the two layers disagree about what was sent. That gap is how a proxy can be told to connect to one host while a check saw another, or how credentials can be cut short or extended.
The flaw only matters where an attacker can influence the address or credential fields passed to a SOCKS client. Applications that use fixed proxy settings are less exposed, but a library you did not write may build those values from user input. The record does not mark this CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does my application have to act as a SOCKS server to be affected?
No. The affected code is the client encoder. The risk is in applications or libraries that send SOCKS requests using values an attacker can influence.
Sources
Last reviewed: 18 October 2026.
