fix(security): bump vitest 4.1.8 → 4.1.11 in tests/ts — closes alerts #50, #51 (GHSA-82fw-gwwq-j7x9)

[benfrank241]

Recreates Dependabot's @vitest/mocker security fix (PR #42) on a human-authored branch so it actually receives secrets.VECTORIZE_TOKEN / VECTORIZE_ORG. Dependabot's own branch gets empty secrets, so both its jobs die at Error: VECTORIZE_API_KEY must be set before any dependency signal is produced.

Alerts closed

Alert	Advisory	Severity	Package	Patched in
#50	GHSA-82fw-gwwq-j7x9	moderate	@vitest/mocker	4.1.11
#51	GHSA-82fw-gwwq-j7x9	moderate	vitest (ancestor)	4.1.11

Path traversal / arbitrary file read via @vitest/mocker redirect mocks; 4.1.11 restricts redirect mocks to the fs allowlist.

Bonus, not alerted: the re-lock also carries nanoid 3.3.16 → 3.3.19, clearing GHSA-2v37-7h3g-55p8 (high, dev-only). That advisory is alert #44, which this repo's policy auto-dismissed on 2026-08-16, and it was previously recorded in #41 as unverifiable locally. It is fixed here as a side effect of vitest's dependency graph moving forward — no separate change was made for it.

npm audit in tests/ts goes 3 vulnerabilities (1 high, 2 moderate) → 0.

Change

vitest is a direct devDependency of tests/ts. The patched version is in range of the existing ^4.1.8, so a lockfile-only update would have sufficed; the manifest floor is raised to ^4.1.11 anyway so the vulnerable range is unreachable from the manifest, not just pinned away by the lockfile. This matches Dependabot #42 exactly, so that PR can be closed once this merges.

