[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 @clickhouse/clickstack-node → @opentelemetry/auto-instrumentations-node → @opentelemetry/instrumentation-host-metrics 0.6.0 (since #3575), so it is in the API image. That package asks for ^5.31.6, but the old pin holds it at 5.30.7. 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. @opentelemetry/auto-instrumentations-node leaves host metrics off by default (defaultExcludedInstrumentations). packages/api/src/telemetry.ts turns them on only when NODE_ENV=development and an API key is set, and the Docker images set NODE_ENV=production. An operator can still turn them on with OTEL_NODE_ENABLED_INSTRUMENTATIONS. The instrumentation 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.
• 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/instrumentation-host-metrics@npm:0.6.0 (before #3575: @opentelemetry/host-metrics@npm:0.35.5). node_modules has one copy, 5.33.19.

The API starts with the new version. On this branch after #3575, I started packages/api/src/index.ts with NODE_ENV=development and the src/telemetry.ts preload (the yarn dev command, without nodemon and dotenv), a dummy HYPERDX_API_KEY, and the OTLP exports sent to a local HTTP listener. The first metrics export had system.cpu.time, system.memory.usage, system.network.io and system.network.errors. The log had no uncaught errors or unhandled rejections. Before #3575 I ran the same check with @opentelemetry/host-metrics 0.35.5, with the same result.

For the before/after checks I used two small installs with the pre-#3575 yarn.lock versions of @opentelemetry/host-metrics (0.35.5), @opentelemetry/sdk-metrics (1.30.1) and @opentelemetry/api (1.9.0). The systeminformation call in @opentelemetry/instrumentation-host-metrics 0.6.0 (build/src/stats/si.js) is the same code as in host-metrics 0.35.5, so these results apply to the current dependent too. 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

✅ No critical issues found.

This is a tightly scoped security dependency bump: the root resolutions pin for systeminformation moves from ^5.24.0 (which held the lockfile at 5.30.7) to ^5.33.19, with a matching single-entry yarn.lock update and a changeset. Direct verification confirms the change is correct and self-consistent:

• systeminformation is referenced only by the root package.json resolutions; no workspace depends on it directly. It reaches the @hyperdx/api image transitively via @opentelemetry/instrumentation-host-metrics@0.6.0, which requests ^5.31.6.
• The old ^5.24.0 pin forced 5.30.7, which does not satisfy the dependent's ^5.31.6; the new ^5.33.19 resolves to 5.33.19 and does. yarn.lock now carries exactly one systeminformation entry with an updated checksum.
• The caret floor ^5.33.19 cannot resolve below 5.33.19, so the advisory range (fixes landed at 5.31.6/5.31.7 and 5.33.16) stays cleared while still allowing forward 5.x patches.
• npmMinimalAgeGate: 7d is satisfied (5.33.19 published 2026-10-30). The changeset's fixed group explains why @hyperdx/app and @hyperdx/otel-collector also bump.

No P0/P1 or P2 findings. The two points raised in the prior Deep Review (resolutionsNotes entry, HostMetrics test coverage) were consciously declined or are pre-existing; neither is an actionable regression in this diff.

🔵 P3 nitpicks (1)

• package.json:88 -- the rationale for this security pin lives only in the changeset body, which is consumed and deleted on release, so the repo retains no in-tree record of why the floor was raised (the resolutionsNotes block documents only the minimatch pin).
  • Fix: optionally add a resolutionsNotes entry for systeminformation recording the advisory IDs and the raised floor; consistent with the author's note that the other six security pins are also undocumented, so leaving it is acceptable too.

---

Reviewers (3): correctness, testing, maintainability. Security, project-standards, and previous-comments reviewers were also dispatched but had not returned when the report was finalized; those domains were covered by direct verification of the resolution/lockfile graph, the advisory range, the age gate, and the prior PR comments.

Testing gaps:

• No automated test exercises systeminformation via OpenTelemetry HostMetrics; that path runs only under NODE_ENV=development, which no CI job uses (Docker is production, E2E is test). Pre-existing, not introduced by this diff.
• No captured yarn install --immutable or checksum verification in CI confirming lockfile/manifest consistency for the new 5.33.19 entry.

_{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?

[BilalAtique]

Pushed b631892. Since #3575, the API gets systeminformation through @opentelemetry/instrumentation-host-metrics 0.6.0, not @opentelemetry/host-metrics, so I fixed the changeset text and the PR description. It also merges current main (with #3592). The diff against main is still the pin, the one yarn.lock entry and the changeset. I ran the dev API on this branch again with the new telemetry.ts preload: its first metrics export had system.network.io, and the log had no errors. Thanks for the CI fixes in #3590 and #3592.

[BilalAtique]

@teeohhem my push dismissed your approval, sorry about that. The only change since you approved is the changeset wording above, plus the main merges. Could you re-approve when you have a moment?