CVE-2026-48515: MessagePack C# Denial of Service via Heap Allocation Attack

Technical summary

The vulnerability exists in MessagePack-CSharp's multi-dimensional array formatters (T[,], T[,,], T[,,,]). During deserialization, the code path reads dimension lengths from the incoming payload and immediately allocates the target array using those dimensions before validating that the total element count (product of all dimensions) matches the guarded element array header present in the serialized stream. This allows an attacker to specify dimensions whose product far exceeds the declared element count, resulting in oversized heap allocation. The element data validation occurs after allocation, not before, leaving a window for memory exhaustion attacks.

Business impact

Applications using MessagePack for C# to deserialize untrusted data are vulnerable to denial-of-service attacks. A remote attacker can send crafted serialized messages that cause the application to allocate gigabytes of memory with minimal network overhead, resulting in service unavailability, crashes, or resource starvation that impacts legitimate users. This is particularly concerning in microservices architectures and message-driven systems where MessagePack is used for inter-service communication or API payload deserialization.

Affected systems

MessagePack for C# (messagepack/messagepack) versions prior to 2.5.301 and 3.1.7 are affected. Organizations should identify all applications and services using MessagePack for C# and verify their current versions. Development teams, CI/CD pipelines, and package management systems should be audited to ensure no older versions are locked in dependencies.

Exploitability

Exploitation requires no authentication, user interaction, or special privileges. An attacker only needs to send a specially crafted MessagePack-serialized message to a system that deserializes untrusted input. The network attack surface is low-complexity, and the payload is trivial to generate. However, practical exploitation depends on the application accepting and deserializing MessagePack data from external or semi-trusted sources. Internal-only message flows with restricted sender access face lower risk.

Remediation

Upgrade MessagePack for C# to version 2.5.301 or later for the 2.x line, or to version 3.1.7 or later for the 3.x line. These versions validate dimension products against the element count before allocating the multi-dimensional array, eliminating the oversized allocation window. Verify the upgrade in a development environment before rolling out to production.

Patch guidance

Update your NuGet package reference for MessagePack (https://www.nuget.org/packages/MessagePack) to 2.5.301 or 3.1.7 or newer. Run 'dotnet package update MessagePack' or update the version in your .csproj file and restore packages. Test deserialization of trusted and untrusted message streams to confirm no regressions in your application. If you maintain a private package mirror, ensure it is refreshed with the patched versions before developers pull updates.

Detection guidance

Monitor for sudden spikes in heap memory consumption or out-of-memory exceptions in applications using MessagePack, especially following unexpected network traffic. Log and inspect any deserialization exceptions tied to multi-dimensional array types (Jagged or rectangular arrays). In network logs, look for small payloads with large dimension declarations in MessagePack format (byte patterns indicating high-dimension metadata followed by minimal data). Application performance monitoring (APM) tools can alert on unusual memory growth rates during message processing.

Why prioritize this

This vulnerability merits rapid prioritization because it is unauthenticated, remotely exploitable, and requires no user interaction. The attack surface is broad for any service accepting MessagePack input, and the impact—service unavailability—is operationally severe. Although not yet listed in CISA's Known Exploited Vulnerabilities catalog at the time of publication, the ease of exploitation and the HIGH CVSS score (7.5) make early patching critical to prevent reactive incident response.

Risk score, explained

The CVSS v3.1 score of 7.5 (HIGH) reflects the combination of a network-accessible attack vector with no privilege or user interaction requirements and a direct availability impact (denial of service via memory exhaustion). Confidentiality and integrity are not affected, which prevents a CRITICAL rating, but the total lack of required authentication and the trivial attack complexity make this a significant operational risk that justifies immediate attention.

Frequently asked questions