Security readout for executives and security teams
Plain-English summary
A flaw in the Netty networking library lets a remote peer using SCTP quietly exhaust a server's memory and CPU by sending tiny message fragments that are never marked "complete." Each fragment stacks on the last, so the server builds an ever-growing chain of buffers until it slows or crashes. Any Java service using Netty's SCTP transport is at risk until it is upgraded.
Executive priority
Prioritize as a scheduled high-severity patch. It is not a drop-everything crisis because SCTP is not widely exposed, but any product using Netty's SCTP transport with untrusted peers should be upgraded within the standard high-severity SLA to avoid a remote denial-of-service capable of taking services offline.
Technical view
In netty-transport-sctp before 4.1.135.Final and 4.2.15.Final, the SCTP message handler wraps the running fragment accumulator with each new slice into a new CompositeByteBuf, creating an unbounded N-deep composite chain per streamIdentifier. There is no cap on fragment count, total bytes, or number of streams. A peer that withholds the complete flag causes readableBytes and getBytes to recurse per level, driving memory and CPU exhaustion (CWE-770).
Likely exposure
Exposure is limited to Java services that use Netty's SCTP transport (netty-transport-sctp) and accept SCTP connections from untrusted or semi-trusted peers. SCTP is uncommon in general web workloads but appears in telecom, signaling (Diameter, S1AP), and some clustering stacks. TCP/HTTP/2/QUIC users of Netty are not affected by this specific handler.
Exploitation context
No public evidence of active exploitation and the CVE is not listed in CISA KEV. CVSS 3.1 base is 7.5 (AV:N/AC:L/PR:N/UI:N, availability impact only), meaning it is network-reachable, unauthenticated, and low complexity. The vulnerability was disclosed via a GitHub Security Advisory (GHSA-5xrh-qmmq-w6ch) and tracked by Red Hat (RHSA-2026:37390, RHBZ#2488388).
Researcher notes
Root cause is unbounded nesting of CompositeByteBuf during SCTP fragment reassembly, keyed by streamIdentifier with no upper bound on N, total bytes, or stream count. Recursion depth on readableBytes/getBytes amplifies impact beyond simple memory growth. Impact is availability-only (CVSS C:N/I:N/A:H). Verify the fix limits fragment accumulation and enforces a ceiling; regression-test with slow-fragment SCTP peers that never set the complete flag.
Mitigation direction
- Upgrade netty-transport-sctp to 4.1.135.Final or 4.2.15.Final across all Java services.
- Apply Red Hat RHSA-2026:37390 on affected RHEL-based middleware and Netty-shipping products.
- Where upgrade is delayed, restrict SCTP ingress to trusted peers via firewall or SCTP association allowlists.
- Enforce connection, stream, and idle-time limits on SCTP endpoints to bound per-peer resource growth.
- Monitor JVM heap, direct memory, and GC pressure on SCTP-enabled services for early warning.
Validation and detection
- Inventory dependencies for io.netty:netty-transport-sctp and any transitive pulls below the fixed versions.
- Confirm resolved Netty version at runtime via build reports (mvn dependency:tree, gradle dependencies) and container SBOMs.
- Identify services that actually bind SCTP sockets; unused SCTP handlers reduce real exposure.
- After upgrade, redeploy and re-run dependency scans (Trivy, Grype, Snyk) to confirm the fixed release is loaded.
- Review logs and metrics for prior anomalous SCTP memory growth that could indicate opportunistic probing.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-770: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupCVE-2026-46340 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- High
- CVSS
- 7.5 (3.1)
- Known Exploited
- No
- Published
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
2 official scoresWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H3.93.6GitHub_MCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H3.93.6redhat-SADPVulnerability scoring details
Base CVSS 3.1 score
7.5HighVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Base CVSS 3.1 score
7.5HighVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- ADP timelineredhat-SADP
Made public.
- CVE publishedCVE Program
The CVE record was published.
- ADP timelineredhat-SADP
Reported to Red Hat.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
- 2026-06-12T15:01:34.090Z: Reported to Red Hat.
- 2026-06-12T14:19:48.855Z: Made public.
Source materials
- CVE List V5 sourceCVE List V5
- https://github.com/netty/netty/security/advisories/GHSA-5xrh-qmmq-w6chCVE reference, GitHub_M · x_refsource_CONFIRM
- https://github.com/netty/netty/releases/tag/netty-4.1.135.FinalCVE reference, GitHub_M · x_refsource_MISC
- https://github.com/netty/netty/releases/tag/netty-4.2.15.FinalCVE reference, GitHub_M · x_refsource_MISC
- https://access.redhat.com/security/cve/CVE-2026-46340CVE reference, redhat-SADP · vdb-entry, x_refsource_REDHAT
- RHBZ#2488388CVE reference, redhat-SADP · issue-tracking, x_refsource_REDHAT
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46340.jsonCVE reference, redhat-SADP · x_sadp-csaf-vex
- https://access.redhat.com/errata/RHSA-2026:37390CVE reference, redhat-SADP · vendor-advisory, x_refsource_REDHAT
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Allocation of Resources Without Limits or Throttling
Allocation of Resources Without Limits or Throttling represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.