Apache.NMS.ActiveMQ CVE-2026-103582

Exploitation requires the victim .NET application to receive a crafted OpenWire frame from a broker it connects to - concretely, the broker must be attacker-controlled or compromised, OR the attacker must be positioned to intercept and modify an unencrypted (non-TLS) OpenWire connection. The trigger is a frame whose declared length/count fields are oversized or negative and are not checked against the actual frame size by the unmarshaller. Limiting factors that reduce real-world risk: only the .NET OpenWire client (through the affected version) is impacted, not arbitrary network-adjacent hosts; connections secured with TLS defeat the MITM path; and the attacker effectively needs a trusted-broker relationship or interception position rather than mere network reachability. Impact is limited to client availability (memory exhaustion / crash); there is no confidentiality or integrity impact and no code execution.

This is a genuinely low-priority DoS, and the signals that are present support that rather than contradict it. No CVSS vector, EPSS score, or KEV entry is provided, and the vuln.today decision label is 'awaiting_data', so there is no quantitative exploitation signal to weigh. There is no public exploit reference in the input, so this is 'no public exploit identified at time of analysis'. The core reason this stays low is the threat model, not the bug class: the affected component is a client library, and the attacker must either control/compromise the broker the client connects to, or occupy a man-in-the-middle position on an unencrypted (non-TLS) connection. A client connecting to an attacker-controlled broker is an unusual trust posture, and MITM is defeated by the TLS that production deployments normally use. The impact is confined to availability of the client application (memory exhaustion, OutOfMemoryException, or an uncaught exception) with no confidentiality or integrity impact and no code execution. Note a data-consistency issue the consumer should verify with the vendor: the header line and 'Affected versions' say the Apache.NMS.OpenWire library 'through 2.2.0', while the body names package 'Apache.NMS.ActiveMQ' 'before 2.3.0' with the fix in 2.3.0 - the exact affected package and boundary version should be confirmed against the Apache advisory.

A .NET application using the Apache NMS ActiveMQ OpenWire client connects to a broker that is attacker-controlled or compromised (or an attacker intercepts an unencrypted OpenWire connection). The broker sends a crafted OpenWire frame declaring an oversized or negative length/count that the unmarshalling code trusts without validating against the actual frame size. The client attempts an enormous memory allocation, exhausting memory and crashing the client application. No public exploit code is identified in the available sources.