Lockfile churn beyond the @vitest/* family is vitest 4.1.11 pulling its build stack forward and is unavoidable: vite 8.0.16 → 8.3.0, rolldown 1.0.3 → 1.2.8 (+ all @rolldown/binding-*), lightningcss 1.32.0 → 1.33.0 (+ bindings), postcss 8.5.25 → 8.5.28, picomatch, nanoid, tinyrainbow, @oxc-project/types, @jridgewell/sourcemap-codec. The @rolldown/binding-wasm32-wasi entry and its @emnapi/* / @napi-rs/wasm-runtime / @tybys/wasm-util / tslib support tree drop out; @rolldown/binding-android-arm-eabi is added. Nothing outside that set changed.

Lockfile provenance

Re-locked with npm install --package-lock-only --ignore-scripts from the committed lockfile — no --force, no --legacy-peer-deps, no regeneration from scratch. Two things worth flagging for review:

• npm 10 crashes re-resolving this tree. npm install / npm update on tests/ts with the bumped manifest dies with TypeError: Cannot read properties of null (reading 'edgesOut') in arborist's #loadPeerSet, while walking vitest@4.1.11's optional peer set (@vitest/browser-playwright, @vitejs/devtools-vitest). Reproduced on npm 10.9.8 and on 10.8.2 (the version CI's node-version: 20.x ships). npm 11 resolves the same tree cleanly, so the lockfile here was produced with npm 11. This does not affect CI: CI only ever runs npm i against a lockfile that already matches the manifest, which needs no re-resolution — verified below. It does mean the next person to re-lock tests/ts on npm 10 will hit this.
• libc markers. The lockfile carries 10 "libc": ["glibc"|"musl"] keys on the new lightningcss-linux-* / @rolldown/binding-linux-* entries — byte-for-byte the same set Dependabot produced in Bump @vitest/mocker and vitest in /tests/ts #42. npm 10 silently strips these on any write (npm i on this branch removes all 10). They are kept deliberately; do not re-lock on npm 10 and commit the result.

Verification

ci.yml has never been green in this repo — all 23 recorded runs of that workflow are failures, because both jobs end in live integration tests against api-dev.vectorize.io. A true-green verify is not obtainable, so this was verified differentially against an unmodified main control worktree at the same commit (62a4e1c), running CI's exact command chain on both sides.

Step (CI equivalent)	control (main, vitest 4.1.8)	this branch (vitest 4.1.11)
cd src/ts && npm install	exit 0	exit 0
cd src/ts && npm run build (tsc)	exit 0	exit 0
cd tests/ts && npm i	exit 0	exit 0
cd tests/ts && npm ci (strict lockfile check)	—	exit 0, lockfile unmodified
cd tests/ts && npm run test (vitest run)	exit 1	exit 1
npm audit	3 vulns (1 high, 2 moderate)	0 vulns

Test failure sets are identical — same 4 files, same 6 tests, one root cause on both sides:

FAIL  tests/connectors.test.ts > connector > ai platform lifecycle
FAIL  tests/connectors.test.ts > connector > destination connector lifecycle
FAIL  tests/connectors.test.ts > connector > source lifecycle
FAIL  tests/extraction.test.ts > extraction > verify iris extraction
FAIL  tests/pipelines.test.ts > pipelines > verify pipeline lifecycle
FAIL  tests/uploads.test.ts > uploads > verify uploads lifecycle
Error: VECTORIZE_API_KEY must be set

Banners confirm the runner actually changed (RUN v4.1.8 vs RUN v4.1.11), so 4.1.11 loads, transforms and executes the suite. The bump introduces no new failure. Any red check on this PR should be read against that baseline.

Expected CI outcome, and what it will tell us

This branch does get secrets, so it will authenticate and reach the dev API — which is where the repo's two standing environment problems live. Both are pre-existing and unrelated to this change:

• HTTP 402 UPGRADE_REQUIRED — {"error":"Upgrade Required","message":"API access is available on paid plans only","code":"UPGRADE_REQUIRED"}. Last seen on fix(security): bump toml 3.0.0 → 4.3.0 (root lockfile) — closes 4 Dependabot alerts #40's run on 2026-09-04, and the same signature hit integrations-python on 2026-09-02. The CI credential or its org appears to have lost paid API access. Note the diagnostic: on fix(security): bump toml 3.0.0 → 4.3.0 (root lockfile) — closes 4 Dependabot alerts #40 the packaging-adjacent steps (Install client → npm install && npm run build; Python Build → poetry install && poetry build) all passed, and only the live-API test steps failed. Same shape on Bump @vitest/mocker and vitest in /tests/ts #42.
• test_extraction has no timeout and no failure ceiling — on fix(security): bump toml 3.0.0 → 4.3.0 (root lockfile) — closes 4 Dependabot alerts #40 it polled not ready ready=False from 15:13 to 18:43 (3h31m) before dying on a 502, producing a 17.5 MB job log. Tracked in Daily security sweep — backlog #41. A multi-hour red here is that, not a hang caused by a dependency bump.

If this PR's Tests (Python) job shows 402 again, that is a fresh data point that the paid-API access problem is still live 10 days on, and it needs an owner independent of this bundle.

Notes

• Supersedes Dependabot PR Bump @vitest/mocker and vitest in /tests/ts #42 (identical upgrade, stuck red for missing secrets) — close it once this merges.
• Separately open and unaffected: fix(security): bump toml 3.0.0 → 4.3.0 (root lockfile) — closes 4 Dependabot alerts #40 (toml 3.0.0 → 4.3.0, root lockfile, alerts #46–#49). Different lockfile, no conflict with this PR.
• Opened by the daily security sweep. Not merged — merging is the maintainer's call.

[benfrank241]

CI results — differential against baseline

Secret Detection passes here (it fails on every Dependabot branch, including #42 for this same upgrade). That is the missing-GITLEAKS_LICENSE effect, and it is the first direct confirmation in this repo that the human-authored branch gets the secrets Dependabot's does not.

Tests (TS) is red, as it is on every run of this workflow, but it is strictly better than the baseline and contains no new failure:

	#40 (main-based human branch, 2026-09-04)	#43 (this PR, vitest 4.1.11)
npm i in tests/ts	ok	ok — added 48 packages, no re-resolution, no edgesOut
connectors.test.ts	3 failed	3 failed — same errors
pipelines.test.ts	1 failed	1 failed — same error
uploads.test.ts	1 failed	1 failed — same error
extraction.test.ts	1 failed, 120006ms (timeout)	passed, 27288ms
total	4 files failed (4), 6 tests failed	3 failed | 1 passed, 5 failed | 1 passed

The 5 remaining failures are the pre-existing discriminator drift between the generated TS client and the dev API, unchanged and unrelated to vitest:

Error: No variant of CreateSourceConnectorRequest exists with 'type=WEB_CRAWLER'
Error: No variant of CreateAIPlatformConnectorRequest exists with 'type=OPENAI'
Error: No variant of CreateDestinationConnectorRequest exists with 'type=PINECONE'
Error: No variant of CreateSourceConnectorRequest exists with 'type=FILE_UPLOAD'
TypeError: Cannot read properties of undefined (reading 'text')   (pipelines)

all thrown inside src/ts/dist/models/*ToJSONTyped — generated client code, not test-runner code. vitest 4.1.11 loaded, transformed and ran all four files.

Worth noting separately: extraction.test.ts passing in 27s is the first time it has completed in this workflow. On #40 it timed out at 120s in TS and ran 3h31m in Python before a 502. No 402 UPGRADE_REQUIRED appears anywhere in this TS job, and the extraction path reached the dev API and got real data back — so paid API access may have been restored since 2026-09-04. Tests (Python) is still running and is the job that actually surfaced the 402; its result is the one to check. I'll leave that to whoever picks this up rather than claim it either way from the TS job alone.

[benfrank241]

Tests (Python) result — the 402 is still live

Answering the question left open above: yes, 402 UPGRADE_REQUIRED is still happening, 10 days after it was first seen on #40.

FAILED tests/test_client.py::test_get_pipelines          - ApiException: (402) Reason: Payment Required
FAILED tests/test_client.py::test_delete_system_connectors - ApiException: (402) Reason: Payment Required
FAILED tests/test_client.py::test_upload_create_pipeline  - ApiException: (402) Reason: Payment Required
{"success":false,"error":"Upgrade Required","message":"API access is available on paid plans only. Please upgrade to use this endpoint.","code":"UPGRADE_REQUIRED"}
========================= 3 failed, 1 passed in 21.16s =========================

This branch authenticates fine — Build (poetry install && poetry build) passes, the client reaches the API, and the API answers 402. So this is an account/plan problem on the CI credential's org, not a secrets problem and not a dependency problem. It needs an owner independent of this PR; nothing in a lockfile can fix it.

Against the #40 baseline, Python is also better, not worse:

	#40 (2026-09-04)	#43 (today)
test_get_pipelines	FAILED (402)	FAILED (402)
test_delete_system_connectors	FAILED (402)	FAILED (402)
test_upload_create_pipeline	FAILED (402)	FAILED (402)
test_extraction	polled not ready 15:13 → 18:43, died on 502	passed
job wall time	3h31m	2m23s

So test_extraction completed on both sides today (27s in TS, ~8s in Python). The 3h31m burn on #40 was the dev API being unresponsive that day, not a permanent state — but the underlying defect from #41 is unchanged: that test polls a ready-flag with no timeout and no failure ceiling, so the next unresponsive day costs another multi-hour run and another 17 MB log.

Net across both jobs: every failure on this PR is pre-existing and reproduces identically on unmodified main; extraction is the only test whose status changed, and it changed from red to green. No failure here is attributable to vitest 4.1.11.