Skip to content
T threat.cafe

· Margot Reyes (editorial persona) · Intel commons after NVD · on threat.cafe

No CVE, no alert: the October agent-tool fixes a CVE-keyed scanner misses

Most October agent-tool security fixes reached users without a CVE. TestedMCP counted 35 MCP server advisories across 10 listings in October 2026. One had a CVE. OpenCode fixed a flaw Pillar Security rated 9.8 as a refactor, with no advisory. A CVE-keyed vulnerability programme misses these by design. The decision is whether to add a second input: GitHub advisories, agent CLI release notes and a curated known-bad list. Until then, treat "unknown" as unresolved, not cleared.

The headline figure and the usable figure

The October 2026 advisory count for MCP servers looks healthy at first glance. TestedMCP's October roundup, last checked 27 October, lists 35 advisories on 10 server listings. That is the headline figure, and the usable figure is much smaller: only 1 of the 35 carries a CVE: CVE-2026-104776, for the Flux159 Kubernetes server. A scanner that joins inventory to CVE IDs therefore sees 1 of 35, or about 3%.

The gap widens outside the server count. TestedMCP lists 9 advisories for MCP Inspector, published 21 October. None of the 9 had a CVE as of 26 October, and 2 of the 9 are rated critical. Fixes with no advisory at all sit outside any count.

The consensus reading is simple: fewer CVEs means fewer problems. The October data does not support it. Advisories exist and fixes ship, but the CVE layer is missing.

Four October fixes, sliced by what a scanner can see

OpenCode, fixed as a refactor. Eilon Cohen of Pillar Security reported a flaw in OpenCode's remote MCP OAuth sign-in on 29 August 2026. A malicious or later-hijacked remote MCP server could supply an authorisation URL. On Windows and WSL, OpenCode passed it to a browser-launch helper without proper escaping. Command execution followed when a developer started sign-in, while macOS and Linux were not affected.

Affected versions run from 1.0.137 to 1.18.32. Version 1.18.33 reached npm on 28 September. Pillar proposed a CVSS 3.1 score of 9.8, which is Pillar's figure rather than an official one.

Pillar's timeline says the vendor, Anomaly, called a malicious MCP server "outside our threat model". The Hacker News cites Anomaly's security policy: user-configured MCP servers are "outside our trust boundary". No CVE was requested and no advisory was published. The fix landed as a refactor that consolidated browser-launch call sites. Neither the pull request nor the release notes mention security. Pillar's own advice is blunt: inventory OpenCode installations directly, because scanners won't flag this without a CVE.

MCP Inspector, advisory but no CVE. One of Inspector's 2 critical advisories is GHSA-4fc4-wcmh-4g86, credited to bhavya32. A malicious OAuth callback could switch Inspector's transport to a local command. GitHub rates it 9.6, and versions 1.0.3 and 2.12.0 fix the full set of 9.

Python MCP SDK, a fix that is off. GHSA-w4fh-qvv9-3v23, reported by u-ktdi and published 5 October, has no CVE. Bearer auth accepted tokens issued for a different resource server. The advisory says: "Upgrading alone changes nothing." Versions 1.30.0 and 2.2.0 add a validate_token_resource setting that stays off by default until 3.0.

Claude Code, changelog only. TestedMCP points to 2 Claude Code changelog entries with no advisory and no CVE. Version 2.1.238 made project .mcp.json headersHelper and inline MCP servers require the folder's trust dialog, including under claude -p. A third-party changelog tracker dates that release to 20 August 2026. Version 2.1.296 fixed headless sessions starting a .mcp.json server switched off for that folder. TestedMCP did not test this behaviour.

The threat.cafe October 2026 No-CVE Fix Ledger below puts these side by side.

The threat.cafe October 2026 No-CVE Fix Ledger
(n = 6 fixes; "Not checked" = release notes not opened by us)

Fix                                   Tool                     CVE?             Advisory?       Release note says security?
------------------------------------  -----------------------  ---------------  --------------  ----------------------------
Remote MCP OAuth sign-in cmd inject.  OpenCode 1.18.33         No               No              No (browser-launch refactor)
OAuth callback switches to stdio      MCP Inspector 1.0.3      No (26 Oct)      Yes (GHSA)      Not checked
Token audience not validated          Python mcp 1.30.0/2.2.0  No               Yes (GHSA)      Fix is opt-in, off by default
Untrusted-folder .mcp.json under -p   Claude Code 2.1.238/296  No               No              Changelog line only
Comment and Control (April 2026)      3 CI agent actions       No (at report)   No (at report)  Patched quietly
kubectl_patch path guard missing      Flux159 k8s MCP 4.1.1    CVE-2026-104776  Yes (GHSA)      Not checked

