🚨 [security] Update protobufjs 8.4.2 → 8.6.3 (minor)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ protobufjs (8.4.2 → 8.6.3) · Repo · Changelog

Security Advisories 🚨

🚨 protobufjs: Memory amplification from preserved unknown fields in binary decode

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.

🚨 protobufjs : Schema-derived names can shadow runtime-significant properties

Summary

protobufjs accepted certain schema-derived names that could collide with properties used by protobufjs runtime helpers. The known affected names are fields named hasOwnProperty, field or oneof names such as $type when loaded through protobufjs JSON/reflection descriptors, and service methods whose generated helper name is rpcCall.

When affected message or service types were used, protobufjs could read schema-controlled data where it expected an own-property helper, reflected type metadata, or the base RPC helper. This could cause deterministic exceptions or recursive calls in affected decode post-checks, verification, object conversion, reflected JSON serialization, or protobufjs RPC helper invocation.

Impact

An attacker who can provide or influence protobuf schemas or protobufjs JSON descriptors may be able to make affected message or service types unusable, resulting in denial of service for the affected processing path.

Applications using only trusted schemas are affected only if those schemas contain one of the problematic names and the application reaches the affected API path.

The issue is not known to allow code execution by itself.

Preconditions

• The application must use an affected protobufjs version.
• The application must load or use a schema or protobufjs JSON descriptor containing one of the problematic names:
  • a field named hasOwnProperty,
  • a field or oneof named $type through protobufjs JSON/reflection descriptor input,
  • or a service method whose generated helper name is rpcCall.
• The application must reach the affected API path for that name: required-field decode post-checks, verify, or toObject for hasOwnProperty; reflected message JSON serialization for $type; or protobufjs RPC service invocation for rpcCall.

Workarounds

Do not load protobuf schemas or protobufjs JSON descriptors from untrusted sources with affected versions. If untrusted schemas or descriptors must be accepted, validate schema-derived field, oneof, and service method names before loading and reject the problematic names described above.

Applications using trusted schemas can avoid the issue by renaming affected fields or service methods, or by avoiding the affected API path.

Release Notes

8.6.3 (from changelog)

Bug Fixes

• Consistently reject truncated 64-bit varints (#2322) (ec868f3)
• Include interfaces in API docs and fix FieldMask doc comment (#2319) (c98a4e5)
• Preserve explicit URLs in path resolution (#2320) (c97cdbe)
• Remove renamed reflection objects by identity (#2324) (9c9f8ee)
• Support Node ESM named imports from CommonJS entrypoints (#2315) (3359e64)
• Support utf8_validation during decode (#2325) (4dff8e4)

8.6.2 (from changelog)

Bug Fixes

• Discard unknown fields by default (#2310) (bf12d56)

8.6.1 (from changelog)

Bug Fixes

• cli: Consistently wait for pbts output before JSDoc exit (#2306) (87ff02f)
• cli: Preserve indentation in multiline declarations (#2307) (b38748d)
• Preserve descriptor metadata needed by protoc-gen-pbjs (#2308) (a3b8dc7)
• Remove inquire submodule (#2305) (cc42616)

8.6.0 (from changelog)

Features

• Add spec-compliant protojson extension (#2297) (ffd3d51)

Bug Fixes

• Avoid name collisions in generated code (#2302) (ce013ab)
• cli: Vendor patched Catharsis for pbts (#2304) (29f7c96)
• Remove postinstall script (#2299) (b8ed7be)
• Support null-prototype plain objects in converters (#2300) (bf20d84)

8.5.0 (from changelog)

Features

• Add option to discard unknown fields (#2289) (f8c489b)
• Expose RPC metadata on service methods (#2286) (711a279)

Bug Fixes

• cli: Consistently handle derived names (#2293) (9e80030)
• Consistently reject null message argument in fromObject (#2287) (0f6178d)
• Prefer nested type resolution over global fallback (#2288) (4b4c703)

Does any of this look wrong? Please let us know.

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[mstange]

I don't think the security issue affects us since we're only using protobuf with a single fixed .proto file: simpleperf_report.proto. This file doesn't match any of the preconditions.

We should still update though.

[canova]

Yeah, let's still update. Seems to be fine.