---
id: "CVE-2026-103582"
kind: "vulnerability"
aliases: ["CVE-2026-103582"]
title: "Apache NMS ActiveMQ .NET client: crafted frame crashes client with memory exhaustion"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["activemq", "dotnet", "nuget", "openwire", "package"]
not_affected_if: ["no-openwire-connection", "not-using-apache-nms"]
published_at: "2026-11-04T11:17:13+00:00"
first_seen_at: "2026-11-04T11:26:45+00:00"
updated_at: "2026-11-04T11:27:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-103582", "first_seen_at": "2026-11-04T11:26:45+00:00"}]
---

# Apache NMS ActiveMQ .NET client: crafted frame crashes client with memory exhaustion

The .NET OpenWire client (Apache.NMS.ActiveMQ) before 2.3.0 trusts frame size and length fields from the network without bounds checks. A malicious broker or an attacker who can modify an unencrypted connection can send a crafted frame that forces huge allocations, causing a denial of service of the client application.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed version of the `Apache.NMS.ActiveMQ` package in the project's NuGet references (`dotnet list package`).
- Look for any `Apache.NMS.ActiveMQ` version below `2.3.0`.

## Fix

- Apache.NMS.ActiveMQ: upgrade to `2.3.0` or later, which enforces a configurable maximum frame size and validates lengths against the frame being read.

## Timeline

- 2026-11-04T11:26:45+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-103582

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_