Hi Klavis team,
While testing AI PatchLab (an open-source local-first SAST/SCA scanner) on a range of MCP and agent projects, I scanned klavis at `669e95dc716b`. This is the largest finding count of any project in the series so far — but that's a function of the monorepo structure (50+ independently-dependency-managed MCP servers), not a knock on any individual server.
Full curated write-up — with the monorepo-drift analysis and the FP breakdown — is at: https://elfrost.github.io/ai-patchlab/scans/klavis-ai-klavis.html
The headline recommendation is process, not a patch list (see section 4) — but here are the items, prioritized.
1. Three critical CVEs that matter most for an MCP platform
These are directly in the request-handling path of MCP servers, so they're worth fixing ahead of the rest:
- authlib — CVE-2026-27962, authentication bypass. Prior to 1.6.9, a JWK Header Injection in authlib's JWS implementation lets an unauthenticated attacker forge JWT tokens that pass signature verification. Affects `mcp_servers/google_cloud_toolathlon`, `mcp_servers/local/Poste.io`, `mcp_servers/local/excel`. Fix: `authlib >= 1.6.9`.
- fastmcp — CVE-2026-32871, authenticated SSRF. Prior to 3.2.0, the `OpenAPIProvider`'s `_build_url()` can be coerced via path traversal in OpenAPI path parameters into requests to unintended backends. Same three servers. Fix: `fastmcp >= 3.2.0`.
- MCP Python SDK — CVE-2025-66416, DNS-rebinding. Prior to 1.23.0, `mcp` does not enable DNS-rebinding protection by default for HTTP servers. Surfaces in ~59 sub-project lockfiles. Fix: `mcp >= 1.23.0`.
2. The other 19 critical CVEs
h11 (8×, malformed Chunked-Encoding acceptance), form-data (4×, unsafe random boundary), basic-ftp (2×, path-traversal file overwrite), fast-xml-parser (1×, XSS), excel-mcp-server (1×, path traversal). All are single-line dependency bumps; full file list in the write-up.
3. ~135 Dockerfiles run as root
Each `mcp_servers/*/Dockerfile` ends without a `USER` directive. Since MCP servers execute tool calls (file ops, shell, API requests), "container compromise" + "runs as root" compound. A shared base image with the `USER` directive baked in fixes all ~135 at once and stops the next server from regressing:
```dockerfile
RUN groupadd -r app && useradd -r -g app -d /app app
USER app
```
4. The durable fix: monorepo-wide dependency automation
Hand-bumping the 22 criticals clears today's list; it does nothing about the drift that produced them. With 50+ independently-pinned sub-projects, no single lockfile is anyone's daily concern, so the aggregate rots. Recommended:
- Dependabot or Renovate with a config covering every `mcp_servers/*/` directory (Renovate's `"extends": ["config:recommended"]` + a directory matcher handles monorepos well).
- A shared Docker base image so the `USER` directive and a pinned MCP-SDK floor are defined once.
- Optionally, a CI job running `trivy fs --severity CRITICAL,HIGH` on the monorepo so new drift is visible on every PR.
This turns "1,300 findings once" into "a handful of automated PRs per week".
The full write-up also walks through the false positives (the ~150 `curl -H "Authorization: Bearer ..."` documentation examples, the example-integration projects' own lockfiles) which I suppressed before triage. Happy to share the raw report or help script the dependency-automation config. Thanks for klavis — the monorepo structure is the cause of the volume, and the automation fix is genuinely a few hours of setup for a permanent result.
Hi Klavis team,
While testing AI PatchLab (an open-source local-first SAST/SCA scanner) on a range of MCP and agent projects, I scanned klavis at `669e95dc716b`. This is the largest finding count of any project in the series so far — but that's a function of the monorepo structure (50+ independently-dependency-managed MCP servers), not a knock on any individual server.
Full curated write-up — with the monorepo-drift analysis and the FP breakdown — is at: https://elfrost.github.io/ai-patchlab/scans/klavis-ai-klavis.html
The headline recommendation is process, not a patch list (see section 4) — but here are the items, prioritized.
1. Three critical CVEs that matter most for an MCP platform
These are directly in the request-handling path of MCP servers, so they're worth fixing ahead of the rest:
2. The other 19 critical CVEs
h11 (8×, malformed Chunked-Encoding acceptance), form-data (4×, unsafe random boundary), basic-ftp (2×, path-traversal file overwrite), fast-xml-parser (1×, XSS), excel-mcp-server (1×, path traversal). All are single-line dependency bumps; full file list in the write-up.
3. ~135 Dockerfiles run as root
Each `mcp_servers/*/Dockerfile` ends without a `USER` directive. Since MCP servers execute tool calls (file ops, shell, API requests), "container compromise" + "runs as root" compound. A shared base image with the `USER` directive baked in fixes all ~135 at once and stops the next server from regressing:
```dockerfile
RUN groupadd -r app && useradd -r -g app -d /app app
USER app
```
4. The durable fix: monorepo-wide dependency automation
Hand-bumping the 22 criticals clears today's list; it does nothing about the drift that produced them. With 50+ independently-pinned sub-projects, no single lockfile is anyone's daily concern, so the aggregate rots. Recommended:
This turns "1,300 findings once" into "a handful of automated PRs per week".
The full write-up also walks through the false positives (the ~150 `curl -H "Authorization: Bearer ..."` documentation examples, the example-integration projects' own lockfiles) which I suppressed before triage. Happy to share the raw report or help script the dependency-automation config. Thanks for klavis — the monorepo structure is the cause of the volume, and the automation fix is genuinely a few hours of setup for a permanent result.