{"id":"ECHO-f62c-6c16-552e","upstream":["CVE-2026-62243","GHSA-c3j3-64rf-grvf"],"severity":[],"modified":"2026-11-04T16:52:57.929Z","affected":[{"package":{"ecosystem":"Echo:Maven","name":"io.netty:netty-handler","purl":"pkg:maven/io.netty/netty-handler"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.1.74.Final+echo.4"}]}]}],"references":[{"type":"WEB","url":"https://advisory.echohq.com/cve/CVE-2026-62243"},{"type":"WEB","url":"https://github.com/netty/netty/security/advisories/GHSA-p85m-gvr3-788c"},{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-62243"},{"type":"WEB","url":"https://www.vulncheck.com/advisories/netty-through-tls-hostname-verification-bypass"},{"type":"WEB","url":"https://github.com/advisories/GHSA-c3j3-64rf-grvf"}],"withdrawn":"2026-11-04T16:52:57.929Z","summary":"GHSA-p85m-gvr3-788c: hostname verification skipped on the OpenSSL client path with a plain\nX509TrustManager when trust-manager wrapping is unavailable (Java 25+). Upstream's fix\n(in https://github.com/netty/netty/commit/9e05192391, 4.1.137.Final) only adds a check at\ncontext creation for an endpoint identification algorithm set with\nSslContextBuilder.endpointIdentificationAlgorithm(...), which netty added in 4.1.112.Final\n(0deca94aa1); 4.1.74.Final has no such setting. The other way to ask for hostname\nverification, SSLParameters on the engine, is the same in 4.1.74.Final and in fixed\n4.1.137.Final (it sets SSL_CVERIFY_REQUIRED and leaves the check to the trust manager), and\nthe fix does not change it. CVE-2026-50010, patched above, covers wrapping plain trust managers.\n"}