Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host

[mikolalysenko]

[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).

Summary

On yarn berry, hosted mode pins a patched dependency as <name>@npm:<v>::__archiveUrl=<hosted tgz> (crates/socket-patch-core/src/patch/redirect/mod.rs:3459). Yarn handles that locator with its npm fetcher, so it attaches the npm registry's credentials to the request, even though the request goes to the hosted patch server and not to the registry. These cases all send Authorization: Bearer <npm token> to the patch host:

• any scoped package (@scope/name) when an npmAuthToken is configured. Yarn uses best-effort auth for scoped idents, so npmAlwaysAuth isn't needed. That covers the top-level npmAuthToken in .yarnrc.yml, the YARN_NPM_AUTH_TOKEN env var that CI commonly sets, and npmScopes.<scope>.npmAuthToken;
• every hosted package, scoped or not, when npmAlwaysAuth: true is set. That's the usual setup for Artifactory / Nexus / GitHub Packages proxies.

Impact

• A private-registry or npm publish token is disclosed to patch.socket.dev (or to any --patch-server-url host) on every cold-cache install of a hosted-patched package. CI is affected on every run. The user never configured that host to receive the token, and nothing in the docs mentions it.
• npm, pnpm and yarn classic scope registry auth to the registry's host, so this is berry-specific. It comes from the locator form that hosted mode picks.
• Scoped packages (@babel/*, @types/*, @isaacs/* …) are a large share of the patchable npm surface.

Repro (Linux, yarn 4.12.0 / 4.18.1 / 4.0.2; mock patch API logging the Authorization header on the tarball route)

mkdir proj && cd proj
echo '{"name":"app","version":"1.0.0","private":true,"dependencies":{"@isaacs/string-locale-compare":"1.1.0","left-pad":"1.3.0"}}' > package.json
printf 'nodeLinker: node-modules\nenableGlobalCache: false\n' > .yarnrc.yml
yarn install
socket-patch scan --json --yes --api-url http://127.0.0.1:18080 --org test-org --api-token fake   # hosted (default): redirected 2
# fresh checkout, cold cache:
mkdir ../fresh && cp package.json yarn.lock ../fresh/ && cd ../fresh
printf 'nodeLinker: node-modules\nenableGlobalCache: false\nunsafeHttpWhitelist:\n  - "127.0.0.1"\n' > .yarnrc.yml
YARN_NPM_AUTH_TOKEN=ENV-CI-TOKEN YARN_GLOBAL_FOLDER=$(mktemp -d) yarn install --immutable

What the patch host received:

GET /patch/npm/@isaacs/string-locale-compare/1.1.0/<token>/<uuid>/…tgz   Authorization: Bearer ENV-CI-TOKEN
GET /patch/npm/left-pad/1.3.0/<token>/<uuid>/left-pad-1.3.0.tgz          Authorization: (none)

With npmAuthToken: "ALWAYS-TOKEN" and npmAlwaysAuth: true in .yarnrc.yml, both requests carry Bearer ALWAYS-TOKEN. The installs themselves succeed and get the patched bytes.

Expected vs actual

• Expected: a hosted redirect shouldn't cause installs to disclose registry credentials to a host the user never set up for them. The CLI contract already holds hosted fetches to this standard elsewhere: the vlt artifact probe is specified as "no Authorization" (CLI_CONTRACT.md, redirect_vlt_artifact_unverifiable). If the berry locator form can't avoid it, hosted mode should at least detect a configured npmAuthToken / npmAlwaysAuth (.yarnrc.yml, env) and warn or refuse, and docs/ecosystems.md "yarn berry" plus docs/testing/yarn-berry-compatibility.md should document it.
• Actual: the token is sent silently, and the run reports plain success.

Matrix

OS	yarn	scoped + npmAuthToken / YARN_NPM_AUTH_TOKEN	scoped + npmScopes token	unscoped + npmAuthToken	any + npmAlwaysAuth: true
Linux	4.0.2 (bare-hex lock)	sent (env)	untested	—	untested
Linux	4.12.0	sent	untested	not sent	sent
Linux	4.18.1 (lock version: 10)	sent (rc and env)	sent	not sent	sent
macOS / Windows	—	untested. The behaviour is in yarn's JS fetcher (npmHttpUtils.get takes auth from the configured registry, not from the URL origin), so it shouldn't depend on the OS

Yarn 2/3 aren't reachable: hosted mode refuses cacheKey 7/8.

First bad: main 2463257. Release 4.0.0 writes the same ::__archiveUrl= locator for berry, so it should behave the same; I didn't re-run the token capture against it.

Suspect code

• crates/socket-patch-core/src/patch/redirect/mod.rs:3459: the {fname}@npm:{}::__archiveUrl={} resolution written by rewrite_yarn_berry (line 3238). There's no gate on registry auth config next to the other berry project gates in preflight_yarn_berry_hosted (around line 3195).

[mikolalysenko]

[agent] Triaged: priority:p1 (yarn berry). This is a security issue: registry credentials go to a third-party host. Not a duplicate. #399 (Composer transport-options auth sent to the hosted URL) is the same class of bug, but it's in a different rewriter with a different mechanism, so I'm not clustering them. The berry locator is still written at crates/socket-patch-core/src/patch/redirect/mod.rs:3459 on main 2463257, and I found no gate on npmAuthToken/npmAlwaysAuth.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (shared root cause: the yarn berry hosted redirect pins through an npm: locator, so yarn's npm fetcher attaches registry credentials to the patch-host request). Branch: agent/fix-yarn-berry-hosted-auth-leak. Claim-ID: 2026-10-01T12:21:53Z-b1686f

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #465

---

Generated by Claude Code

[mikolalysenko]

[agent] The fix in #465 is blocked on a maintainer decision. The tarball-URL pin stops the token leak, but yarn's hardened mode (automatic on public-PR CI) rejects it with YN0078. A package.json resolutions-based pin works in every mode, but it would change hosted mode to edit package.json. Measurements and options: #465 (comment)

---

Generated by Claude Code