Skip to content

fix: clear the Grype vulnerability backlog via spec overrides - #833

Merged
danbarr merged 6 commits into
mainfrom
fix/grype-backlog
Aug 5, 2026
Merged

fix: clear the Grype vulnerability backlog via spec overrides#833
danbarr merged 6 commits into
mainfrom
fix/grype-backlog

Conversation

@danbarr

@danbarr danbarr commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Uses the override mechanism from #669 / #831 to clear 6 of the 10 servers failing the build-containers Grype gate. The other 4 turned out not to be override-shaped; details below.

Closes #828
Closes #830

Fixed

Server Override Findings cleared
uvx/adb-mysql-mcp-server cryptography>=50.0.0 1 high
uvx/chroma-mcp mcp[cli]>=1.28.1,<2 5 high
npx/brightdata-mcp SDK 1.26.0 3 high
npx/mcp-jetbrains SDK 1.26.0 2 high
npx/astra-db-mcp undici 6.28.0 3 high
npx/browserbase-mcp-server sharp 0.35.3, undici 6.28.0 4 high

Every one is an upstream pin or cap that excludes the available fix, which is exactly the case #668 described. Each reason field records the pin, the advisories, and why that specific target version.

Version selection

Picking the minimum fixed version is wrong more often than not, because a small bump can step into an advisory the pinned version predated. Concrete cases here:

  • brightdata and jetbrains: the two highs are fixed at 1.24.0 and 1.25.2, but GHSA-345p-7cg4-v4c7 affects >=1.10.0,<=1.25.3, which the pinned 1.21.2 / 1.7.0 escape. 1.25.2 would trade two advisories for a third, so 1.26.0.
  • chroma-mcp: five advisories are cleared by 1.28.1, but a smaller bump to 1.23.0 would newly expose GHSA-hvrp-rf83-w775 (>=1.23.0,<=1.27.1).
  • astra-db and browserbase: undici 5.x is EOL so the fixes only exist in 6.x. Pinned to 6.28.0, the last 6.x, deliberately stopping short of 7.x-only advisories.
  • chroma-mcp is capped <2 because mcp 2.0.0 removed the module the server imports, which is the failure that started all of this.

Three are cross-major forces (undici 5 to 6 twice, sharp 0.33 to 0.35) and are flagged as such in their reasons.

Verification

Per server: dockhand build then docker build then grype --fail-on high --only-fixed from the repo root so .grype.yaml applies. All six report zero high/critical.

Functional checks beyond "the image builds", since forcing past a cap can break a server that still builds and imports:

  • adb-mysql: starts, 3 tools + 4 resources activate; scan exit 0
  • chroma-mcp: 13 tools enumerated, all SAFE
  • astra-db: 19 tools enumerated, all SAFE
  • brightdata, jetbrains, browserbase: initialize + tools/list over stdio. These are insecure_ignore: true so mcp-scan cannot enumerate them
  • browserbase additionally: sharp 0.35.3 loads against libvips 8.18.3 and round-trips a create/resize/re-encode

Not fixed, and why

mcp-neo4j-cypher, mcp-neo4j-aura-manager, mcp-neo4j-memory. Every fastmcp advisory below 3.2.0 is patched only at 3.2.0 with no 2.x backport, so the fix must cross 2.x to 3.x, and upstream caps fastmcp<3. Forcing 3.x was tested: the image builds, import mcp_neo4j_cypher succeeds, then create_mcp_server() raises TypeError: FastMCP() no longer accepts 'stateless_http'. All three pass that constructor kwarg, which 3.x removed with a hard raise. Needs an upstream release, not an override. See #830 for the full write-up, and #528, which would make cypher's posture worse rather than better.

mcp-server-neon. The npm package is deprecated in favor of a hosted server, last published 0.6.5 which is already what we pin, and upstream's main is now a Next.js app never published under that name. Its ~30 exact-pinned deps produce 86 findings including a next critical. Tracked separately for removal rather than patched.

Note on the neo4j finding

Those three are insecure_ignore: true, so mcp-scan cannot enumerate their tools and would have passed a startup-breaking override straight through. The "the scan also validates the override" property from #831 only holds for scannable servers. Worth remembering before trusting a green scan on an insecure_ignore server.

🤖 Generated with Claude Code

danbarr and others added 6 commits August 5, 2026 15:56
@danbarr @claude
fix(adb-mysql-mcp-server): force cryptography>=50.0.0
fd8b66c 
Grype flags cryptography 48.0.1 for GHSA-g6cj-pr64-35w5 (High): the
PKCS#7 EnvelopedData decryption path exposes a Bleichenbacher oracle
through distinguishable errors and timing. The affected range is
>=44.0.0,<50.0.0 and the fix is 50.0.0.

