I think there may be a problem in actions/ops-build-reporter/package-lock.json around line 3601.
undici 5.29.0, pinned in actions/ops-build-reporter/package-lock.json (lines 3601-3612), is flagged for CVE-2026-12151 (HIGH). The undici WebSocket client enforces maxPayloadSize only against the cumulative byte count of a message's fragments, with no cap on the number of fragments. A malicious or compromised WebSocket server can exploit this by streaming an endless series of small or empty continuation frames - each individually passing per-frame and cumulative-size validation - causing unbounded memory growth until the client process is OOM-killed, i.e. a remote denial of service. Exploitation requires the application to initiate a WebSocket connection (new WebSocket(...) or WebSocketStream) to an attacker-controlled or compromised endpoint. Risk level: HIGH per the scanner. In this repo the vulnerable version ships inside the ops-build-reporter GitHub Action, so the blast radius is mostly CI-bound (crashed jobs/runners, pipeline disruption) rather than production data compromise; however, the advisory offers no workaround and the fix is a low-risk dependency upgrade, so it should be patched promptly. Caveat: the advisory text says affected releases begin at 6.17.0 while 5.29.0 was flagged - upgrade anyway, since it clears the scanner finding and moves the action off the legacy 5.x line. Fixed versions: 6.27.0 (6.x line), 7.28.0 (7.x), 8.5.0 (8.x).
Something like this might fix it:
Upgrade undici to a patched release (>= 6.27.0 on the 6.x line; alternatively >= 7.28.0 or >= 8.5.0) and regenerate the lockfile. Do not hand-edit package-lock.json - let npm rewrite the node_modules/undici entry (lines 3601-3612) with correct resolved/integrity metadata.
If undici is a direct dependency of the action:
```diff
--- a/actions/ops-build-reporter/package.json
+++ b/actions/ops-build-reporter/package.json
@@
"dependencies": {
- "undici": "^5.29.0"
+ "undici": "^6.27.0"
}
```
Then run:
```bash
cd actions/ops-build-reporter
npm install undici@^6.27.0
npm ls undici # confirm 6.27.0+ resolves everywhere
```
If undici is only a transitive dependency, force the patched version via npm overrides:
```diff
--- a/actions/ops-build-reporter/package.json
+++ b/actions/ops-build-reporter/package.json
@@
{
"name": "ops-build-reporter",
"version": "1.0.0",
+ "overrides": {
+ "undici": "^6.27.0"
+ },
"dependencies": { ... }
}
```
Then run `npm install` to regenerate package-lock.json. After the bump, re-run the scanner to confirm CVE-2026-12151 is cleared, and as defense-in-depth verify the action never opens WebSocket connections to attacker-influenced/untrusted endpoints.
For reference: rule CVE-2026-12151. Rated high.
I do not maintain this project, so I may well be missing context — if this is intentional or already handled elsewhere, please just close it.
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
actions/ops-build-reporter/package-lock.jsonaround line 3601.undici 5.29.0, pinned in actions/ops-build-reporter/package-lock.json (lines 3601-3612), is flagged for CVE-2026-12151 (HIGH). The undici WebSocket client enforces maxPayloadSize only against the cumulative byte count of a message's fragments, with no cap on the number of fragments. A malicious or compromised WebSocket server can exploit this by streaming an endless series of small or empty continuation frames - each individually passing per-frame and cumulative-size validation - causing unbounded memory growth until the client process is OOM-killed, i.e. a remote denial of service. Exploitation requires the application to initiate a WebSocket connection (new WebSocket(...) or WebSocketStream) to an attacker-controlled or compromised endpoint. Risk level: HIGH per the scanner. In this repo the vulnerable version ships inside the ops-build-reporter GitHub Action, so the blast radius is mostly CI-bound (crashed jobs/runners, pipeline disruption) rather than production data compromise; however, the advisory offers no workaround and the fix is a low-risk dependency upgrade, so it should be patched promptly. Caveat: the advisory text says affected releases begin at 6.17.0 while 5.29.0 was flagged - upgrade anyway, since it clears the scanner finding and moves the action off the legacy 5.x line. Fixed versions: 6.27.0 (6.x line), 7.28.0 (7.x), 8.5.0 (8.x).
Something like this might fix it:
For reference: rule
CVE-2026-12151. Rated high.I do not maintain this project, so I may well be missing context — if this is intentional or already handled elsewhere, please just close it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.