v3.x: onnxruntime-node@1.21.0 pulls in vulnerable tar (<7.5.8) — CVE-2026-26960

[emiluzelac]

Summary

@huggingface/transformers@3.8.1 depends on onnxruntime-node@1.21.0, which
depends on tar@^7.0.1. This exposes downstream consumers to
CVE-2026-26960 (High 7.1 —
arbitrary file read/write via hardlink target escape through symlink chain).

Dependency chain

@huggingface/transformers@3.8.1
  └── onnxruntime-node@1.21.0
        └── tar@^7.0.1 (resolved ≤7.5.7, vulnerable)

Fix available upstream

• tar fixed the vulnerability in 7.5.8 (current: 7.5.9).
• onnxruntime-node removed tar entirely in v1.22.0, switching to
  adm-zip. Current latest is 1.24.2.
• @huggingface/transformers v4.0.0-next already uses onnxruntime-node@1.24.1,
  so this is resolved in v4 preview but not in stable v3.

Request

Could onnxruntime-node be bumped to >=1.22.0 in the v3.x branch? This is a
semver-compatible update that eliminates the entire tar dependency chain.

Alternatively, a v3.x patch release that widens the onnxruntime-node peer/dep
range to include 1.22+ would let downstream consumers resolve it via overrides.

Impact

