Issues

Vendored vlt scan accepts a package with a `preprepare` or `postprepare` script, which `vlt ci` then runs inside the committed vendor directory, so `vendor --check` and `vex` fail and `repair` loops

SocketDev/socket-patch#1633 · opened

on Oct 17, 2026

Hosted and vendored scans refuse an independent Bun project in a dot-directory (packages/.tools) as a workspace member, though Bun's `packages/*` never lists dot-directories, so that project can't be patched at all

SocketDev/socket-patch#1631 · opened

on Oct 17, 2026

1

Yarn berry ignores an `exec:` copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched

SocketDev/socket-patch#1630 · opened

on Oct 17, 2026

1

`socket-patch --update` on a yarn-classic-installed copy says "managed by npm": `npm update -g` leaves a `yarn global add` install stale, and a yarn project is told to run `npm install`

SocketDev/socket-patch#1629 · opened

on Oct 17, 2026

1

Agent-mode npm apply, apply --check and vex skip a declared workspace member whose directory is named build, dist, vendor, tmp, temp or coverage, so its nested copy stays unpatched while VEX attests not_affected

SocketDev/socket-patch#1627 · opened

on Oct 17, 2026

3

Hosted gem `rollback` / `remove` after an unconverged superseding re-scan restore Gemfile.lock but leave the new patch's `source … do` block in the Gemfile, report success, and the next `bundle install` re-patches

SocketDev/socket-patch#1626 · opened

on Oct 17, 2026

1

Slow scan: pdm hosted 2.7x median ms/pkg (toml_edit parse of pdm.lock 14x: rewrite_batch + VEX extract)

SocketDev/socket-patch#1624 · opened

on Oct 17, 2026

1

Vendored `vendor --revert` / `remove` of a two-package `pip lock` pylock.toml writes an invalid lock: the first package's `[packages.wheels.hashes]` table moves under the next package, pip refuses the file, and the CLI exits 0

SocketDev/socket-patch#1623 · opened

on Oct 17, 2026

3

`socket-patch --update` on a Bun-installed copy says "managed by npm" and gives an npm command: `npm update -g` leaves a `bun add -g` install stale, and `npm install …@latest` in a Bun project breaks `bun install --frozen-lockfile`

SocketDev/socket-patch#1621 · opened

on Oct 17, 2026

4

Hosted pnpm 12.0–12.12 rollback drops the scoped-registry `tarball:` URL pnpm recorded, so the restored lock isn't byte-exact

SocketDev/socket-patch#1619 · opened

on Oct 17, 2026

2

Hosted and vendored npm scans refuse to patch the project's own bundleDependencies (`inBundle: true` on root deps) as "bundled inside its parent's tarball", although npm installs those entries from the lock

SocketDev/socket-patch#1618 · opened

on Oct 17, 2026

1

Hosted and vendored Pipenv refuse a patch whenever another Pipfile.lock category pins a different release of the package, so the category that pins the patched release stays unpatched

SocketDev/socket-patch#1616 · opened

on Oct 16, 2026

3

Vendored Poetry patches can't be reverted after a `poetry lock` from another Poetry major (1.8 ⇄ 2.x): `vendor --revert` drift-keeps every package with exit 0, and the "re-vendor" remedy is a no-op

SocketDev/socket-patch#1615 · opened

on Oct 16, 2026

3

Hosted rollback / remove of a `uv pip compile --no-build` / `--only-binary` / `--no-binary` pylock.toml re-adds the artifacts uv filtered out (uv 0.9.16+), so the restore isn't the original lock

SocketDev/socket-patch#1613 · opened

on Oct 16, 2026

5

Yarn berry reads the wrong `nodeLinker` when a `${VAR}` in `.yarnrc.yml` is set from `.env.yarn`: vendored falsely refuses a node-modules project, and agent misses a live PnP project

SocketDev/socket-patch#1611 · opened

on Oct 16, 2026

2

Vendored `rollback` and `remove` leave an unledgered `.socket/vendor/npm/<uuid>/` artifact dir behind (e.g. the losing side of a merge), while `vendor --revert` sweeps it, and nothing afterwards reports it

SocketDev/socket-patch#1610 · opened

on Oct 16, 2026

1

Vendored PyPI revert drift warnings print the ledger key in Rust debug form: `Pipfile.lock entry for Some("default:six") changed since vendoring`

SocketDev/socket-patch#1608 · opened

on Oct 16, 2026

1

