CVE-2026-48109 - MessagePack LZ4 decompression denial of service
MessagePack-CSharp’s optional LZ4 decompression path uses a deprecated fast
decompression routine that does not enforce a source-length bound. A crafted
compressed MessagePack payload can trigger out-of-bounds reads from the input
buffer, causing AccessViolationException and process termination during
deserialization. In some cases, limited unintended memory disclosure may happen
before the crash.
When to use it
- A .NET service resolves a vulnerable MessagePack-CSharp version directly or transitively.
MessagePackSerializerhandles untrusted or semi-trusted payloads withLz4BlockorLz4BlockArraycompression.- Payloads cross API, broker, cache, plugin, tenant, file, or agent/tool boundaries and are deserialized in-process.
- You need a bounded PR or triage note that upgrades MessagePack and records temporary LZ4 containment or worker isolation.
Inputs
- .NET project files, central package files, lockfiles, container files, SBOMs, generated dependency reports, and deployment manifests.
- Serializer options, compression settings, trusted/untrusted input inventory, worker isolation, crash supervision, and telemetry evidence.
- Available restore, build, unit/integration/serialization tests, static analysis, container build, SBOM, and dependency/security scan commands.
Affected versions
- Vulnerable package:
MessagePack <2.5.301 - Vulnerable package:
MessagePack >=3.0.214-rc.1,<3.1.7 - Fixed package:
2.5.301,3.1.7 - Affected feature:
Lz4BlockandLz4BlockArraycompression modes on untrusted inputs
Indicator-of-exposure
- The repository depends on vulnerable
MessagePackversions directly or transitively. - Code deserializes untrusted or semi-trusted payloads using
MessagePackSerializerwithLz4BlockorLz4BlockArray. - MessagePack payloads cross tenant boundaries, internet-facing APIs, brokers, caches, plugins, or agent/tool integrations.
- Deserialization happens in-process without crash isolation or worker restart supervision.
Quick checks:
rg -n "MessagePack|MessagePackSerializer|Lz4Block|Lz4BlockArray|WithCompression|Compression\\.|AccessViolationException" .
dotnet list package | rg "MessagePack"
rg -n "MessagePackCompression|SerializerOptions|Lz4" src test app services . 2>/dev/null
Windows:
rg -n "MessagePack|MessagePackSerializer|Lz4Block|Lz4BlockArray|WithCompression|Compression\\.|AccessViolationException" .
dotnet list package | rg "MessagePack"
rg -n "MessagePackCompression|SerializerOptions|Lz4" src test app services .
Do not run crafted memory-corruption proofs against production services and do not dump serialized customer payloads into logs or tests.
Remediation strategy
- Upgrade every controlled
MessagePackdependency to2.5.301+or3.1.7+. - If immediate upgrade is blocked, disable
Lz4BlockandLz4BlockArrayfor untrusted input paths and accept only uncompressed MessagePack or trusted producer traffic temporarily. - Isolate deserialization of untrusted compressed payloads in separate worker processes or containers with restart supervision where feasible.
- Re-scan broker consumers, API endpoints, cache bridges, and plugin interfaces for any code path that enables LZ4 compression on attacker-influenced data.
- Review crash telemetry for unexplained
AccessViolationExceptionor worker exits in MessagePack-consuming services.
The prompt
You are remediating CVE-2026-48109 / GHSA-hv8m-jj95-wg3x, a high-severity
MessagePack-CSharp LZ4 decompression issue that can crash the process on
crafted input. Produce exactly one output:
- A reviewer-ready PR/change request that upgrades MessagePack, hardens
untrusted deserialization paths, and documents operator actions, or
- TRIAGE.md if this repository does not control an affected MessagePack
dependency, compressed input path, image, or deployment.
## Rules
- Scope only CVE-2026-48109 and directly related MessagePack LZ4
deserialization paths.
- Treat serialized payloads, tenant data, cache contents, broker messages, and
crash dumps as sensitive.
- Do not create or run memory-corruption proofs against shared systems.
- Do not remove authentication, message integrity checks, or schema validation
as a shortcut.
- Do not auto-merge.
## Steps
1. Inventory every controlled `MessagePack` reference across project files,
lockfiles, container images, SBOMs, and generated dependency reports.
2. Determine every resolved version. Targets are vulnerable if they resolve to
`<2.5.301` or `>=3.0.214-rc.1,<3.1.7`.
3. Find all uses of `MessagePackSerializer` and identify where
`Lz4Block`/`Lz4BlockArray` compression is enabled.
4. Determine which inputs are untrusted or cross trust boundaries: public APIs,
queues, caches, brokers, plugins, files, agent messages, or tenant traffic.
5. If the repository does not control an affected dependency or runtime, stop
with `TRIAGE.md` listing checked files, external owner if known, and
required fixed versions `2.5.301` / `3.1.7`.
6. Upgrade all controlled MessagePack references to a fixed version compatible
with the project. Refresh lockfiles, images, SBOMs, generated reports, and
docs.
7. If any upgrade path is blocked, disable LZ4 compression for untrusted input
paths and document the temporary containment.
8. Add regression coverage that proves:
- vulnerable package versions are absent;
- untrusted paths no longer use vulnerable LZ4 decompression;
- trusted paths continue to work as expected;
- crash handling or worker isolation is in place where needed.
9. Add a PR body section named `CVE-2026-48109 operator actions` that states:
- MessagePack versions before and after;
- which LZ4-enabled paths were patched, disabled, or triaged;
- whether worker isolation or restart supervision was added;
- which validation commands passed.
10. Run available validation: dependency restore, unit/integration tests,
serialization tests, static analysis, container build, SBOM refresh, and
non-secret smoke checks.
11. Use PR title:
`fix(sec): remediate CVE-2026-48109 in MessagePack`.
## Stop conditions
- No affected MessagePack dependency, LZ4 input path, image, or deployment is
controlled by this repository.
- Safe verification would require crash testing shared systems with crafted
payloads.
- Upgrade requires a broader runtime migration outside scope.
- Validation fails for unrelated pre-existing reasons; document them instead of
broadening scope.
Verification - what the reviewer looks for
- No controlled build resolves vulnerable
MessagePackversions. - Untrusted input paths do not use the vulnerable LZ4 decompression mode.
- Regression coverage protects both package versioning and serializer options.
- Operator notes capture any temporary disablement of LZ4 or worker isolation.
Output contract
- Reviewer-ready PR upgrading all controlled MessagePack references to
2.5.301+or3.1.7+and refreshing lockfiles, images, SBOMs, and reports. - Evidence mapping LZ4-enabled deserialization paths to trust boundaries and showing untrusted paths are patched, disabled, or isolated.
- Safe tests for package versions and serializer options without crash payloads or sensitive serialized data.
TRIAGE.mdwhen no affected dependency, LZ4 input path, image, or deployment is controlled here.
Watch for
- Upgrading one project while another shared service or worker still uses the vulnerable package line.
- Leaving LZ4 enabled on public or tenant-crossing paths during a partial fix.
- Logging serialized payload bytes or crash dumps containing sensitive content.
- Assuming a process supervisor alone is an acceptable long-term fix.
Related recipes
References
- GitHub Advisory: https://github.com/advisories/GHSA-hv8m-jj95-wg3x
- Project release evidence: https://github.com/MessagePack-CSharp/MessagePack-CSharp/releases/tag/v3.1.7
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-48109