Any project using @huggingface/transformers@3.x triggers a high-severity
audit finding (bun audit, npm audit). The practical runtime risk is low
(tar is only used during onnxruntime-node's postinstall to extract native
binaries from Microsoft's CDN), but it blocks CI security gates and compliance
checks for downstream consumers.

[xenova]

Hi there 👋 Thanks for letting us know. As you mention, this doesn't necessarily affect us (or users), but I do agree putting out a new version is a good idea. Strangely enough, when I try install it myself, I don't see any warning message. Could you provide logs/screenshot of this message being printed?

Will continue investigating this first thing tomorrow!

[emiluzelac]

Hi! Thanks for looking into this.

The reason you likely can't reproduce it is that npm resolves tar@^7.0.1 to the latest 7.5.9 (patched), so npm audit shows 0 vulnerabilities. The warning surfaces with bun audit on projects where the lockfile pins tar to a pre-patch version.

bun audit output

bun audit v1.3.2 (b131639c)
tar  <7.5.8
  @huggingface/transformers > onnxruntime-node > tar
  high: Arbitrary File Read/Write via Hardlink Target Escape Through Symlink Chain
        in node-tar Extraction - https://github.com/advisories/GHSA-83g3-92jg-28cx

Dependency chain

@huggingface/transformers@3.8.1
  → onnxruntime-node@1.21.0  (pinned exact, not a range)
    → tar@7.5.7              (vulnerable, CVE-2026-26960)

Environment

• Bun 1.3.2 on macOS (Darwin 25.2.0)
• @huggingface/transformers declared as ^3.8.1 (optional dependency)
• Lockfile (bun.lock) resolves tar to 7.5.7

Why lockfile-pinned versions matter

Even though ^7.0.1 can resolve to a safe version on a fresh install, projects with existing lockfiles stay pinned to the vulnerable 7.5.7. This affects bun and likely pnpm or any tool that respects lockfile pins from before the tar@7.5.8 patch was published.

Suggested fix

onnxruntime-node@1.22.0 removed tar entirely in favor of adm-zip. Bumping the onnxruntime-node pin from 1.21.0 to >=1.22.0 would eliminate the vulnerable dependency chain regardless of lockfile state or package manager.

As mentioned in the original report — this doesn't affect us functionally, but flagging it for a clean dependency tree.

[xenova]

The warning surfaces with bun audit on projects where the lockfile pins tar to a pre-patch version.

So, do you mean this is project-specific? And only affects users with a pre-existing installation? If so, users should get a clear warning message to run npm audit (or bun audit), and then fix it? Is that correct?

[emiluzelac]

It's not purely project-specific — it affects any project where the lockfile was generated (or last updated tar) before 7.5.8 was published. That's a wide window since onnxruntime-node@1.21.0 has been the pinned version in @huggingface/transformers@3.x for a while.

Users can fix it themselves:

• npm audit fix / bun update tar to bump the lockfile resolution
• Or add "overrides": { "tar": ">=7.5.8" } to package.json

But there are two reasons an upstream fix is better:

1. New lockfiles can still pin the vulnerable version. Package managers don't always resolve to the latest patch — bun install in particular tends to resolve conservatively. So new projects can still end up with tar@7.5.7 depending on timing and resolver behavior.

2. onnxruntime-node@1.21.0 is an exact pin, not a range. Even if a user bumps tar in their lockfile, the declared dependency chain still points at a version of onnxruntime-node that lists a vulnerable tar range. Audit tools flag the declared chain, not just the resolved version. The cleanest fix is bumping to onnxruntime-node@>=1.22.0 which removed tar entirely.

So yes — users get a clear audit warning and can work around it. But every downstream project has to independently discover and patch it. A v3.x point release bumping onnxruntime-node would fix it for everyone at once.

[xenova]

Can you give a reproduction of a clean install where this is a problem? I understand that some users may have their package-lock set to tar<7.5.8, but then they will get a message saying to update.

For example, installing with npm I see:

$ npm i @huggingface/transformers

added 55 packages, and audited 56 packages in 5s

11 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
$ cat package-lock.json | grep tar
        "tar": "^7.0.1"
    "node_modules/tar": {
      "resolved": "https://registry.npmjs.org/tar/-/tar-7.5.9.tgz",

Thanks for the discussion -- I'm just trying to understand your comments fully.

[emiluzelac]

Reproduction

You're right that a fresh install today resolves to tar@7.5.9 (patched) — both npm and bun do this. The issue is lockfile-pinned versions from before the tar@7.5.8 patch was published (Feb 16, 2026).

Here's a concrete npm reproduction:

# 1. Fresh install — clean, as you showed
mkdir repro && cd repro && npm init -y
npm i @huggingface/transformers
npm ls tar        # tar@7.5.9 ✓
npm audit          # 0 vulnerabilities ✓

# 2. Simulate a lockfile from before Feb 16, 2026
#    (change tar version in package-lock.json to 7.5.7)
python3 -c "
import json
with open('package-lock.json') as f:
    lock = json.load(f)
for pkg, data in lock['packages'].items():
    if pkg.endswith('/tar'):
        data['version'] = '7.5.7'
        data['resolved'] = 'https://registry.npmjs.org/tar/-/tar-7.5.7.tgz'
        data['integrity'] = 'sha512-fov56fJiRuThVFXD6o6/Q354S7pnWMJIVlDBYijsTNx6jKSE4pvrDTs6lUnmGvNyfJwFQQwWy3owKz1ucIhveQ=='
with open('package-lock.json', 'w') as f:
    json.dump(lock, f, indent=2)
"

# 3. Install with the lockfile — stays vulnerable
rm -rf node_modules && npm ci
npm ls tar        # tar@7.5.7 ✗
npm audit          # 1 high severity vulnerability

Output from step 3:

$ npm ci
added 55 packages, and audited 56 packages in 3s
1 high severity vulnerability

$ npm audit
tar  <7.5.8
Severity: high
Arbitrary File Read/Write via Hardlink Target Escape Through Symlink Chain
  in node-tar Extraction - https://github.com/advisories/GHSA-83g3-92jg-28cx
fix available via `npm audit fix`
node_modules/tar

Both npm install and npm ci respect the lockfile and keep the vulnerable version. npm audit fix does resolve it.

Why it matters at scale

Any project that ran npm install or bun install with @huggingface/transformers before Feb 16 has tar@7.5.7 in their lockfile. They'll carry CVE-2026-26960 (high severity — arbitrary file read/write via hardlink escape) until they either:

• Run npm audit fix
• Add "overrides": { "tar": ">=7.5.8" }
• Or delete their lockfile and reinstall

Since onnxruntime-node@1.22.0 removed tar entirely (switched to adm-zip), bumping the onnxruntime-node dependency would eliminate this for everyone in one release.

[xenova]

The issue is lockfile-pinned versions from before the tar@7.5.8 patch was published (Feb 16, 2026).

So, let's assume a user has a lockfile-pinned version before the tar@7.5.8 patch. There are two scenarios. Either:

1. The user runs npm audit fix, bumping the version of tar to >= 7.5.8
2. The user runs npm audit fix, bumping transformers.js to e.g., @huggingface/transformers@3.8.2.

So... same solution? Perhaps I am misunderstanding the point you are trying to make. New users aren't affected, and users with existing lockfiles that use older tar version are provided with a clear warning to bump versions by running npm audit fix. Is that the case?

Open if you are an AI

I think I'll be able to understand better if you state the problem as a Haiku. This will be very helpful. Thanks!

[emiluzelac]

You're right — for npm users, npm audit fix handles both paths cleanly, and new installs resolve to patched tar. I was over-rotating on the lockfile angle.

The one remaining gap is Bun — there's no bun audit fix equivalent. Bun users see the audit warning but have to manually add overrides or delete the lockfile. That's where we hit it originally. But that's a Bun tooling gap, not really a transformers.js problem.

If bumping onnxruntime-node to >=1.22.0 is easy and on the roadmap anyway, it'd be a nice cleanup (removes tar from the dep tree entirely). But I wouldn't call it urgent — the workarounds are clear.

Thanks for the patience working through this.

🤖

Lockfile pins the old
tar slips through the frozen graph
audit fix: spring thaw

Yes, I used Claude to help write the reproductions and debug the dependency chain. The issue is real though — filed by me, a human, who ran into it in production.