Skip to main content

protobufjs EUVDEUVD-2026-38305

| CVE-2026-54270 MEDIUM
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-06-15 https://github.com/protobufjs/protobuf.js GHSA-94rc-8x27-4472
5.3
CVSS 3.1 · Vendor: https://github.com/protobufjs/protobuf.js
Share

Severity by source

Vendor (https://github.com/protobufjs/protobuf.js) PRIMARY
5.3 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
vuln.today AI
5.3 MEDIUM

Network-reachable with no auth; A:L rather than H because process termination requires sustained concurrent requests, not a single payload.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/protobufjs/protobuf.js).

CVSS VectorVendor: https://github.com/protobufjs/protobuf.js

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 15, 2026 - 20:38 vuln.today
Analysis Generated
Jun 15, 2026 - 20:38 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 32 npm packages depend on protobufjs (1 direct, 31 indirect)

Ecosystem-wide dependent count for version 8.2.0.

DescriptionCVE.org

Summary

protobufjs 8.2.0 added support for preserving unknown fields encountered during binary decode. Affected versions preserved unknown wire elements in message.$unknowns and did not provide a decode-time option to discard unknown fields before retaining them.

A crafted protobuf payload containing many unknown fields could therefore cause a decoded message to retain substantially more memory than the input size would suggest, even when unknown-field round-tripping is not needed. protobufjs 8.5.0 added the relevant decode-time options, allowing applications that decode untrusted protobuf data to disable unknown-field retention during decode. protobufjs 8.6.2 flips the default so unknown fields are discarded unless explicitly opted into.

Impact

An attacker who can provide protobuf binary data decoded by an application using affected protobufjs versions may be able to increase memory pressure by sending messages with many unknown fields. This can degrade availability or contribute to process termination in services that decode and retain attacker-controlled messages.

This issue affects applications that decode untrusted protobuf binary input and do not need unknown-field round-tripping. Applications that only decode trusted protobuf data, already enforce input-size/concurrency limits, or do not retain decoded messages beyond immediate processing are less directly affected.

Preconditions

  • The application must decode protobuf binary data influenced by an attacker.
  • The decoded schema must not define the attacker-selected field numbers, causing those fields to be treated as unknown.
  • The application must use a protobufjs version that preserves unknown fields but does not provide a decode-time discard option.
  • The decoded message, or enough decoded messages concurrently, must remain live long enough for retained unknown-field data to affect memory usage.

Workarounds

Upgrade to protobufjs 8.5.0 or newer and disable unknown-field preservation if not needed: Create a Reader, set reader.discardUnknown = true, and decode from that reader, or make this the default for subsequently created readers by setting Reader.discardUnknown = true. When upgrading to protobufjs 8.6.2 or newer, unknown fields are discarded by default unless opted into by setting discardUnknown = false.

Applications should also continue to enforce input-size, request concurrency, and request timeout limits at their transport or application boundary.

AnalysisAI

Memory amplification in protobufjs 8.2.0-8.4.2 enables remote unauthenticated attackers to exhaust heap memory in Node.js services by submitting crafted protobuf binary payloads densely packed with field numbers absent from the application's schema. The library's unknown-field retention feature - introduced in 8.2.0 - stores these wire elements in message.$unknowns with no decode-time cap or discard mechanism, allowing payloads to consume memory far exceeding their wire size. No public exploit code is identified at time of analysis, and this vulnerability is not listed in CISA KEV; however, the attack requires no privileges and is accessible over the network against any service that decodes untrusted protobuf binary input.

Technical ContextAI

protobufjs is the dominant JavaScript/TypeScript implementation of Google's Protocol Buffers binary serialization format (npm package pkg:npm/protobufjs). Version 8.2.0 introduced unknown-field preservation: when a binary-encoded message contains wire fields whose field numbers are not declared in the application's .proto schema, the decoder stores the raw wire elements in the message.$unknowns property to support round-trip fidelity. CWE-770 (Allocation of Resources Without Limits or Throttling) precisely describes the root cause: the library allocated memory for these retained unknown fields without exposing any mechanism to bound that allocation or discard fields at decode time. An attacker exploiting this can craft a payload where the ratio of unknown-to-known fields is maximized, causing the in-memory representation to be orders of magnitude larger than the serialized input. Version 8.5.0 introduced reader.discardUnknown and Reader.discardUnknown to control this behavior; version 8.6.2 changed the default to discard unknown fields unless explicitly opted into.

RemediationAI

The primary fix is upgrading to protobufjs 8.6.2 or newer, where unknown fields are discarded by default unless the application explicitly sets discardUnknown = false; this requires no code changes for applications that do not rely on unknown-field round-tripping. For applications upgrading only to 8.5.x, enable the discard option explicitly: call Reader.discardUnknown = true once at application startup to apply the behavior globally, or set reader.discardUnknown = true on individual Reader instances before decoding - note that per-reader configuration requires touching all decode call sites. Applications that cannot upgrade immediately should enforce strict input-size limits at the transport boundary (e.g., grpc.max_receive_message_length, Express limit in bodyParser) to constrain the maximum amplification per request; this does not eliminate the vulnerability but caps per-request memory cost. Additionally, enforcing request concurrency limits and per-request timeouts reduces the window for concurrent in-flight messages to accumulate. See https://github.com/protobufjs/protobuf.js/security/advisories/GHSA-94rc-8x27-4472 for full advisory details.

Share

EUVD-2026-38305 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy