GHSA-f38q-mgvj-vph7 CVE-2026-54269
protobufjs : Schema-derived names can shadow runtime-significant properties
- Severity
- 5.3 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 0.40%
- Chance of exploitation in the next 30 days. Higher than 34.49% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
- Available
- 2 packages have a fixed version
Description
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
$typethrough protobufjs JSON/reflection descriptor input, - or a service method whose generated helper name is
rpcCall.
- a field named
- The application must reach the affected API path for that name: required-field decode post-checks,
verify, ortoObjectforhasOwnProperty; reflected message JSON serialization for$type; or protobufjs RPC service invocation forrpcCall.
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.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| protobufjs | < 7.6.3 |
7.6.3 |
| protobufjs | >= 8.0.0, < 8.6.0 |
8.6.0 |
| protobufjs-cli | >= 2.0.0, < 2.5.1 |
2.5.1 |
| protobufjs-cli | < 1.3.3 |
1.3.3 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
protobufjs npm → 7.6.3
- npm
npm install protobufjs@7.6.3- yarn
yarn add protobufjs@7.6.3- pnpm
pnpm add protobufjs@7.6.3
protobufjs-cli npm → 2.5.1
- npm
npm install protobufjs-cli@2.5.1- yarn
yarn add protobufjs-cli@2.5.1- pnpm
pnpm add protobufjs-cli@2.5.1
Severity breakdown
CVSS 3.1 5.3
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
Weakness
CWE-674: Uncontrolled Recursion
The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.
How to prevent it
- Implementation: Ensure that an end condition will be reached under all logic conditions. The end condition may include checking against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.
- Implementation: Increase the stack size.
CWE-754: Improper Check for Unusual or Exceptional Conditions
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
- Implementation: Check the results of all functions that return a value and verify that the value is expected.
- Implementation: If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
- Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Architecture and Design, Implementation: If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
- Architecture and Design: Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-j3f2-48v5-ccww protobufjs: Denial of Service via infinite loop in .proto option parsing | High | Also affects protobufjs |
| GHSA-jfj6-75fj-8934 protobufjs: Text Format string map parsing can mutate returned map object prototype | Medium | Also affects protobufjs |
| GHSA-94rc-8x27-4472 protobufjs: Memory amplification from preserved unknown fields in binary decode | Medium | Also affects protobufjs |
| GHSA-wcpc-wj8m-hjx6 protobufjs: Denial of service through unbounded Any expansion during JSON conversion | High | Also affects protobufjs |
| GHSA-jggg-4jg4-v7c6 protobufjs: Denial of Service via unbounded recursive JSON descriptor expansion | High | Also affects protobufjs |
| GHSA-2pr8-phx7-x9h3 protobuf.js: Denial of service from crafted field names in generated code | Medium | Also affects protobufjs |
| GHSA-66ff-xgx4-vchm protobuf.js: Code injection through bytes field defaults in generated toObject code | High | Also affects protobufjs |
| GHSA-fx83-v9x8-x52w protobuf.js: Prototype injection in generated message constructors | Medium | Also affects protobufjs |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor