Skip to main content

Netty EUVDEUVD-2026-36465

| CVE-2026-50010 HIGH
Improper Verification of Cryptographic Signature (CWE-347)
2026-06-12 GitHub_M GHSA-c653-97m9-rcg9
7.5
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Identify Netty-based TLS client using plain X509TrustManager
  2. Delivery
    Gain man-in-the-middle position on network path
  3. Exploit
    Present certificate for unrelated hostname
  4. Execution
    Netty skips endpoint identification and accepts handshake
  5. Persist
    Proxy and decrypt session traffic
  6. Impact
    Harvest credentials or tamper with payloads

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
Exploitation Conditions

The application must build its TLS client with Netty's SslContextBuilder.forClient().trustManager(...) and pass a plain javax.net.ssl.X509TrustManager (not an X509ExtendedTrustManager), which causes Netty to wrap it in the buggy X509TrustManagerWrapper; clients using the default JDK trust manager or supplying an X509ExtendedTrustManager are unaffected. The attacker additionally needs an active man-in-the-middle position on the network path between the Netty client and its intended server, plus any certificate trusted by that client's truststore for a non-matching hostname (e.g. an attacker-controlled cert signed by any CA in the truststore, a misissued cert, or a stolen valid cert for a different domain). No authentication or user interaction is required on the Netty side, and the bug affects all pre-4.1.135.Final and pre-4.2.15.Final versions on every supported JDK and OS - the limiting factor is the trust-manager configuration, not the platform.

Impact

Signals are mixed: the CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N and a 7.5 base score align with a remote-network confidentiality break, but exploitation realistically requires an active man-in-the-middle position, which the CVSS vector flattens into AC:L. EPSS is only 0.04% (13th percentile) and the flaw is not on the CISA KEV, consistent with a configuration-dependent cryptographic weakness that is hard to mass-scan for rather than a remotely triggerable RCE. Note the I:N rating is questionable - if hostname verification is bypassed, an attacker who intercepts and re-signs traffic can also modify it, so integrity impact is arguably High; the I:N classification appears to assume passive eavesdropping only. Priority should be driven by exposure: Netty-based clients talking to untrusted networks (mobile apps, edge agents, cross-DC links) are clearly affected, while pure server-side Netty deployments that never call trustManager() with a plain X509TrustManager are not.

Exploit ScenarioDerived

