CVE-2025-29953 - How Untrusted Data Deserialization in Apache ActiveMQ NMS OpenWire Client Puts You at Risk (And How to Fix It)

A major security flaw – CVE-2025-29953 – was found in Apache ActiveMQ NMS OpenWire Client that can let attackers run arbitrary code on your .NET systems. This happened when the client connects to a server it shouldn’t trust. The vulnerability stems from unsafe deserialization of data, a classic but dangerous bug category. Read on to understand how it works, how you might be at risk, and what you can do to secure your environment for good.

What’s the Problem?

The Apache ActiveMQ NMS OpenWire Client is a .NET library that lets your .NET apps talk to ActiveMQ servers. When using versions earlier than 2.1.1, client logic allowed potentially dangerous objects (sent from a server) to be deserialized *unsafely*.

Specifically

- If your client connects to a server you don’t fully trust—maybe a connection string typo, a compromised broker, or even a man-in-the-middle attack—the malicious server can send back a payload that forces your app to “rebuild” a .NET object from the binary they chose.

1. Deserialization is Dangerous

In .NET, BinaryFormatter (or similar) can recreate complex objects from binary data. If an attacker controls the data being deserialized, they can construct objects whose constructors or property setters do nasty things (like running shell commands).

2. The Bypass

Since version 2.1., the NMS OpenWire client had an allow/denylist to try to limit which classes could be loaded during deserialization. But researchers found that the feature could be bypassed, still letting attackers send payloads that produce unsafe object graphs.

Proof of Concept (PoC) Example

For demonstration, assume a malicious OpenWire broker sends a serialized binary payload that tries to exploit a .NET client.

using System.Runtime.Serialization.Formatters.Binary;
using System.IO;

// This would be part inside the OpenWire client code to handle server response
byte[] dataFromServer = GetPayloadFromUntrustedServer(); // simulated

var formatter = new BinaryFormatter();
using (var ms = new MemoryStream(dataFromServer))
{
    // The vulnerability: deserializing attacker-controlled data
    var obj = formatter.Deserialize(ms);
    // obj might be a dangerous type, triggering code execution
}

An attacker could craft dataFromServer so that it’s actually a binary payload that, when deserialized, runs their chosen code.

That broker is malicious or hijacked and sends a payload.

- Your app deserializes it, and any exploit code embedded in the object graph runs in the context of your app.
- This could mean reverse shells, ransoming, stealing credentials, or anything—*all under your user account*.

## Why Didn’t Allow/Denylist Stop It?

While v2.1. tried to help, certain .NET type graphs and serialization tricks could bypass these restrictions—classic “gadget chains” that rely on safe-looking classes that, when deserialized in a certain order, can be made to do bad things.

.NET’s Response – and Why You Should Care

The .NET team itself deprecated binary serialization starting in .NET 9 (announcement), because it’s just too risky in the modern world. You should never deserialize untrusted binary data, period.

Official References

- Apache ActiveMQ Security Advisory CVE-2025-29953
- ActiveMQ NMS OpenWire Client GitHub Repo
- .NET BinaryFormatter Deprecation Announcement

Upgrade to NMS OpenWire Client 2.1.1 or newer:

Get the release on Apache's download page.
2. Never connect to untrusted servers/brokers:

Stop using .NET binary serialization if possible:

Microsoft recommends switching to other serialization formats (JSON, protobuf, System.Text.Json, etc).

If you must handle binary data, only accept it from authenticated and authorized sources.

- Write fail-fast code: if your client gets a response from an unexpected broker, abort the connection.

Summary

CVE-2025-29953 is a high-risk issue in Apache ActiveMQ NMS OpenWire Client for .NET, making it possible for untrusted servers to execute code on your system due to unsafe binary deserialization. v2.1.1 fixes the flaw—upgrade right away and follow Microsoft’s lead in moving away from binary serialization for untrusted data sources.

Stay safe: Patch, harden, and watch your dependencies!

Timeline

Published on: 04/18/2025 16:15:22 UTC
Last modified on: 04/23/2025 16:15:47 UTC