fix(security): bump toml 3.0.0 → 4.3.0 (root lockfile) — closes 4 Dependabot alerts

[benfrank241]

Recreates Dependabot's toml security fix on a human-authored branch so it actually gets CI. Dependabot's own PR (#39) cannot pass: its branches don't receive secrets.VECTORIZE_TOKEN / VECTORIZE_ORG / GITLEAKS_LICENSE, so Tests (TS) fails with Error: VECTORIZE_API_KEY must be set and Secret Detection fails on the missing licence — no dependency signal at all.

Alerts closed

Alert	Advisory	Severity	Patched in
#46, #48	GHSA-v5mp-jgw5-2x6j / CVE-2026-63376 — Object.prototype pollution from a crafted TOML string	high	4.1.2
#47, #49	GHSA-82x6-q7mm-w9cf — stack-overflow DoS via deeply nested arrays / inline tables	high	4.2.0

(Two alerts per advisory: GitHub raises one against package.json and one against package-lock.json.)

Change

toml is a direct dependency of the root package.json and the only requester in the tree, so this is a plain direct bump — no overrides entry needed.

"toml": "^3.0.0"  ->  "^4.2.0"      # resolves to 4.3.0

Lockfile regenerated with npm install --package-lock-only. Diff is 2 files / 9 insertions / 6 deletions and touches nothing but toml.

⚠️ This is a MAJOR bump — flagged for human review

3.x → 4.x. The patched versions exist only on the 4.x line, so there is no in-range fix. What that major carries:

• 4.0.0 modernised tooling and moved to the TOML v1.0.0 spec (was v0.4-era), 4.1.0 added v1.1.0 support.
• engines now declares node >=20. CI pins node-version: "20.x", so this is satisfied — but it is a new constraint on anyone running the release scripts locally.
• No new transitive dependencies (toml@4.3.0 has zero deps).

Verification

The root package.json has no build / test / lint scripts, and CI's Tests (TS) / Tests (Python) jobs build src/ts and src/python — neither touches the root lockfile. The root toml dependency is consumed only by scripts/readToml.js and scripts/editToml.js (both use exactly one API, toml.parse), which back npm run read-toml / npm run edit-toml and are called from scripts/release-python.sh and scripts/generate-python.sh.

So verification was derived from that actual consumer surface, against an unmodified main control worktree:

1. npm ci clean on both sides; resolved version confirmed 4.3.0.
2. npm run read-toml on src/python/pyproject.toml and tests/python/pyproject.toml — output identical to the toml@3 baseline (0.4.0, 0.1.0).
3. npm run edit-toml round-trip (scalar version, plus a list-mode keywords rewrite through @iarna/toml stringify) — emitted file is byte-identical to the toml@3 baseline (md5 69abb882… on both).
4. Parse-equivalence across every .toml in the repo (src/python/pyproject.toml, tests/python/pyproject.toml, tests/python/poetry.toml) — parsed objects JSON-identical under 3.0.0 and 4.3.0.
5. Advisory behaviour confirmed fixed — a 200 000-level nested array makes 3.0.0 die with an uncatchable RangeError: Maximum call stack size exceeded, while 4.3.0 raises an ordinary, catchable parse error (Maximum nesting depth of 500 exceeded). The bound is configurable via toml.parse(input, { maxDepth }) if any real document ever needs it.

Notes

• Supersedes Dependabot PR Bump toml from 3.0.0 to 4.2.0 #39 (same upgrade, but stuck red for missing secrets) — that one can be closed once this merges.
• One further advisory is present in this lockfile but is out of scope here and has no Dependabot alert: yaml@2.7.0 (dev-only, via typedoc), GHSA-48c2-rrv3-qjmp, moderate, fixed in 2.8.3. Recorded in the sweep backlog issue rather than mixed into this PR.
• Opened by the daily security sweep. Not merged — merging is the maintainer's call.

[benfrank241]

CI triage — Tests (TS) is red, and it is not this change

Posting the evidence rather than asking anyone to take it on trust.

What the checks did

Check	On Dependabot's #39	On this branch
Secret Detection	❌ fail (no GITLEAKS_LICENSE)	✅ pass
Tests (TS)	❌ fail — never ran a test (Error: VECTORIZE_API_KEY must be set)	❌ fail — tests execute, 6 fail against the live dev API
Tests (Python)	❌ fail — same missing-secret error	(long-running live suite)

The Secret Detection flip from fail to pass is the point of moving this to a human-authored branch: secrets.* reach chore/* branches and do not reach dependabot/* ones. The TS job likewise now gets far enough to actually run tests, which #39 never did.

The 6 TS failures

No variant of CreateSourceConnectorRequest      exists with 'type=FILE_UPLOAD'
No variant of CreateSourceConnectorRequest      exists with 'type=WEB_CRAWLER'
No variant of CreateDestinationConnectorRequest exists with 'type=PINECONE'
No variant of CreateAIPlatformConnectorRequest  exists with 'type=OPENAI'
Test timed out in 120000ms                                  (tests/extraction.test.ts:13)
Cannot read properties of undefined (reading 'text')        (tests/pipelines.test.ts:150)

The first four are thrown from inside the generated client (src/ts/dist/models/Create*ConnectorRequest.js) — the discriminator mapping in the generated code no longer matches what the tests send, i.e. drift between vectorize_api.json / the generated src/ts and the live dev API.

The last one is a bug in the test's own error handler, and it is masking whatever the real failure was:

// tests/pipelines.test.ts:149-150
console.error(error?.response);
console.error(await error?.response.text());   // <- `?.` then an unguarded `.`

When error.response is undefined the first line prints undefined and the second throws TypeError, replacing the original error. Worth a separate fix (error?.response?.text()), unrelated to this PR.

Why none of it can be this diff

1. Path-level. This PR changes exactly two files, both at the repo root:

   $ git diff origin/main..chore/security-daily-20260904-vectorize-clients-npm-root --name-only
   package-lock.json
   package.json
   $ git diff origin/main..chore/security-daily-20260904-vectorize-clients-npm-root -- src/ts tests/ts
   (empty)
   

   The Tests (TS) job runs only cd src/ts && npm install && npm run build, then cd tests/ts && npm i && npm run test. tests/ts depends on file:../../src/ts and neither directory references the root manifest, so the job's entire dependency closure is byte-identical to main. The root toml dependency is reachable only from scripts/readToml.js / scripts/editToml.js, which CI never invokes.

2. Historical control. There is no green baseline to diff against — ci.yml triggers on pull_request only, so it never runs on main, and all 100 recorded ci.yml runs are failure. The most recent human-authored branch run, where secrets were available (develop, 2025-07-18, run 16379415802), was likewise Tests (TS) failure / Tests (Python) success. TS has been red on human branches for roughly 14 months.

3. Local verification of the part that this diff can affect is in the PR description: identical read-toml output, byte-identical edit-toml round-trip, JSON-identical parse of every .toml in the repo, and a behavioural demonstration that the DoS advisory is actually fixed — all against an unmodified main control worktree.

One gap, stated plainly: I wanted a same-day control (a no-op branch off today's main, to show these exact 6 failures reproduce on unmodified code right now). Pushing that control branch was blocked by a permission policy on my side, so the freshest same-branch-type control I can point to is the 2025-07-18 develop run above. Points 1 and 3 do not depend on it.

Suggested follow-ups (tracked in #41, not in this PR)

• Add VECTORIZE_TOKEN / VECTORIZE_ORG / GITLEAKS_LICENSE as Dependabot secrets so Dependabot's own security PRs become self-verifying, or make the integration tests skip cleanly without credentials.
• Regenerate the TS client against the current spec to clear the No variant of … drift.
• Fix error?.response.text() → error?.response?.text() so real failures stop being masked.
• Rename one of the two workflows — ci.yml and docs.yml are both name: CI, which makes gh run list output ambiguous.

[benfrank241]

Tests (Python) finished — also red, and the root cause is billing, not code

It ran for 3h 31m and failed. Adding it here for completeness, because the cause turns out to be more interesting than the TS one.

FAILED tests/test_client.py::test_get_pipelines            - ApiException: (402)
FAILED tests/test_client.py::test_delete_system_connectors - ApiException: (402)
FAILED tests/test_client.py::test_upload_create_pipeline   - ApiException: (402)
FAILED tests/test_client.py::test_extraction              - ServiceException: (502)
======================= 4 failed in 12668.85s (3:31:08) ========================

The 402 body is:

{"code":"UPGRADE_REQUIRED"}   //  HTTP 402 Payment Required

402, not 401 — so VECTORIZE_TOKEN is authenticating fine; the CI service account has lost API access on its plan. No code change can make this suite pass.

Two things worth flagging:

1. This is not specific to this repo. The identical failure — HTTP 402 with code: UPGRADE_REQUIRED from api.vectorize.io — took out the LangChain Unit Tests workflow on vectorize-io/integrations-python on 2026-09-02 (all five matrix legs, raised in the session fixture). Two repos, same API account, same symptom. It looks org-wide rather than per-repo, so it's probably worth someone checking the plan on whichever account backs VECTORIZE_TOKEN in CI — otherwise every repo whose tests hit the live API has a permanently unpassable gate.

2. The Build step passed. cd src/python && poetry install && poetry build succeeded; only the live-API Tests step failed. That is the entire portion of this job with any relationship to packaging.

As with the TS job, this cannot be attributed to the diff in this PR:

$ git diff origin/main..chore/security-daily-20260904-vectorize-clients-npm-root -- src/python tests/python
(empty)

tests/python/pyproject.toml declares vectorize-client = {path = "../../src/python"} and never references the root manifest.

Also worth noting for whoever picks this up: test_extraction burned roughly 3.5 hours before failing, despite carrying @pytest.mark.timeout(60). The timeout is clearly not being enforced on whatever it blocks in (the TS suite hit the same wall as Test timed out in 120000ms on tests/extraction.test.ts). A job-level timeout-minutes in ci.yml would stop a stuck run from occupying a runner for hours.

Net for this PR: all three checks are accounted for. Secret Detection passes. Tests (TS) fails on generated-client/spec drift, Tests (Python) fails on an expired API plan — both pre-existing, both provably outside this diff, which touches only the root package.json / package-lock.json.