An attacker on a coffee-shop Wi-Fi, a compromised upstream router, or a hostile transit network intercepts TLS traffic from a Netty-based client (e.g. a mobile backend agent, a microservice's outbound HTTPS call, or a Kafka/Redis client) and presents a certificate that chains to a trusted CA but bears an unrelated hostname. Because the patched-against bug leaves endpoint identification off, the Netty client accepts the certificate, completes the handshake, and the attacker proxies the connection to the real server while reading and rewriting plaintext credentials, tokens or RPC payloads in transit. No public exploit is needed - any off-the-shelf MITM tool (mitmproxy, bettercap) with a misissued or attacker-controlled CA-signed certificate is sufficient.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 12, 2026

TLS hostname verification is silently disabled in Netty's netty-handler module for any client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager), allowing network attackers in a man-in-the-middle position to present a valid certificate for any host and intercept supposedly encrypted traffic. Affects all Netty versions prior to 4.1.135.Final and 4.2.15.Final; no public exploit identified at time of analysis and EPSS is very low (0.04%), but the defect bypasses a core TLS protection that Netty 4.2 explicitly advertises as enabled by default.

RemediationAI

Vendor-released patch: upgrade io.netty:netty-handler (and the rest of the Netty BOM) to 4.1.135.Final or 4.2.15.Final per the release notes at https://github.com/netty/netty/releases/tag/netty-4.1.135.Final and https://github.com/netty/netty/releases/tag/netty-4.2.15.Final and the advisory at https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9. Until you can upgrade, the most reliable workaround is to stop passing a plain X509TrustManager to SslContextBuilder - instead supply an X509ExtendedTrustManager (e.g. obtain it from a TrustManagerFactory.getInstance("PKIX") initialised with your KeyStore) so the JDK's own endpoint-identification wrapping kicks in. As a secondary control, explicitly invoke SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") on the SSLEngine you obtain from Netty and verify hostnames in application code, accepting the trade-off of duplicated verification logic if you later upgrade. Avoid the tempting shortcut of removing the custom trust manager entirely, since that re-enables full JDK truststore validation but may break pinning use cases.

Affected VersionsENISA

netty 4.2.0.Final, < 4.2.15.Final
netty < 4.1.135.Final

Affected Packages

maven io.netty:netty-handler fix: 4.1.135.Final, 4.2.15.Final
euvd netty fix: 4.1.135.Final
euvd netty_4_2_0_final fix: 4.2.15.Final

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 3 packages in maven, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Netty's SimpleTrustManagerFactory.engineGetTrustManagers() routes a user-supplied plain X509TrustManager through X509TrustManagerWrapper, which extends X509ExtendedTrustManager but stubs the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and delegating to the 2-arg form. Because the wrapped object is already an X509ExtendedTrustManager, the JDK's SunJSSE AbstractTrustManagerWrapper and Netty's own OpenSslX509TrustManagerWrapper both skip the re-wrap step that normally injects endpoint identification logic, so the endpointIdentificationAlgorithm="HTTPS" setting that Netty 4.2 turns on by default never actually runs. The root cause maps to CWE-347 (improper verification of cryptographic signature/identity) because the certificate chain is validated for trust but the peer hostname is never checked against the SAN/CN, defeating the binding between trust anchor and endpoint identity. Affected CPE is cpe:2.3:a:netty:netty:*:*:*:*:*:*:*:* across all pre-fix releases used by HTTP, gRPC, Redis, Kafka and many other JVM TLS clients.

Know when Netty gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
vuln.today AI 7.4 HIGH

Network vector; AC:H because exploitation requires an active MITM position and a vulnerable trustManager configuration; PR:N/UI:N on the client side; C:H and I:H because hostname-bypass MITM enables both eavesdropping and tampering.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE HIGH
Red Hat 7.5 HIGH

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

2
Patch available
Jun 12, 2026 - 17:01 EUVD
CVE Published
Jun 12, 2026 - 14:50 cve.org
HIGH 7.5

DescriptionCVE.org

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue.

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 686 maven packages depend on io.netty:netty-handler (317 direct, 369 indirect)

Ecosystem-wide dependent count for version 4.2.0.Final.

Executive ViewAI

Why It Matters

Netty versions before 4.1.135.Final and 4.2.15.Final silently disable TLS hostname verification when applications use custom trust managers, exposing encrypted communications to man-in-the-middle attacks. This vulnerability directly compromises the encryption protections that applications depend upon to secure sensitive data in transit. While no public exploitation has been detected, any organization using affected Netty versions requires immediate patching to restore proper TLS security.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.0%
Top 87% exploitable
Threat Intel
1
1 source
Data Quality
8 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

More in Netty

View all
CVE-2023-44487 HIGH POC
7.5 Oct 10

Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour

CVE-2019-16869 HIGH POC
7.5 Sep 26

Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding : chunked

CVE-2026-56820 CRITICAL POC
9.1 Jul 21

Certificate revocation-check bypass in the Netty network framework's OCSP client (io.netty:netty-handler-ssl-ocsp) affec

CVE-2024-36121 CRITICAL POC
9.1 Jun 04

netty-incubator-codec-ohttp is the OHTTP implementation for netty. Rated critical severity (CVSS 9.1), this vulnerabilit

CVE-2024-40642 HIGH POC
8.1 Jul 18

The netty incubator codec.bhttp is a java language binary http parser. Rated high severity (CVSS 8.1), this vulnerabilit

CVE-2025-24970 HIGH POC
7.5 Feb 10

Netty, an asynchronous, event-driven network application framework, has a vulnerability starting in version 4.1.91.Final

CVE-2026-59902 HIGH POC
7.5 Aug 17

Memory exhaustion in Netty's SctpMessageCompletionHandler (netty-transport-sctp) allows unauthenticated remote peers to

CVE-2026-55833 HIGH POC
7.5 Jul 20

Compression-amplification denial of service in the Netty network framework (versions prior to 4.1.136.Final and 4.2.16.F

CVE-2026-55831 HIGH POC
7.5 Jul 20

Memory-amplification denial of service in the Netty network framework (SPDY/3.1 codec) prior to 4.1.136.Final and 4.2.16

CVE-2026-56816 HIGH POC
7.5 Jul 21

Memory-exhaustion denial of service in Netty's HTTP/3 codec (Http3FrameCodec) affects all releases prior to 4.2.16.Final

CVE-2026-59903 HIGH POC
7.5 Aug 17

Netty's HTTP CORS handler silently rewrites the Vary response header to Vary: Origin in releases before 4.1.137.Final an

CVE-2026-48748 HIGH POC
7.5 Jun 12

Denial of service in the Netty HTTP/3 codec (io.netty:netty-codec-http3) prior to version 4.2.15.Final allows remote una

Vendor StatusVendor

SUSE

Severity: Important
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise High Performance Computing 15 SP4-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS Affected

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-50010 ADVISORY https://vuldb.com/vuln/370618 REF https://access.redhat.com/errata/RHSA-2026:26017 REF https://access.redhat.com/errata/RHSA-2026:26018 REF https://access.redhat.com/errata/RHSA-2026:26586 REF https://access.redhat.com/errata/RHSA-2026:28573 REF https://access.redhat.com/errata/RHSA-2026:34608 REF https://access.redhat.com/errata/RHSA-2026:37390 REF https://access.redhat.com/errata/RHSA-2026:41951 REF https://access.redhat.com/errata/RHSA-2026:48151 REF https://access.redhat.com/errata/RHSA-2026:49700 REF https://access.redhat.com/errata/RHSA-2026:49701 REF https://access.redhat.com/errata/RHSA-2026:50085 REF https://access.redhat.com/errata/RHSA-2026:53644 REF https://access.redhat.com/errata/RHSA-2026:53645 REF https://access.redhat.com/errata/RHSA-2026:53646 REF https://access.redhat.com/errata/RHSA-2026:53806 REF https://access.redhat.com/errata/RHSA-2026:62260 REF https://access.redhat.com/errata/RHSA-2026:65126 REF https://access.redhat.com/errata/RHSA-2026:66488 REF https://access.redhat.com/errata/RHSA-2026:66545 REF https://access.redhat.com/security/cve/CVE-2026-50010 REF https://bugzilla.redhat.com/show_bug.cgi?id=2488429 REF https://github.com/netty/netty/releases/tag/netty-4.1.135.Final REF https://github.com/netty/netty/releases/tag/netty-4.2.15.Final REF https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9 REF https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-50010.json

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy