[BilalAtique]

Summary

The root resolutions block pins systeminformation to ^5.24.0, and yarn.lock resolves it to 5.30.7. @hyperdx/api installs it through @opentelemetry/host-metrics, a production dependency, so it is in the API image. npm audit reports 7 advisories for 5.30.7, 5 of them high. Two of them are the command injections in networkInterfaces() on Linux from the issue: GHSA-5xpp-75jx-m839 (fixed in 5.31.7) and GHSA-hvx9-hwr7-wjj9 (fixed in 5.31.6).

• The resolution is now ^5.33.19, the newest 5.x release. It fixes all 7 advisories. The last fix (GHSA-3f7j-7jwc-fxfj, Windows) is in 5.33.16.
• yarn.lock changes only the systeminformation entry, from 5.30.7 to 5.33.19.
• A changeset bumps @hyperdx/api at patch.

Things to be aware of:

• I did not find a path from HyperDX code to the vulnerable functions. packages/api/src/index.ts starts HostMetrics only when NODE_ENV=development, and the Docker images set NODE_ENV=production. Also, host-metrics calls networkStats() with no argument. On Linux, that reads only the default interface (ip route, then /sys/class/net/<iface>/...) and does not call networkInterfaces(). It calls it only on Windows, or for the '*' argument. I measured this on Linux (see Tests). So this change removes a vulnerable version from the image and from scanner reports. I could not show an exploit through HyperDX.
• fix: npm vuln resolutions + VEX exceptions #1803 raised this resolution to ^5.31.0 in March. It was stacked on build(deps): add security resolutions for vulnerable npm packages #1740 and merged into the build(deps): add security resolutions for vulnerable npm packages #1740 branch after build(deps): add security resolutions for vulnerable npm packages #1740 had landed, so the bump never reached main.
• @opentelemetry/host-metrics 0.40.0 depends on systeminformation@^5.31.6. A host-metrics update would also work, but it is a larger change (0.35.5 to 0.40.0), and the root resolution would still override its range. I kept this PR to the resolution.
• 5.33.19 was published on 2026-10-30, so it passes the repo's 7-day npmMinimalAgeGate.
• The systeminformation changelog from 5.30.7 to 5.33.19 lists fixes and hardening, and no API removals.

Tests

yarn install with the repo's Yarn (4.13.0) changes only the systeminformation entry in yarn.lock. yarn why systeminformation shows 5.30.7 (via npm:^5.24.0) on main and 5.33.19 (via npm:^5.33.19) on this branch, both under @opentelemetry/host-metrics@npm:0.35.5. node_modules has one copy, 5.33.19.

The API starts with the new version. I started packages/api/src/index.ts with NODE_ENV=development (the yarn dev command, without nodemon and dotenv) and sent its OTLP exports to a local HTTP listener. The first metrics export had system.cpu.time, system.memory.usage, system.network.io, system.network.errors and system.network.dropped. The log had no uncaught errors or unhandled rejections.

For the before/after checks I used two small installs with the yarn.lock versions of @opentelemetry/host-metrics (0.35.5), @opentelemetry/sdk-metrics (1.30.1) and @opentelemetry/api (1.9.0). An npm override sets systeminformation to 5.30.7 (main) or 5.33.19 (this branch). The Linux runs use node:22.23.4-alpine, the base of the API image, in Docker (arm64). HostMetrics runs as in packages/api/src/index.ts, with an in-memory reader, and is collected twice.

Check	main (5.30.7)	This branch (5.33.19)
npm audit, systeminformation advisories	7 (5 high, 1 moderate, 1 low)	0
Linux: networkInterfaces() with source /tmp/x;touch${IFS}/tmp/pwned-interfaces in /etc/network/interfaces (GHSA-5xpp-75jx-m839)	runs touch	does not run it
Linux: HostMetrics with the same file	10 metrics, 0 errors, system.network.io for eth0, touch not run	same
macOS: HostMetrics	10 metrics, 0 errors	same
Result fields of networkInterfaces() and networkStats() (Linux and macOS)		same as main

I also logged every child process. On Linux, on both versions, HostMetrics runs only ip route 2> /dev/null | grep default and cat /sys/class/net/eth0/.... Prettier passes on package.json and the changeset.

Not run: Windows, the Docker image build, ESLint, tsc and knip (no source file or workspace dependency changed).

How to reproduce

Starting point: a clone of this repo. Use the repo's Yarn (4.13.0).

On main:

1. Run yarn why systeminformation. It shows systeminformation@npm:5.30.7 (via npm:^5.24.0). 5.30.7 is in the vulnerable range of GHSA-5xpp-75jx-m839 (<= 5.31.6) and GHSA-hvx9-hwr7-wjj9 (>= 4.17.0, <= 5.31.5).
2. To see the injection itself: in a node:22-alpine container with systeminformation@5.30.7 installed, write source /tmp/x;touch${IFS}/tmp/pwned-interfaces to /etc/network/interfaces, then run node -e "require('systeminformation/lib/network').networkInterfaces()". /tmp/pwned-interfaces is created.

