What is the CVSS score of CVE-2025-54539?

CVE-2025-54539 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 2.1%.

Which versions of ActiveMQ NMS AMQP are affected by CVE-2025-54539?

A critical remote code execution flaw in the ActiveMQ NMS AMQP .NET client (all releases through 2.3.0) allows a hostile or impersonated AMQP broker to run arbitrary code on any .NET application or…

How to fix or mitigate CVE-2025-54539?

Within 24 hours, inventory every application, service, and build pipeline that references the ActiveMQ NMS AMQP .NET client and determine whether any of them connect to brokers outside of fully trusted, internally controlled infrastructure; for any such connection, block or disable outbound AMQP access to untrusted endpoints until remediation completes, and if an emergency change window is available, upgrade the client to the vendor-released fix version 2.4.0 immediately. Within 7 days, complete the upgrade to 2.4.0 across all affected .NET applications (do not treat the 2.1.0 deserialization allow/deny-list as a compensating control, as it is bypassable), rebuild and redeploy dependent services, and verify in staging that client-broker sessions still function; engage the vendor to confirm the patch status, since the advisory feed used for this analysis lists no available patch while the technical detail identifies 2.4.0 as the vendor-released fix. Within 30 days, enforce broker trust boundaries as standing architecture - mutual TLS, broker certificate pinning, and network segmentation so clients only reach brokers we control - add dependency scanning to CI/CD to flag the NMS AMQP client below 2.4.0, and complete an assurance review confirming no residual instances of versions 2.3.0 and earlier remain in production or disaster-recovery environments.

ActiveMQ NMS AMQP CVE-2025-54539

CRITICAL

Deserialization of Untrusted Data (CWE-502)

2025-10-16 security@apache.org

RCE Apache Deserialization Microsoft .NET Activemq Nms Amqp

9.8

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

8.1 HIGH

Network client-side flaw, but attacker must control/impersonate the AMQP server the client connects to and defeat the allow/deny-list filter, so AC:H; no client privileges needed (PR:N); full RCE gives C/I/A High.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Metadata Corrected

Oct 09, 2026 - 10:40 vuln.today

tag: .NET added

Analysis Generated

Oct 09, 2026 - 10:39 vuln.today

CVE Published

Oct 16, 2025 - 09:15 cve.org

CRITICAL 9.8

DescriptionCVE.org

A Deserialization of Untrusted Data vulnerability exists in the Apache ActiveMQ NMS AMQP Client.

This issue affects all versions of Apache ActiveMQ NMS AMQP up to and including 2.3.0, when establishing connections to untrusted AMQP servers. Malicious servers could exploit unbounded deserialization logic present in the client to craft responses that may lead to arbitrary code execution on the client side.

Although version 2.1.0 introduced a mechanism to restrict deserialization via allow/deny lists, the protection was found to be bypassable under certain conditions.

In line with Microsoft’s deprecation of binary serialization in .NET 9, the project is evaluating the removal of .NET binary serialization support from the NMS API entirely in future releases.

Mitigation and Recommendations: Users are strongly encouraged to upgrade to version 2.4.0 or later, which resolves the issue. Additionally, projects depending on NMS-AMQP should migrate away from .NET binary serialization as part of a long-term hardening strategy.

AnalysisAI

Remote code execution in the ActiveMQ NMS AMQP .NET client affects all releases up to and including 2.3.0 when the client initiates an AMQP session to an attacker-controlled, compromised, or otherwise untrusted broker; that server can return crafted serialized data the client deserializes without bounds, potentially executing arbitrary code on the client host. The primary prerequisite is control or impersonation of the broker endpoint the client connects to, so deployments that only talk to trusted, internally controlled brokers are not realistically exploitable without first compromising that broker or the network path, and the allow/deny-list deserialization restriction added in 2.1.0 is bypassable so enabling it does not guarantee protection. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); EPSS is 2.09% (81st percentile) and the vendor-released fix is version 2.4.0.

Technical ContextAI

This is a CWE-502 deserialization-of-untrusted-data flaw rooted in the .NET binary serialization support that the Apache ActiveMQ NMS AMQP client exposes through the NMS API. When a client establishes an AMQP connection, server-supplied data is fed into the client's deserialization logic; because that logic is unbounded with respect to the .NET BinaryFormatter-class type graph, a malicious AMQP peer can return a crafted payload whose type resolution triggers code execution during object reconstruction on the client. AMQP itself is a broker-oriented messaging protocol, so the trust boundary here is inverted from the usual server-side case: the victim is the client and the adversary is the server endpoint. The 2.1.0 allow/deny-list mechanism was designed to constrain which types may be deserialized, but the advisory notes it can be bypassed under certain conditions, meaning the class-level root cause (type-driven deserialization in .NET binary serialization) is not fully mitigated by filtering alone. Vendor CPE cpe:2.3:a:apache:activemq_nms_amqp:*:*:*:*:*:*:*:* captures the wildcard version coverage; the project is also evaluating removal of .NET binary serialization from the NMS API entirely, in line with Microsoft's deprecation of binary serialization in .NET 9.

RemediationAI

Upgrade Apache ActiveMQ NMS AMQP to version 2.4.0 or later, which resolves the unbounded .NET binary deserialization behavior; the vendor advisory at https://lists.apache.org/thread/9k684j07ljrshy3hxwhj5m0xjmkz1g2n (mirrored at http://www.openwall.com/lists/oss-security/2025/10/15/3) should be reviewed for the full upgrade guidance. Because the allow/deny-list protection introduced in 2.1.0 is bypassable, do not rely on that filter alone as a mitigation. Where upgrading is not immediately possible, constrain the blast radius by ensuring NMS-AMQP clients connect only to trusted, internally controlled brokers - enforce outbound firewall and network segmentation rules so clients cannot reach arbitrary AMQP endpoints (trade-off: this breaks any legitimate broker-agnostic or federated messaging topology that depends on connecting to third-party brokers). Enable TLS with strict server certificate validation, and where feasible pin the expected broker certificate or hostname so an attacker cannot impersonate the endpoint through DNS or MITM positioning (trade-off: pinning adds certificate lifecycle management overhead and can cause outages on legitimate broker certificate rotation). As a longer-term hardening step, plan to migrate applications off .NET binary serialization in the NMS API, consistent with Microsoft's deprecation of binary serialization in .NET 9 and the Apache project's stated evaluation of removing that support in future releases.