I think there may be a problem in pnpm-lock.yaml around line 1.
The project depends on protobufjs 7.5.4, which is vulnerable to CVE-2026-41242. In vulnerable versions, an attacker can craft a protobuf definition with malicious content in a "type" field. When the definition is compiled and used for decoding, the malicious code is executed in the runtime, resulting in remote code execution. This gives the attacker full control over the application host, making the vulnerability CRITICAL. Updating protobufjs to a non‑vulnerable release (>=7.5.5 or >=8.0.1) eliminates the unsafe code generation path and mitigates the risk.
Something like this might fix it:
*** Begin Patch
*** Update File: pnpm-lock.yaml
@@
- "protobufjs": "7.5.4",
+ "protobufjs": "7.5.5",
*** End Patch
For reference: rule CVE-2026-41242. Rated critical.
I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
I think there may be a problem in
pnpm-lock.yamlaround line 1.The project depends on protobufjs 7.5.4, which is vulnerable to CVE-2026-41242. In vulnerable versions, an attacker can craft a protobuf definition with malicious content in a "type" field. When the definition is compiled and used for decoding, the malicious code is executed in the runtime, resulting in remote code execution. This gives the attacker full control over the application host, making the vulnerability CRITICAL. Updating protobufjs to a non‑vulnerable release (>=7.5.5 or >=8.0.1) eliminates the unsafe code generation path and mitigates the risk.
Something like this might fix it:
For reference: rule
CVE-2026-41242. Rated critical.I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.