CVE coverage: 1 of 6 fixes in this ledger; 1 of 35 TestedMCP server advisories (Oct 2026).
Paste-ready rule: "No CVE" is a data gap, not a verdict. Unknown stays unknown until checked.

A pattern older than October

The October 2026 cohort is not an outlier. In April 2026, VentureBeat reported on "Comment and Control". The research came from Aonan Guan with Johns Hopkins colleagues Zhengyu Liu and Gavin Zhong. One prompt injection pattern hit 3 products: the Claude Code Security Review action, Gemini CLI Action and GitHub Copilot Agent. All 3 were patched quietly, and VentureBeat found none of the 3 had issued CVEs or GitHub advisories at reporting time. Anthropic had rated its instance 9.4.

Adversa AI's October roundup summarises its own catalog of 10 Claude Code attacks. Two of 10 produced CVEs and 4 of 10 were declined by vendors, by Adversa's own count from its own selection of attacks. Selection bias applies: a curated top 10 is not a base rate.

The strongest case against this argument

The best counterargument deserves a fair hearing. CVEs exist for vulnerabilities in a product's own trust model. If a vendor scopes user-configured MCP servers out, a malicious server is not a product flaw. Under that view, Anomaly's call is consistent, and some October fixes are genuinely ambiguous too. A changelog line that tightens trust prompts can read as hardening, not a vulnerability. Assigning CVEs to every hardening change would flood feeds with noise.

That case is coherent, yet it still fails the defender. Scoping decides who is responsible, not whether the risk exists. When a vendor says "outside our trust boundary", the risk moves to you. Your developers still add remote MCP servers, and your CI still runs headless agents in repositories you did not write. And the Inspector case is not ambiguous at all: 2 critical advisories exist, on GitHub, with no CVE. A programme that waits for the CVE waits on paperwork, not on the fix.

What to check today

The second input is a short list of habits, ordered by effort:

  1. Inventory agent CLIs and versions. Confirm OpenCode 1.18.33 or later on Windows and WSL. Run opencode mcp list to see configured servers, as The Hacker News suggests. Confirm Claude Code 2.1.296 or later.
  2. Watch GitHub advisories per repository. Cover each agent tool and MCP server you run, plus Inspector and the MCP SDKs.
  3. Read agent CLI release notes as a security input. Words like "refactor", "trust", "headless", "OAuth" and "sandbox" deserve a second look. Assign an owner; weekly is a reasonable cadence.
  4. Check opt-in fixes. For Python mcp servers, upgrade to 1.30.0 or 2.2.0. Then set validate_token_resource=True with resource_server_url in AuthSettings, unless your verifier already checks audience.
  5. Pin versions and re-verify. A pinned version turns a quiet fix into a deliberate upgrade. See our post "Approved last month, malicious today: a re-verification cadence".
  6. Subscribe to curated lists. Advisory roundups like TestedMCP's and known-bad lists track agent artifacts directly.
  7. Turn vendor scoping into your own control. Write down who approves remote MCP servers. For Claude Code in CI, TestedMCP suggests --bare with --mcp-config.
  8. Adopt a three-state policy. A version with no CVE is "unknown", not cleared. Our post "Known bad, no known bad, unknown: a three-state policy model" covers enforcement with hooks and gateways.

What to tell the people who sign off

The approval case for this change fits on four lines, one per reader:

  • Finance: the second input is reading time, not a new tool. Budget a few owner-hours a week for advisory and changelog review.
  • Security lead: the blast radius is developer laptops and CI runners that hold tokens. The OpenCode flaw ran code on Windows and WSL machines at sign-in.
  • Legal and compliance: evidence of patching should cite advisory IDs and versions, not only CVE IDs. Several October fixes have no CVE to cite.
  • Operations: pinning adds upgrade tickets. Rollback is a version pin change.

Where this would be wrong

The argument above has clear failure conditions. It would be wrong if CVEs are assigned to the October fixes within weeks, which would make the gap a lag, not a structural miss. It would weaken if NVD or CNAs start issuing IDs for GHSA-only agent-tool advisories at scale. It would also be wrong for teams whose scanners already ingest the GitHub advisory database directly. For them, only the advisory-free fixes remain hidden.

Some limits sit in plain sight. Pillar's post is bylined 19 October, but its timeline lists publication on 4 October, and the difference is unresolved. TestedMCP lists the OpenCode issue as "reported but unconfirmed", because it found no vendor advisory, so the technical detail rests on Pillar's write-up. The threat.cafe review did not test any of these issues, and Pillar reported no exploitation for OpenCode.

Check any agent tool or MCP server name against the threat.cafe board, which records advisories with no CVE as well as those with one.

Volatility: VOLATILE (event-triggered review). Review when a CVE is assigned to the OpenCode or MCP Inspector fixes, or when TestedMCP publishes its November 2026 roundup.

Sources

#cve #ghsa #mcp-servers #release-notes #vulnerability-management

All posts