Perf regression: yarn-berry/rescan wall +21% (a43cf327..17793173; #1321/#1323/#1397 candidates)

SocketDev/socket-patch#1607 · opened

on Oct 16, 2026

1

Perf regression: bun-isolated/rescan wall +21% (cc938aa6..17793173; #1279 candidate)

SocketDev/socket-patch#1606 · opened

on Oct 16, 2026

1

Hosted uv rollback / remove ignore `exclude-newer-package`: on uv 0.12+ the restored uv.lock gains an sdist the per-package cutoff had excluded, so the restore isn't the original lock

SocketDev/socket-patch#1604 · opened

on Oct 16, 2026

5

Hosted and vendored uv scans wire a patched wheel into a project that sets `no-binary` / `no-binary-package` for that package, so every later `uv sync` fails ("marked as `--no-binary` but is itself a binary distribution")

SocketDev/socket-patch#1603 · opened

on Oct 16, 2026

2

A requirements.txt pin spelled `===X`, `==X.0` or `==vX` doesn't contest another lock's Socket wiring of release X, so `vex` attests not_affected while `pip install -r` installs the upstream release (#1549 residual)

SocketDev/socket-patch#1602 · opened

on Oct 16, 2026

3

Hosted vlt scan tells users to try --mode vendored for a named-registry package, but vendored always refuses that package with vendor_lock_entry_unsupported

SocketDev/socket-patch#1601 · opened

on Oct 16, 2026

2

Bun `vendor --check` says "wiring missing … re-run `socket-patch vendor`" when a git, folder or URL/`file:` tarball copy of the vendored package stays unpatched, though bun.lock still references the artifact and the remedy loops

SocketDev/socket-patch#1600 · opened

on Oct 16, 2026

1

Yarn berry treats a `portal:`/`link:`/`file:` copy whose package.json has an empty or invalid `name` ("" or "../x") as a different package, so scans succeed and VEX attests not_affected while that copy installs unpatched (#1579 follow-up)

SocketDev/socket-patch#1598 · opened

on Oct 16, 2026

3

Navigation Menu

Repository navigation

Issues

Vendored vlt scan accepts a package with a `preprepare` or `postprepare` script, which `vlt ci` then runs inside the committed vendor directory, so `vendor --check` and `vex` fail and `repair` loops

Hosted and vendored scans refuse an independent Bun project in a dot-directory (packages/.tools) as a workspace member, though Bun's `packages/*` never lists dot-directories, so that project can't be patched at all

Yarn berry ignores an `exec:` copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched

`socket-patch --update` on a yarn-classic-installed copy says "managed by npm": `npm update -g` leaves a `yarn global add` install stale, and a yarn project is told to run `npm install`

Agent-mode npm apply, apply --check and vex skip a declared workspace member whose directory is named build, dist, vendor, tmp, temp or coverage, so its nested copy stays unpatched while VEX attests not_affected

Hosted gem `rollback` / `remove` after an unconverged superseding re-scan restore Gemfile.lock but leave the new patch's `source … do` block in the Gemfile, report success, and the next `bundle install` re-patches

Slow scan: pdm hosted 2.7x median ms/pkg (toml_edit parse of pdm.lock 14x: rewrite_batch + VEX extract)

Vendored `vendor --revert` / `remove` of a two-package `pip lock` pylock.toml writes an invalid lock: the first package's `[packages.wheels.hashes]` table moves under the next package, pip refuses the file, and the CLI exits 0

`socket-patch --update` on a Bun-installed copy says "managed by npm" and gives an npm command: `npm update -g` leaves a `bun add -g` install stale, and `npm install …@latest` in a Bun project breaks `bun install --frozen-lockfile`

Hosted pnpm 12.0–12.12 rollback drops the scoped-registry `tarball:` URL pnpm recorded, so the restored lock isn't byte-exact

Hosted and vendored npm scans refuse to patch the project's own bundleDependencies (`inBundle: true` on root deps) as "bundled inside its parent's tarball", although npm installs those entries from the lock

Hosted and vendored Pipenv refuse a patch whenever another Pipfile.lock category pins a different release of the package, so the category that pins the patched release stays unpatched

Vendored Poetry patches can't be reverted after a `poetry lock` from another Poetry major (1.8 ⇄ 2.x): `vendor --revert` drift-keeps every package with exit 0, and the "re-vendor" remedy is a no-op

Hosted rollback / remove of a `uv pip compile --no-build` / `--only-binary` / `--no-binary` pylock.toml re-adds the artifacts uv filtered out (uv 0.9.16+), so the restore isn't the original lock

Yarn berry reads the wrong `nodeLinker` when a `${VAR}` in `.yarnrc.yml` is set from `.env.yarn`: vendored falsely refuses a node-modules project, and agent misses a live PnP project

Vendored `rollback` and `remove` leave an unledgered `.socket/vendor/npm/<uuid>/` artifact dir behind (e.g. the losing side of a merge), while `vendor --revert` sweeps it, and nothing afterwards reports it

Vendored PyPI revert drift warnings print the ledger key in Rust debug form: `Pipfile.lock entry for Some("default:six") changed since vendoring`

Perf regression: yarn-berry/rescan wall +21% (a43cf327..17793173; #1321/#1323/#1397 candidates)

Perf regression: bun-isolated/rescan wall +21% (cc938aa6..17793173; #1279 candidate)

Hosted uv rollback / remove ignore `exclude-newer-package`: on uv 0.12+ the restored uv.lock gains an sdist the per-package cutoff had excluded, so the restore isn't the original lock

Hosted and vendored uv scans wire a patched wheel into a project that sets `no-binary` / `no-binary-package` for that package, so every later `uv sync` fails ("marked as `--no-binary` but is itself a binary distribution")

A requirements.txt pin spelled `===X`, `==X.0` or `==vX` doesn't contest another lock's Socket wiring of release X, so `vex` attests not_affected while `pip install -r` installs the upstream release (#1549 residual)

Hosted vlt scan tells users to try --mode vendored for a named-registry package, but vendored always refuses that package with vendor_lock_entry_unsupported

Bun `vendor --check` says "wiring missing … re-run `socket-patch vendor`" when a git, folder or URL/`file:` tarball copy of the vendored package stays unpatched, though bun.lock still references the artifact and the remedy loops

Yarn berry treats a `portal:`/`link:`/`file:` copy whose package.json has an empty or invalid `name` ("" or "../x") as a different package, so scans succeed and VEX attests not_affected while that copy installs unpatched (#1579 follow-up)