Spotted what might be an issue in pnpm-lock.yaml around line 1.
The project is using trim@0.0.1, which is vulnerable to a Regular Expression Denial of Service (ReDoS) flaw (CVE-2020-7753). An attacker can craft input that triggers catastrophic backtracking in the trim() implementation, causing the application to hang or crash. This is classified as HIGH severity because it can lead to service disruption and potentially be leveraged in broader attacks. Updating to the patched version (>=0.0.3) eliminates the vulnerable regex and mitigates the risk.
Something like this might fix it:
```diff
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@
- /trim/0.0.1:
- resolution: {integrity: sha512-<old-hash>}
- version: 0.0.1
+ /trim/0.0.3:
+ resolution: {integrity: sha512-<new-hash>}
+ version: 0.0.3
```
Additionally, ensure the `package.json` (or any other manifest) references the updated version, e.g.:
```json
"dependencies": {
"trim": "^0.0.3"
}
```
For reference: rule CVE-2020-7753. Rated high.
I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Spotted what might be an issue in
pnpm-lock.yamlaround line 1.The project is using trim@0.0.1, which is vulnerable to a Regular Expression Denial of Service (ReDoS) flaw (CVE-2020-7753). An attacker can craft input that triggers catastrophic backtracking in the trim() implementation, causing the application to hang or crash. This is classified as HIGH severity because it can lead to service disruption and potentially be leveraged in broader attacks. Updating to the patched version (>=0.0.3) eliminates the vulnerable regex and mitigates the risk.
Something like this might fix it:
For reference: rule
CVE-2020-7753. Rated high.I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.