alibabacloud-tea-openapi caps cryptography <49.0.0 for python>=3.9,
which excludes the fixed version, so the constraint is needed to pull
it forward. This is not a regression from the mcp<2 constraint;
cryptography resolves to 48.0.1 with and without it.

.grype.yaml treats runtime dependencies under /opt/uv-tools as not
ignorable, so an ignore rule is not the right instrument here. Asking
upstream to raise the cap is the more correct long-term fix but is not
something we control.

Verified locally: image installs cryptography 50.0.0 and mcp 1.29.0,
grype --fail-on high --only-fixed reports no vulnerabilities, the
container starts and activates 3 tools plus 4 resources, and the MCP
security scan passes with all tools SAFE.

Residual risk: imports and the RSA signing primitive are covered, but
not live API calls against AnalyticDB, which need credentials.

Fixes #828

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@danbarr @claude
fix(chroma-mcp): constrain mcp[cli] to >=1.28.1 for 5 HIGH CVEs
d307763 
chroma-mcp 0.2.6 exact-pins mcp[cli]==1.6.0, which excludes the fix
for all five HIGH advisories Grype reports against the published
image: GHSA-3qhf-m339-9g5v (fixed 1.9.4), GHSA-j975-95f5-7wqh
(1.10.0), GHSA-9h52-p55h-vw2f (1.23.0), GHSA-jpw9-pfvf-9f58 (1.27.2)
and GHSA-vj7q-gjh5-988w (1.28.1).

1.28.1 is the lowest floor that clears all five. A smaller bump to
1.23.0 would newly expose GHSA-hvrp-rf83-w775 (HIGH, affects
>=1.23.0,<=1.27.1), which the pinned 1.6.0 predates. The constraint
is capped <2 so uv cannot resolve the mcp 2.x major.

chroma-mcp imports only mcp.server.fastmcp.FastMCP, which is stable
across the 1.x line, so this stays well inside same-major territory.

Verified: image builds, resolves mcp 1.29.0, grype --fail-on high
--only-fixed reports no vulnerabilities, and the mcp-scan enumerates
all 13 chroma_* tools with no findings.

Refs #830

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@danbarr
fix(brightdata-mcp): override SDK to 1.26.0 to clear 3 high CVEs
7970f5e 
@brightdata/mcp 2.9.0 exact-pins @modelcontextprotocol/sdk 1.21.2,
which fails the Grype gate with three high findings:

  GHSA-w48q-cv73-mx4w  DNS rebinding  fixed 1.24.0
  GHSA-8r9q-7v3j-jr4g  ReDoS          fixed 1.25.2
  GHSA-345p-7cg4-v4c7  >=1.10.0,<=1.25.3, fixed 1.26.0

An exact pin below every fix, so this is the override shape #669
introduced. 1.26.0 is the lowest version clearing all three: 1.25.2
is still inside the GHSA-345p range. Same-major, no API break.

Verified: grype --fail-on high --only-fixed exits 0 with no
high/critical findings, npm resolves 1.26.0 for both the direct
dependency and fastmcp's copy (deduped), and the container starts
and enumerates its tool list over stdio.

Refs #830
@danbarr
fix(mcp-jetbrains): override SDK to 1.26.0 to clear 2 high CVEs
8095cbe 
No code-scanning alerts landed for this server, so the findings were
established by building the image and running grype locally:

  @modelcontextprotocol/sdk 1.7.0
  GHSA-w48q-cv73-mx4w  DNS rebinding  fixed 1.24.0   high
  GHSA-8r9q-7v3j-jr4g  ReDoS          fixed 1.25.2   high

@jetbrains/mcp-proxy 1.8.0 exact-pins the SDK at 1.7.0, so this is the
same shape as onchain-mcp. 1.26.0 rather than 1.25.2 because
GHSA-345p-7cg4-v4c7 affects >=1.10.0,<=1.25.3, which 1.7.0 predates; a
smaller bump would trade two advisories for a third. Same-major.

Verified: grype --fail-on high --only-fixed exits 0, npm reports
@modelcontextprotocol/sdk@1.26.0 overridden, and the proxy completes
the MCP initialize handshake. tools/list then returns "No working IDE
endpoint available", which is the expected response with no JetBrains
IDE to proxy to and the reason this server carries insecure_ignore.