On this branch:

1. Run yarn why systeminformation. It shows systeminformation@npm:5.33.19 (via npm:^5.33.19).
2. Repeat step 2 with systeminformation@5.33.19. /tmp/pwned-interfaces is not created.

How to test on Vercel preview

N/A — non-UI change.

References

• Closes systeminformation resolution still allows 5.30.7 -- command injection in networkInterfaces() #3306
• Related: build(deps): add security resolutions for vulnerable npm packages #1740 (added the resolution), fix: npm vuln resolutions + VEX exceptions #1803 (its ^5.31.0 bump did not reach main)

[vercel]

@BilalAtique is attempting to deploy a commit to the HyperDX Team on Vercel.

A member of the Team first needs to authorize it.

[changeset-bot]

🦋 Changeset detected

Latest commit: 72f8ace

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@hyperdx/api	Patch
@hyperdx/app	Patch
@hyperdx/otel-collector	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

PR Review

✅ No issues found.

[github-actions]

Deep Review

Scope: 3 files vs base 5b0d074 — package.json (root resolutions pin), yarn.lock (single entry), .changeset/systeminformation-command-injection.md (new). No first-party source changes.

Intent: Remediate command-injection advisories in systeminformation by raising the root resolutions pin from ^5.24.0 to ^5.33.19 and moving the locked version from 5.30.7 to 5.33.19.

✅ No critical issues found.

Direct verification of the change:

• Lockfile is internally consistent. yarn.lock has exactly one top-level systeminformation entry (systeminformation@npm:^5.33.19 → 5.33.19); no second resolved version remains. The transitive descriptor systeminformation: "npm:^5.31.6" from @opentelemetry/instrumentation-host-metrics@npm:0.6.0 is bridged to that entry by the global resolution override — the same mechanism already in use on main (where ^5.24.0/5.30.7 was the single key despite the same ^5.31.6 descriptor).
• No vulnerable copy lingers. The old 5.30.7 entry is fully removed; the tree resolves to a single fixed version.
• No first-party exposure. No source file under packages/ imports systeminformation or HostMetrics; the dependency is entirely transitive, so the bump carries no first-party API or behavior change.
• Changeset scope matches reach. @hyperdx/api: patch is the package whose image embeds the transitive dependency; the other packages in the aggregated changeset-bot list originate from pre-existing changesets, not this diff.

🔵 P3 nitpicks (1)

• package.json:88 — the sibling resolutionsNotes object documents the rationale for one pin but adds no entry for this high-severity security pin, leaving its "why" only in the changeset and PR body.
  • Fix: optionally add a resolutionsNotes entry recording the advisory IDs and the minimum fixed version for the systeminformation pin.

---

Reviewers (4): correctness, maintainability, security, previous-comments.

Testing gaps:

• No automated regression test exercises the host-metrics code path against 5.33.19; the compatibility check was performed manually and the path runs only outside NODE_ENV=production, so the gap is low-risk but remains uncovered in CI.

_{No finding blocks merge automatically. A maintainer will expect P0/P1 findings in code this PR changes to be fixed; P2/P3 are your call -- fix or reply. Never fix findings about surrounding code here; reply instead. Do not widen the PR. How to respond}

[BilalAtique]

Thanks. On the Deep Review points:

• resolutionsNotes (P3): not changed. The other security pins in resolutions (express, send, cookie, fast-xml-parser, ...) have no note, and the one existing note is for a pin that is "not a CVE override". This PR and the changeset record why the systeminformation pin is high. Happy to add a note if a maintainer wants one.
• Test gap (HostMetrics with 5.33.19): the gap was there before this PR. I ran that path by hand: packages/api/src/index.ts with NODE_ENV=development exported system.network.io and the other host metrics with 5.33.19, and HostMetrics gave the same 10 metrics with 0 errors on 5.30.7 and 5.33.19 on Linux and macOS (details under Tests). I did not add a CI test, to keep this PR to the version bump.

[BilalAtique]

E2E shard 1 failed on one test, alerts.spec.ts:631 (between-threshold alert from a dashboard tile), on all 3 tries. The failure screenshot shows no webhook selected in the tile alert form ("Expected string, received null"), so the editor does not save.

I don't think this PR causes it. It changes no app code, and the E2E API runs with NODE_ENV=test, so HostMetrics (the only user of systeminformation) does not start. The other 116 tests in the shard pass, including the between-threshold alert from a saved search, and main passed at the same base (4e93ae5). I can't rerun jobs from a fork. Could a maintainer rerun the failed job?

[BilalAtique]

E2E shard 4 on 72f8ace stopped before any test ran: Timed out waiting 180000ms from config.webServer. The API was up ("API Server listening on port 21000, NODE_ENV=test", MongoDB connected). The Next.js production build was still collecting build traces when the 180 s limit ran out (TypeScript 32 s, compile 92 s). The other jobs on this head pass so far. Could a maintainer rerun that job?