CVE-2026-32284

What it actually does

The msgpack decoder does not correctly verify that enough bytes remain in the input buffer before parsing truncated MessagePack fixext values using format codes 0xd4 through 0xd8. A remote, unauthenticated attacker who can supply MessagePack-encoded data to an application using the affected shamaton msgpack decoder can trigger an out-of-bounds read that results in a runtime panic. The primary impact is availability loss: the vulnerable process may crash or abort request handling, but the provided details do not indicate code execution, data disclosure, or data modification.

Why it matters to the business

Applications, APIs, message brokers, agents, or backend services that accept untrusted MessagePack input and use the affected shamaton msgpack decoder may be crashed with a small malformed payload, causing service interruption, failed transactions, degraded availability, and potential cascading failures in dependent systems. The CVSS score indicates high availability impact, but current public exploitation signals are low: EPSS is 0.00405, the 30-day trend is flat, there is no known CISA KEV listing, no ransomware association, and no reported mature exploit at this time. Risk is highest for internet-facing or multi-tenant services that decode MessagePack from unauthenticated clients.

How an attack unfolds

An attacker identifies an endpoint, protocol handler, queue consumer, RPC interface, or ingestion path that accepts MessagePack data and routes it to the affected shamaton msgpack decoder. The attacker sends a deliberately truncated fixext object using one of the vulnerable fixext format codes, 0xd4, 0xd5, 0xd6, 0xd7, or 0xd8, without providing the full type byte and payload length required by that format. Because the decoder fails to fully validate the remaining buffer length before reading, it attempts to access bytes beyond the available input. In runtimes that panic on invalid bounds access, this terminates the decode operation and may crash the process if the panic is not recovered. Repeating the request can keep the service unavailable or unstable. No authentication or user interaction is required when the vulnerable parser is reachable over the network.

How to fix it

Upgrade shamaton msgpack to a version that contains a fix once a patched release is available from the maintainer. No fixed version was provided in the input, so engineering teams should monitor the upstream package repository, release notes, advisories, and dependency security feeds for the first non-vulnerable version. Until a patch is available, reduce exposure by rejecting unauthenticated or untrusted MessagePack input where possible, enforcing strict request size and schema validation before decoding, wrapping decode operations with panic recovery or equivalent exception handling, applying rate limits to endpoints that parse MessagePack, isolating parser workloads so a crash does not terminate critical processes, and placing vulnerable services behind authentication or access controls. If the library is vendored, update the vendored copy after the upstream fix is released.

How to confirm the fix worked

Inventory codebases and dependency manifests for use of shamaton msgpack, including transitive and vendored copies. Confirm whether any externally reachable service decodes untrusted MessagePack data. After updating or mitigating, run dependency scanning to verify the vulnerable package version is no longer present. Perform a controlled negative test in a non-production environment by sending truncated fixext MessagePack payloads for format codes 0xd4 through 0xd8 and confirming the service returns a handled error rather than panicking or terminating. Review application logs and crash reports to ensure no new runtime panic, bounds error, or process restart occurs when malformed MessagePack input is received.

Typical attack path

1. Discover an application endpoint or service interface that accepts MessagePack-encoded input.
2. Confirm that malformed binary input is processed by a shamaton msgpack decoding path.
3. Craft a truncated fixext payload using MessagePack format code 0xd4, 0xd5, 0xd6, 0xd7, or 0xd8 with insufficient trailing bytes.
4. Send the malformed payload to the target over the exposed protocol, API, or message channel.
5. Trigger an out-of-bounds read and runtime panic in the decoder.
6. Repeat requests or deliver the payload through automated clients to cause sustained denial of service.

How to detect it

To assess whether this was already exploited, review application logs, process supervisor logs, container restart events, crash dumps, APM traces, and API gateway or load balancer logs for sudden panics or restarts correlated with requests carrying binary MessagePack payloads. Focus on services that deserialize MessagePack from external clients, queues, webhooks, RPC calls, or message streams. Look for runtime panic messages indicating index or slice bounds errors during MessagePack decoding, especially near references to fixext handling or shamaton msgpack. In network telemetry, search for repeated short binary requests containing MessagePack fixext type markers 0xd4, 0xd5, 0xd6, 0xd7, or 0xd8 followed by fewer bytes than required. Investigate patterns of repeated 5xx responses, connection resets, container restarts, or process exits immediately after malformed requests. Because no public exploit kit or actor-specific indicators are known from the provided data, detection should emphasize behavioral evidence of parser crashes and malformed MessagePack inputs rather than static attacker infrastructure.

• panic: runtime error: index out of range
• panic: runtime error: slice bounds out of range
• runtime error: index out of range
• runtime error: slice bounds out of range
• fixext
• msgpack
• MessagePack
• 0xd4
• 0xd5
• 0xd6
• 0xd7
• 0xd8
• shamaton msgpack

What your security team should do

• Prioritize remediation for internet-facing, unauthenticated, or high-availability services that accept MessagePack input.
• Ask engineering teams to identify direct, transitive, and vendored usage of shamaton msgpack across repositories and build artifacts.
• Monitor upstream advisories and upgrade immediately when a fixed shamaton msgpack version is released.
• Implement compensating controls now: input validation, rate limiting, authentication, panic recovery, and process supervision for services decoding MessagePack.
• Add detection for crash loops, runtime panics, and malformed MessagePack traffic involving fixext format codes 0xd4-0xd8.
• Review recent logs for unexplained process crashes or repeated malformed binary requests to MessagePack-consuming endpoints.
• Treat exploitation likelihood as currently low based on flat EPSS, no KEV listing, no ransomware association, and no known mature exploit, but do not defer fixes for exposed services because exploitation is simple and unauthenticated.