Refs #830
@danbarr
fix(astra-db-mcp): override undici to 6.28.0 to clear 3 high CVEs
d242e55 
undici 5.29.0 reaches the image through
astra-db-mcp -> mcp-evals -> @actions/core -> @actions/http-client,
which caps it at ^5.25.4:

  GHSA-vrm6-8vpv-qv8q  fixed 6.24.0  high
  GHSA-v9p9-hfj2-hcw8  fixed 6.24.0  high
  GHSA-vxpw-j846-p89q  fixed 6.27.0  high

The 5.x line is end of life, so no 5.x release can carry these fixes
and the cap excludes every fix. 6.28.0 is the last 6.x release; no
high advisory affects >=6.27.0 on that line, and stopping at 6.x
avoids the 7.x-only advisories (GHSA-hm92-r4w5-c3mj,
GHSA-vmh5-mc38-953g, GHSA-4cwx-7wf7-3272).

This is a cross-major force, so worth flagging. It is low risk here:
@actions/http-client 4.0.1 upstream has itself moved to undici
^6.23.0, and the consumer is the mcp-evals harness rather than the
server's request path.

Verified: grype --fail-on high --only-fixed exits 0 with only medium
and low findings remaining, npm reports undici@6.28.0 overridden, and
scripts/mcp-scan/run_scan.py exits 0 with all 19 tools enumerated and
SAFE.

Refs #830
@danbarr
fix(browserbase-mcp-server): override sharp and undici to clear 4 hig…
ab1e2cd 
…h CVEs

Grype reports two capped dependencies, not just the sharp one #830
recorded:

  sharp 0.33.5 (capped ^0.33.0)
  GHSA-f88m-g3jw-g9cj  libvips CVEs, affects <0.35.0   high

  undici 5.29.0 (capped ^5.29.0 by @ai-sdk/provider-utils, reached via
  @browserbasehq/stagehand -> @ai-sdk/amazon-bedrock)
  GHSA-vrm6-8vpv-qv8q  fixed 6.24.0                    high
  GHSA-v9p9-hfj2-hcw8  fixed 6.24.0                    high
  GHSA-vxpw-j846-p89q  fixed 6.27.0                    high

Both caps exclude every fix. sharp goes to 0.35.3, the newest 0.35.x
and the only sharp advisory in play. undici goes to 6.28.0, the last
6.x release, which clears all three without stepping into the 7.x-only
advisories.

Both are effectively cross-major forces: sharp 0.x minors are breaking
by convention, and undici 5 to 6 is a real major. Mitigating evidence
is that @ai-sdk/provider-utils 5.x upstream now uses undici ^7.28.0,
so that consumer tracks well past 6.x.

Verified: grype --fail-on high --only-fixed reports "No vulnerabilities
found" and exits 0; sharp loads in the container against libvips 8.18.3
and round-trips a create/resize/re-encode; the server completes the MCP
initialize handshake and enumerates its tool list over stdio.

Note, unrelated to this change: @browserbasehq/mcp-server-browserbase
2.4.3 is currently uninstallable from a clean npm cache. Its transitive
ai@5.0.228 exact-pins @ai-sdk/gateway@2.0.127, which does not exist in
the registry. This reproduces with a bare `npm install` and no
overrides, and is the likely cause of the intermittent build-step
failures. CI will keep failing at npm install until upstream publishes
a fixed release.

Refs #830
@danbarr danbarr mentioned this pull request Aug 5, 2026
Merged
@toolhive-release-app

toolhive-release-app Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

🔒 MCP Security Scan Results

✅ adb-mysql-mcp-server

  • Status: Passed
  • Tools scanned: 3
  • Result: No security issues detected

✅ astra-db-mcp

  • Status: Passed
  • Tools scanned: 19
  • Result: No security issues detected

⚠️ brightdata-mcp

  • Status: Warning
  • Message: Scan failed to produce output (insecure_ignore is enabled)

✅ browserbase-mcp-server

  • Status: Passed
  • Tools scanned: 9
  • Result: No security issues detected

✅ chroma-mcp

  • Status: Passed
  • Tools scanned: 13
  • Result: No security issues detected

⚠️ mcp-jetbrains

  • Status: Warning
  • Message: Scan failed to produce output (insecure_ignore is enabled)

Summary: Scanned 6 MCP server(s), all passed security checks. ✅

@danbarr
danbarr merged commit 766a8c8 into main Aug 5, 2026
28 checks passed
@danbarr
danbarr deleted the fix/grype-backlog branch August 5, 2026 20:15
This was referenced Aug 5, 2026
Closed
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@JAORMX JAORMX JAORMX approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

2 participants

@danbarr @JAORMX