What is the CVSS score of CVE-2026-33524?

CVE-2026-33524 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Which versions of Eclipse zserio are affected by CVE-2026-33524?

CVE-2026-33524 is a critical remote denial-of-service vulnerability in the Eclipse zserio serialization framework affecting Navigation Data Standard implementations deployed across 40+ automotive…. A patch is available.

How to fix or mitigate CVE-2026-33524?

Within 24 hours: Identify all internal and customer-facing systems using Eclipse zserio and map affected automotive platforms (NDS implementations). Within 7 days: Prioritize deployment of zserio v2.18.1 patch across all C++ and Java runtime environments; coordinate with automotive OEM customers for urgent updates. Within 30 days: Verify patch deployment completion across all affected systems; establish monitoring for malformed serialization payloads at network ingress points.

Eclipse zserio CVE-2026-33524

EUVD-2026-25591 HIGH

Memory Allocation with Excessive Size Value (CWE-789)

2026-04-24 https://github.com/ndsev/zserio

GHSA-cwq5-8pvq-j65j

Docker Java Denial Of Service

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Re-analysis Queued

Apr 24, 2026 - 19:22 vuln.today

cvss_changed

Analysis Generated

Apr 24, 2026 - 17:00 vuln.today

EUVD ID Assigned

Apr 24, 2026 - 16:30 euvd

EUVD-2026-25591

Analysis Generated

Apr 24, 2026 - 16:30 vuln.today

Patch released

Apr 24, 2026 - 16:30 nvd

Patch available

CVE Published

Apr 24, 2026 - 16:25 nvd

HIGH 7.5

DescriptionGitHub Advisory

Summary

Unbounded Memory Allocation (all platforms)

A crafted payload as small as 4-5 bytes can force memory allocations of up to 16 GB, crashing any process with an OOM error (Denial of Service).

Affected code (C++):

cpp/runtime/src/zserio/Array.h (line 1029) - m_rawArray.reserve(readLength) with unchecked readLength
cpp/runtime/src/zserio/BitStreamReader.h (lines 249, 281) - value.reserve(len) with unchecked len

Affected code (Java):

java/runtime/src/zserio/runtime/array/Array.java (line 271) - rawArray.reset(readSize) → new int[readSize]
java/runtime/src/zserio/runtime/io/ByteArrayBitStreamReader.java (line 245) - new byte[length]

Proof of Concept

Memory Allocation DoS (verified on 64-bit)

Payload	Claimed Size	Allocated	Amplification
4 bytes	100,000,000	762 MB	~200 million x
5 bytes	2,147,483,647	~16 GB	system crash

The full PoC source code and Docker build files are available upon request.

Impact

zserio is the serialization framework underlying the NDS (Navigation Data Standard), used by 43 member companies including Toyota, BMW, Volkswagen, Mercedes-Benz, and others. According to the Eclipse zserio project:

> "Zserio serialized data is used in millions of deployments in cars on the road"

Attack vectors include NDS.Live cloud map updates, map data supply chain compromise, and backend data processing pipelines. On 32-bit automotive ECUs, this could affect ADAS functionality.

Suggested Fix

For all runtimes: Validate varsize against stream size

if (claimedSize > remainingBytesInStream) {
    throw error("varsize claims more data than available in stream");
}

Disclosure Timeline

2026-03-08: Reported to Woven by Toyota PSIRT (go-zserio)
2026-03-10: Reported to ndsev/zserio maintainers via GitHub Security Advisory
2026-03-23: Split off overflow vulnerability to own report
90-day coordinated disclosure timeline

A patch for this issue is available at https://github.com/ndsev/zserio/releases/tag/v2.18.1.

Reporter

Ryuji Yasukochi (ryuji.yasu@gmail.com)

AnalysisAI

Unbounded memory allocation in Eclipse zserio serialization framework allows remote attackers to trigger system crashes via crafted payloads as small as 4-5 bytes, forcing allocations up to 16 GB and causing out-of-memory errors. Affects both C++ and Java runtimes used in Navigation Data Standard (NDS) implementations deployed across millions of vehicles from Toyota, BMW, Volkswagen, Mercedes-Benz, and 39 other automotive manufacturers. Vendor-released patch available in zserio v2.18.1, addressing unchecked length parameters in Array.h, BitStreamReader.h, and Java runtime equivalents. CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) indicates trivial remote exploitation without authentication.

Technical ContextAI

Eclipse zserio is a serialization framework implementing variable-length integer encoding (varsize) for compact binary representation. The vulnerability exists in the deserialization logic where length fields read from untrusted input streams directly drive memory allocation calls without validation against remaining stream data. In C++ runtime (Array.h line 1029, BitStreamReader.h lines 249/281), vector::reserve() is called with unchecked readLength/len values. In Java runtime (Array.java line 271, ByteArrayBitStreamReader.java line 245), new int[readSize] and new byte[length] are allocated based on attacker-controlled fields. This is a classic CWE-789 (Memory Allocation with Excessive Size Value) issue where the serialization protocol's claimed size is trusted without verifying sufficient backing data exists. The pkg:maven/io.github.ndsev:zserio-runtime artifact is affected across both language implementations. The framework is foundational to NDS (Navigation Data Standard) used for automotive map data serialization, making this a supply-chain issue affecting vehicle infotainment, ADAS, and navigation systems.

RemediationAI

Upgrade to Eclipse zserio v2.18.1 or later, which implements validation of claimed varsize values against actual remaining stream data before memory allocation. Patch commit a9932de4b5eefb3afd5e18ca2fd758aa744a7c69 adds bounds checking: if (claimedSize > remainingBytesInStream) throw error. Download from https://github.com/ndsev/zserio/releases/tag/v2.18.1. For automotive OEMs with extended integration timelines, implement compensating controls at network perimeter: (1) enforce maximum message size limits (e.g., 10 MB) on NDS.Live cloud-to-vehicle update channels before deserialization, blocking oversized allocations at ingress - trade-off is rejecting legitimate large map tiles if limit set too low; (2) isolate zserio deserialization in memory-limited containers/cgroups with OOM kill policies that prevent cascading system crashes - trade-off is service degradation instead of graceful error handling; (3) implement supply-chain verification (code signing, hash validation) on map data sources to prevent malicious payload injection - does not prevent exploitation of signed-but-crafted data from compromised suppliers. Advisory references: https://github.com/ndsev/zserio/security/advisories/GHSA-cwq5-8pvq-j65j and https://github.com/advisories/GHSA-cwq5-8pvq-j65j.