Grype backlog: 10 published servers fail the vulnerability gate, several fixable via spec.constraints/overrides

[danbarr]

Context

#669 touches cmd/dockhand/**, which triggers a full catalog rebuild. That rebuild ran the Grype gate against every server for the first time in a while and 11 build-containers jobs failed: 10 on Run Grype vulnerability scanner, and browserbase-mcp-server additionally on Build and push Docker image.

These are not caused by #669. For any spec without overrides/constraints the injection is a strict no-op: the generated Dockerfile is byte-identical between that branch and main. The full rebuild simply re-scanned images whose vulnerabilities had accrued since their last build.

That is the underlying dynamic worth noting: a server is only rebuilt when its own spec.yaml changes (or cmd/dockhand, go.mod, or the workflow), so newly published advisories against an already-built image go unnoticed until something unrelated forces a rebuild. The published images on GHCR carry these findings today.

Findings by server

Server	High/Critical findings
npx/brightdata-mcp	@modelcontextprotocol/sdk x3 (high)
npx/astra-db-mcp	undici x3 (high)
npx/browserbase-mcp-server	sharp (high), plus a separate build failure
npx/mcp-server-neon	~34 across next (1 critical), axios, lodash, postcss, sharp, @modelcontextprotocol/sdk
npx/onchain-mcp	@modelcontextprotocol/sdk x2 (high)
npx/mcp-jetbrains	fails the gate; specific packages need reading from the run's SARIF (no code-scanning alerts landed for this category)
uvx/chroma-mcp	mcp x5 (high)
uvx/mcp-neo4j-cypher	fastmcp (1 critical, 1 high)
uvx/mcp-neo4j-aura-manager	fastmcp (1 critical, 1 high)
uvx/mcp-neo4j-memory	fastmcp (1 critical, 1 high)

uvx/adb-mysql-mcp-server also fails, split out as #828 since it is unblocked by #669 directly.

Relationship to #668

Two of these are the original cases #668 was opened for:

• brightdata-mcp is the chore(deps): update dependency @brightdata/mcp to v2.11.1 #469 case: @modelcontextprotocol/sdk hard-pinned to 1.21.2, fixes at >=1.24. Confirmed still 3 high findings.
• mcp-neo4j-cypher is the chore(deps): update dependency mcp-neo4j-cypher to v0.6.0 #528 case: fastmcp capped below the fixed version.

Two refinements to what #668 recorded:

• The fastmcp cap affects all three neo4j servers (cypher, aura-manager, memory), not just cypher.
• mcp-clickhouse (chore(deps): update dependency mcp-clickhouse to v0.4.1 #527) currently passes, because main still ships 0.2.0. It regresses the moment that renovate bump lands, which is what chore(deps): update dependency mcp-clickhouse to v0.4.1 #527 was blocked on.

Newly identified as the same shape:

• chroma-mcp hard-pins mcp[cli]==1.6.0, while its 5 high findings are fixed across 1.9.4, 1.10.0, 1.23.0, 1.27.2, and 1.28.1. An exact pin excluding every fix, so an override candidate.

Different shape, likely not override territory:

• mcp-server-neon has ~34 high/critical across a broad dependency tree. That reads as a badly stale upstream release rather than one cap, and probably wants an upstream bump or a version reassessment.
• browserbase-mcp-server has a genuine build failure that needs fixing before its sharp finding matters.

Proposed work

1. Per-server triage: for each, determine whether an upstream pin/cap excludes the fix (use spec.constraints/spec.overrides from feat(dockhand): support transitive dependency overrides/constraints in spec.yaml #669) or whether the server needs an upstream version bump.
2. Where an override is used, follow the caution in docs/adding-servers.md and functionally test, especially when forcing across a major boundary.
3. Consider whether the gate should run more often than "when something forces a rebuild", since that is what let this backlog build up.

The weekly periodic-security-scan workflow was supposed to be the safety net here, but its critical-finding alerting is broken. Tracked in #829.

[danbarr]

uvx half: triaged

chroma-mcp fixed. It exact-pins mcp[cli]==1.6.0, which excludes every fix for its 5 high findings. Constrained to mcp[cli]>=1.28.1,<2: 1.28.1 is the lowest version clearing all five, and a smaller bump to 1.23.0 would have newly exposed GHSA-hvrp-rf83-w775 (high, >=1.23.0,<=1.27.1) which 1.6.0 predates. Capped <2 so uv cannot resolve the mcp 2.x major, which is the same break that took out adb-mysql-mcp-server. Verified: grype clean where it previously reported 5 high, and all 13 tools still enumerate as SAFE in the scan.

The three neo4j servers are not override-fixable. Recommend removing them from this issue's scope and tracking upstream instead.

Every fastmcp advisory below 3.2.0 is patched only at 3.2.0, with no 2.x backport, so the fix necessarily crosses the 2.x to 3.x major boundary. Upstream caps fastmcp<3. Forcing 3.x was tested on mcp-neo4j-cypher:

• docker build succeeds
• import mcp_neo4j_cypher succeeds (fastmcp 3.4.6)
• create_mcp_server(driver) then raises TypeError: FastMCP() no longer accepts 'stateless_http'

All three call FastMCP(..., stateless_http=True), and fastmcp 3.x removed that constructor kwarg with a hard raise. So the override produces an image that builds and imports cleanly but cannot start the server. These need an upstream release that drops the kwarg and lifts the cap, not a spec-level override.

Worth flagging separately: this failure mode would not have been caught by CI. All three neo4j servers set security.insecure_ignore: true, so mcp-scan cannot enumerate their tools and would have passed the broken override through. The "scan also validates the override" property from #831 only holds for scannable servers.

adb-mysql-mcp-server is handled in #828. npx triage still in progress.