Read the docs
TI-2026-85007 Aliases CVE-2026-103582GHSA-cvrj-57gg-c399

Unbounded memory allocation in Apache NMS OpenWire client library

Priority LOW 22CWE-789Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
Denial of service
Confidentiality · integrity · availability
—
Fix status
No fix listed

No CVSS vector from any source. Fix status from CNA. Impact type from CWE-789.

Summary

Apache NMS ActiveMQ (the .NET OpenWire client, package Apache.NMS.ActiveMQ) through 2.2.0 is affected. The OpenWire unmarshalling code trusts frame size and length fields read from the network without enforcing a maximum frame size or checking that decoded lengths fit the frame (CWE-789). A malicious or compromised broker, or an attacker who can modify an unencrypted connection, can send a crafted frame with an oversized or negative length. This can cause very large memory allocations, an OutOfMemoryException or an uncaught exception, and a denial of service of the client application.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

Description from the CNA

Unbounded memory allocation and missing frame size validation in Apache NMS ActiveMQ (the .NET OpenWire client, package Apache.NMS.ActiveMQ) before 2.3.0. The OpenWire unmarshalling code trusted the frame size and the length and count fields read from the network. It did not enforce a maximum frame size, and it did not check that decoded lengths fit within the frame being read. A malicious or compromised broker, or an attacker able to intercept and modify an unencrypted connection, could send a crafted OpenWire frame with an oversized or negative length. This could cause the client to attempt very large memory allocations, leading to excessive memory consumption, an OutOfMemoryException or an uncaught exception, and a denial of service of the client application. Users are recommended to upgrade to version 2.3.0, which enforces a configurable maximum frame size and validates lengths against the size of the frame being read.

Why it matters now

EPSS 0.00216 12th percentileScored 2026-11-07
Fix No fix listed No fixed version in the sources yet

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
ApacheApache ActiveMQ NMS OpenWire Client Libraryup to 2.2.0—No fix listedCNA
  • Apache ActiveMQ NMS OpenWire Client Library VendorApache Affected up to 2.2.0 Fixed in — No fix listed CNA

Remediation

Upgrade Apache.NMS.ActiveMQ to version 2.3.0, which enforces a configurable maximum frame size and validates lengths against the size of the frame being read.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

Vendor assessments

Red Hat

Red Hat's page for this CVE →

Not affected: 1 product
  • Red Hat

Timeline

  1. 2026-11-04 Threatist record created from CVE-2026-103582
  2. 2026-11-04 Alias added: GHSA-cvrj-57gg-c399
  3. 2026-11-06 Affected versions changed · Red Hat
  4. 2026-11-06 CVSS score added · Red Hat

References

Advisory 1

  • TI-2025-18529 Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT KEVCVSS 3.1CRITICAL 10.0
  • TI-2024-30292 Apache OFBiz: Confused controller-view authorization logic (forced browsing) KEVCVSS 3.1CRITICAL 9.8
  • TI-2024-26062 Apache OFBiz: Unauthenticated endpoint could allow execution of screen rendering code KEVCVSS 3.1CRITICAL 9.8
  • TI-2024-21190 Apache OFBiz: Path traversal leading to RCE KEVCVSS 3.1CRITICAL 9.8
  • TI-2024-18186 Apache HugeGraph-Server: Command execution in gremlin KEVCVSS 3.1CRITICAL 9.8
  • TI-2023-25106 Deserialization of untrusted data in Apache ActiveMQ KEVCVSS 3.1CRITICAL 10.0
See all 4053 →

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences