npm install @tanstack/react-router@1.169.8 in jadoonf/npm-analysis-feed, run 25697800810. Of 42 TanStack package profiles in the sweep, 8 records carried the same shape: package install reached a transient bun.exe under the npm cache, escalated through sudo, and spawned python3.10 from there.The TanStack sweep ran every package in the matrix through the same install on a GitHub Actions runner instrumented with Garnet's eBPF sensor. Each install produced one run profile and the same three runtime checks were evaluated against process ancestry, file access, and network egress. The TanStack project itself was not compromised at the time of the sweep; the profiles are useful because the records separate cleanly across the 42 packages.
Execution lineage
Run 25697800810 · jadoonf/npm-analysis-feed
Garnet: TanStack Matrix
The embedded record is the install of @tanstack/react-router@1.169.8. The lineage shows what npm install did at the kernel level: a transient Bun binary ran from a path inside the npm cache, dropped to dash, then sudo, then python3.10. None of those processes appear in the workflow's checked-in source; they came from a path the dependency install staged at resolve time. The same chain appeared in each of the 8 failing TanStack profiles below.
Assertions flagged
Three checks ran against this profile. The canonical assertion id Garnet posts back to the control plane is one of no_bad_egress_domain / no_bad_ingress_domain / no_bad_local_domain; the granular id below is what the embed renders.
| Check (class) | Granular id | Result | Evidence |
|---|---|---|---|
| Privilege escalation | no_code_injection_via_proc_memory | fail | python3.10 descended from bun.exe → sudo matched the code modification through procfs pattern. Confidence 0.99, severity high. |
| Network egress | no_bad_egress_domain | attention | The same process family reached git-tanstack.com, a destination clean profiles in this sweep never touched. |
| Stealth | no_binary_execution_and_deletion | pass | No self-deleting payload observed on this ancestry. |
The other 34 profiles in the sweep cleared all three.
What was observed
Process ancestry. The install resolved through Node, then crossed into a transient Bun binary that the dependency tree staged inside the npm cache (~/.npm/_cacache/tmp/git-clone.../node_modules/bun/bin/bun.exe), then escalated through sudo and launched python3.10. The full chain — npm install → node → dash → bun.exe → dash → sudo → python3.10 — is visible in the embedded lineage above; the same chain appeared in each of the 8 failing profiles.
Network. Outbound flows on this ancestry covered registry and GitHub traffic, the link-local cloud metadata address 169.254.169.254, and git-tanstack.com. Clean profiles in the same sweep covered only registry.npmjs.org, api.github.com, codeload.github.com, and local DNS.
File / memory access. On the same ancestry the record carries exec_from_unusual_dir and hidden_elf_exec (the Bun binary running from the npm-cache path), plus credentials_files_access (touches on credential-shaped paths). The privilege-escalation check ties these back to the code_modification_through_procfs pattern on the Python descendant.
Notable absences. No binary_self_deletion on this ancestry — the Bun binary stayed on disk after the install step exited. No outbound from the Python descendant to a non-cloud-metadata destination before the workflow step closed. The record carries the precondition for credential outbound but not the outbound itself.
What changed between runs
The clean comparator is the other 34 TanStack profiles from the same sweep, running the same kind of npm install against the same runner image.
| Clean profiles in the sweep | The 8 profiles with the chain | |
|---|---|---|
| Process lineage | npm install → node and stop | npm install → node → dash → bun.exe → dash → sudo → python3.10 |
| Executable location | Resolved binaries from project paths | bun.exe from ~/.npm/_cacache/tmp/git-clone.../node_modules/bun/bin/bun.exe |
| Network (observed) | Registry + GitHub + local DNS | Registry + GitHub + git-tanstack.com + 169.254.169.254 |
| File / exec signals on the ancestry | None | exec_from_unusual_dir, hidden_elf_exec, credentials_files_access |
| Privilege-escalation check | pass | fail |
| Network-egress check | pass | attention |
The 8 profiles with the chain covered @tanstack/react-router@1.169.8 (the install shown in the embed), @tanstack/router-ssr-query-core@1.168.6, @tanstack/router-utils@1.161.14, @tanstack/router-vite-plugin@1.166.56, @tanstack/solid-router-devtools@1.166.19, @tanstack/solid-router-ssr-query@1.166.18, @tanstack/solid-start-client@1.166.53, and @tanstack/vue-start-client@1.166.49.
Analysis
The interesting property of this record is that two runs with identical workflow source produced different runtime shapes. The split lives in the resolve graph, not in any file under version control, and it only becomes legible when the install executes against an instrumented runner. Lockfiles and static scanners describe the surface of the dependency tree; this record describes what the dependency tree actually ran.
Garnet records process ancestry, file access, and network egress straight from the kernel for every workflow run by the Garnet GitHub Action. One record per run, the same shape as the one above.
