Chief of Staff & VP @nucleussec, employee #2. Nearly 7 yrs in vulnerability management. Got here by showing up, not applying. Built mcp-audit. Poker player.
1/ I had my agents run mcp-audit against the 100 most-downloaded MCP servers on npm (6.7M downloads/week), from a clean sandbox with no API keys. 60 connected and handed over their tools. Here's what 1,611 tool definitions look like.
@cognition Big commitment, and good to see prioritizing by exploitability in your own environment as its own step. After the fix PR, it still takes a human who owns that service to approve the merge, and a rescan in production to confirm it's closed.
@jeremiahg If I were grading the industry, I'd want every forecast published before exploitation and scored after, like a weather forecast. Counting the misses in public is what ends the guessing!
@ResilientCyber Agreed. If I were a CISO this week, I'd list every SaaS integration holding a token into HR, sales and IT, and give each one a named owner who can revoke it the same day. Agents chain those connections fast, so who pulls the plug has to be settled first.
Saw the same lag one layer down. In the scan of the 100 most-downloaded MCP servers on npm I posted yesterday, 16 of the 66 built on the TypeScript SDK still didn't resolve to the version fixed after the Oct 20 disclosure. About 412K downloads a week. The lockfile tells you. The changelog won't.
@guruchahal That 3.2x vs 1.6x gap lands on the same people. Asset owners didn't triple in two years, so the review pile grows faster than anyone can work it. I'd love to see that chart cut by owner: who's sitting on the most open CVEs, and for how long.
@emollick Where it goes sideways is when seeing more turns into deciding more. If everything the dashboard surfaces still needs a senior leader's sign-off, span of control grows and so does the line outside their door. Push decision rights down at the same time!
@DanielMiessler Handy. Match it against your own inventory and put a name and a date next to every hit. A list doesn't patch anything until someone owns the line.
@snehalantani And exploitable is partly an address question. The same CVE on an internet-facing PHP box and on a lab VM three hops in are two different tickets. Grossman's 1,448 would shrink a lot if you sorted it by where each one actually lives.
@patchmcp Both, if you lock with --connect. It records a digest of every tool's schema and description, then flags a schema change as HIGH and a description-only change as MEDIUM. It stores hashes rather than the text, so you see that a tool changed but not the before-and-after.
I built an #OpenSource scanner for the MCP servers your AI coding tools run. Commit a lock of the servers you approved, and CI fails the pull request when one of them changes. Fully offline. (Yes, I built it with AI coding assistants!)
pip install mcp-audit-scanner
@jeremiecharris Companies have their own version of 3 days of food and water. Decide now who can take an internet-facing system offline at 2am without waiting for a meeting, and get it in writing. If I were a CISO, I'd do it this week.
Good find, and he's right about the hard part. Every team running Brotli now has to find where it's bundled inside software they didn't build, who owns each copy, and when each vendor's fix lands. That's the coordination problem we've worked on at Nucleus since I joined in 2020.
we've found and have been working on disclosure for a remote code execution in a widely-deployed compression library.
it's both an impactful issue and an example that shows how complicated it can be to coordinate patching, since it's integrated into a lot of downstream software:
@levie Agreed on the basics. Fragmented data and not knowing your state of risk was the story when I started in vulnerability management in 2020, and long before that. Same problem, just more volume and more speed now.
@snehalantani@anton_chuvakin Agreed, KEV is the right scoreboard. I'd just keep it out of the patch trigger. When @nucleussec reviewed KEV additions from Oct 2025 to Mar 2026, 14 CVEs showed meaningful early signals before any exploitation was confirmed.
@nikesharora Agreed on the hybrid approach. Just give every virtual patch an owner and a date for the direct fix, or it becomes a risk acceptance nobody signed. And settle who can approve both before the next PHP week, not during it.
5/ And my own scanner: 661 poisoning findings on these servers, zero real. 488 came from a rule flagging Chinese punctuation as homoglyphs. That bug is in the report too. Report + data: https://t.co/aXU50io5sv
1/ I had my agents run mcp-audit against the 100 most-downloaded MCP servers on npm (6.7M downloads/week), from a clean sandbox with no API keys. 60 connected and handed over their tools. Here's what 1,611 tool definitions look like.
4/ The MCP project disclosed TypeScript SDK flaws on Oct 20 (3 HIGH). On scan day, 50 of the 66 servers built on it resolved to the fixed SDK. 16 didn't, ~412K downloads/week. 4 still predate the Dec 2025 DNS-rebinding fix.
mcp-audit v0.21.1 is out, a security update. The binaries now build on dependencies with no known vulnerabilities, and the registry adds five October MCP SDK advisories.
Thanks to Alex Chen (activeing123 on GitHub) for submitting mcptoon!
https://t.co/e9aheKMf2f