TL;DR: Bumblebee is Perplexity’s free, Apache 2.0, read-only scanner that inventories every package, IDE extension, and MCP server config on a developer machine and flags exact matches against supply-chain compromise catalogs. In my test it caught a compromised node-ipc version in a lockfile and a GlassWorm-listed Cursor extension in under 200 ms. The catch: it only flags what a catalog names — it makes no judgment calls of its own.

	Bumblebee v0.1.2	npm audit	Claude Security plugin
Best for	Fleet-wide “are we exposed to this advisory?” checks across packages, extensions, and MCP configs	Known-vulnerable npm deps in one project	Finding vulnerabilities in your own code
Price	$0 (Apache 2.0, self-hosted)	$0 (ships with npm)	$0 extra; burns Claude plan tokens
The catch	No built-in vuln feed — you supply exposure catalogs; exact version matches only	npm only; blind to IDE extensions, MCP configs, and every other ecosystem	Reviews source code, not installed artifacts; token-hungry

Honest take: If your team runs Cursor, Claude Code, or Windsurf with MCP servers, deploy Bumblebee on a cron and keep the threat_intel/ catalogs updated — it is currently the cheapest way to answer “which of our laptops has the compromised package” in minutes instead of days. Solo devs with one project can stay on npm audit plus marketplace hygiene.

Perplexity open-sourced Bumblebee on May 22, 2026, describing it as one of the internal tools protecting the developer machines behind Perplexity, Comet, and Computer. Five months later the repo sits at 5.1k stars and 460 forks (checked October 19, 2026), the current tag is v0.1.2 (June 18, 2026), and the maintained threat catalogs have grown to 11 campaigns covering 1,072 packages and 2,910 version pins — including the May 2026 Mini Shai-Hulud npm worm wave and the GlassWorm IDE-extension campaign. I installed v0.1.2 on a Linux box on October 19, 2026, seeded a workspace with a known-compromised npm package and a GlassWorm-listed Cursor extension, and ran all three scan profiles. Everything below is from those runs plus the official repo docs.

What is Bumblebee and what does it actually scan?

Bumblebee is a single static Go binary that reads on-disk metadata — lockfiles, package-manager install records, extension manifests, and MCP JSON configs — and emits one NDJSON record per component it finds. It answers one narrow question: when an advisory names a package, extension, or version, which machines show a match right now? It never executes package managers, never runs npm ls or pip show, and never reads your source files. That design matters because the postinstall script is exactly where recent npm worms detonate; a scanner that shells out to npm to ask what’s installed can trigger the thing it’s hunting.

Coverage in v0.1.2, from the repo’s docs/inventory-sources.md:

Surface	What it reads
npm / pnpm / Yarn / Bun	package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock, node_modules metadata
PyPI	*.dist-info/METADATA, *.egg-info/PKG-INFO
Go / RubyGems / Composer	go.sum, Gemfile.lock, composer.lock, installed gemspecs
MCP server configs	mcp.json, .mcp.json, claude_desktop_config.json, mcp_config.json, mcp_settings.json, cline_mcp_settings.json, ~/.gemini/settings.json, ~/.claude.json
Editor extensions	VS Code, Cursor, Windsurf, VSCodium manifest files
Browser extensions	Chromium-family manifest.json, Firefox extensions.json
Agent skills	skills.sh lock files (~/.agents/.skill-lock.json, project skills-lock.json)
Homebrew	Formula install receipts and cask markers

The MCP row is the unusual one. MCP configs declare which external services your AI coding agent can reach — GitHub, databases, email — and they have already been an attack vector this year: the Amazon Q Developer MCP credential-theft CVE auto-executed MCP servers on repo clone. Mainstream SCA tools scan registries and repos; almost nothing inspects the MCP JSON sitting in ~/.cursor/ at rest. Bumblebee does, and it deliberately parses but never emits the env blocks where tokens live — I grepped my scan output for the fake credentials I planted and got zero hits.

How do you install Bumblebee?

One command, if your Go toolchain is current:

$ go install github.com/perplexityai/bumblebee/cmd/bumblebee@latest

The first real-world snag hit immediately: my machine had Go 1.24.7 and Bumblebee requires Go 1.25+. With GOTOOLCHAIN=auto (the default since Go 1.21), the install resolved it without intervention — it downloaded go1.26.9, built, and finished in 23 seconds:

go: github.com/perplexityai/bumblebee@v0.1.2 requires go >= 1.25; switching to go1.26.9

If your org pins GOTOOLCHAIN=local, that same install dies with a version error, so budget one toolchain bump into any fleet rollout. There are no prebuilt binaries and no Homebrew formula as of v0.1.2 — Go is the only install path.

The binary ships a self-test against embedded fixtures with deliberately fake package names, which makes a decent smoke test before fleet deployment:

$ bumblebee version
bumblebee v0.1.2
$ bumblebee selftest
selftest OK (5 findings in 2ms)

What happens when Bumblebee finds a compromised package?

It emits a finding record with the exact evidence, severity, and catalog entry — and nothing else happens, because the tool is read-only by design. To test detection, I built a workspace containing two real-world indicators from the maintained catalogs: a package-lock.json pinning node-ipc@9.2.3 (one of seven versions compromised in the May 2026 credential-stealer campaign documented by Socket) and a Cursor extensions directory containing a manifest for aadarkcode.one-dark-material@3.20.1, a version on the GlassWorm v2 affected list. Manifests and lockfiles only — no actual malicious code was involved.

The baseline profile swept the machine in 176 ms (8,925 files considered, 87 records) and flagged the extension:

$ bumblebee scan --profile baseline --exposure-catalog ./threat_intel > inventory.ndjson

{
  "record_type": "finding",
  "finding_type": "package_exposure",
  "severity": "critical",
  "catalog_name": "aadarkcode.one-dark-material (GlassWorm)",
  "ecosystem": "editor-extension",
  "package_name": "aadarkcode.one-dark-material",
  "version": "3.20.1",
  "source_file": ".../.cursor/extensions/aadarkcode.one-dark-material-3.20.1/package.json",
  "confidence": "high",
  "evidence": "exact name+version match (version=3.20.1)"
}

The project profile pointed at the code directory caught the lockfile entry the same way — critical npm node-ipc 9.2.3, traced to the exact package-lock.json. Add --findings-only and the output drops the inventory records and keeps just the hits, which is what you want when you’re sweeping 200 laptops during an incident.

Two details stood out. First, every record carries the scanner version, run ID, hostname, and profile, so NDJSON from a whole fleet can be piped into one log index and still be traceable. Second, profiles enforce scope discipline: baseline and project refuse to walk a bare home directory — only deep with an explicit --root does that, and it takes a --max-duration cap. That’s the difference between a tool designed for recurring automated runs and a grep script someone will eventually point at / on a Friday.

What does Bumblebee see in your MCP configs?

Every server, its package identity, and where it was declared — but no secrets. My test .mcp.json declared a GitHub MCP server via npx and a Postgres server via uvx, both with fake credentials in env blocks. The scan inventoried both:

mcp  @modelcontextprotocol/server-github  (server_name: github)      .mcp.json
mcp  mcp-server-postgres                  (server_name: internal-db) .mcp.json

Bumblebee parses the command line to identify the underlying package — npx -y @modelcontextprotocol/server-github becomes a scannable npm identity, uvx mcp-server-time becomes a PyPI one. A spec like @playwright/mcp@latest is preserved in requested_spec, but the version field stays empty and confidence drops to low, because nothing on disk says which version npx will actually resolve tonight. That’s an honest representation of a real blind spot: an MCP server declared at @latest can silently become a compromised version tomorrow without the config changing at all. If you want version-pinned MCP findings, pin versions in your configs — advice that holds regardless of what scanner you run, and one more reason to be picky about which MCP servers you install.

Coverage has one gap worth knowing: v0.1 parses JSON configs only. Codex CLI’s config.toml and Continue.dev’s YAML config are walked past, unparsed. Claude Code, Claude Desktop, Cursor, Windsurf, Cline, and Gemini CLI configs are all covered.

What’s in the maintained threat catalogs?

Eleven campaign catalogs under threat_intel/, built from public reporting (Socket, StepSecurity, Koi Security, Checkmarx, Sonatype) and updated by PR — 1,072 entries and 2,910 pinned versions as of October 19, 2026. The roster reads like this year’s supply-chain incident log:

Catalog	Campaign	Scale
mini-shai-hulud.json	Mini/Shai-Hulud npm+PyPI worm, May 2026	172 entries
antv-mini-shai-hulud.json	AntV worm wave, May 2026	324 packages / 643 versions
mastra-2026-06-17.json	Mastra npm compromise, June 2026	141 packages
glassworm.json	GlassWorm IDE-extension worm	245 entries / 383 versions, 243 of them editor extensions
node-ipc-credential-stealer.json	node-ipc credential stealer, May 2026	7 versions, with C2 indicators
nx-console-vscode-2026-05-18.json	Nx Console VS Code extension compromise	1 extension version
gemstuffer.json	GemStuffer RubyGems exfiltration	123 gems / 155 versions
plus 4 more	Laravel Lang (Composer), Red Hat Cloud Services (npm), shopsprint/decimal (Go typosquat), TrapDoor (npm/PyPI/Cargo)	—

The GlassWorm catalog is the one that justifies the whole category: 243 compromised editor extensions is an attack surface that npm audit cannot see and most orgs don’t inventory at all. We covered the adjacent marketplace problem in our Open VSX evil-twin extensions guide — Bumblebee is the first tool I’ve tested that turns “did anyone install one of these?” into a one-command answer.

You’re not limited to the shipped catalogs. The repo includes tools/osvcatalog, which converts a local snapshot of the OSSF malicious-packages database into a Bumblebee catalog offline — the scanner itself never makes a network call, at scan time or any other time. For a security team, that offline posture is a feature: the scanner can run on machines that aren’t allowed to phone home, which pairs naturally with fully local AI coding stacks (see the best local coding LLMs on our sister site if you’re building one).

What does Bumblebee miss?

Plenty — and the limits are structural, not bugs:

• No judgment, only matching. My test config declared an MCP server with write access to a production database behind a sketchy connection string. No finding — correctly, by the tool’s own rules, because no catalog names mcp-server-postgres. Bumblebee is an inventory-and-match engine, not an anomaly detector. If you want “this MCP config looks dangerous” analysis, that’s a different tool.
• Exact version matching. A cataloged package at an uncataloged version produces no finding. Catalogs support a "*" wildcard per package, but the shipped ones mostly pin exact versions, so a stale catalog quietly stops protecting you. Treat threat_intel/ updates like signature updates.
• Read-only means no blocking. It will tell you node-ipc@9.2.3 is on a laptop; it will not stop the install, quarantine the file, or kill the process. Remediation is on you.
• Platform and ecosystem gaps. macOS and Linux only — no Windows. No Cargo/crates.io support yet (the TrapDoor catalog documents six malicious Cargo packages that are present but unmatched until support lands). Loose agent-skill directories without a lock file aren’t enumerated.
• Point-in-time, not continuous. Each invocation is one scan. Cadence is your cron job’s problem.

Bumblebee vs npm audit vs Snyk-style SCA: which do you need?

Different layers; the overlap is smaller than it looks. npm audit checks one project’s npm dependency tree against the npm registry’s advisory database — great default, but it covers exactly one ecosystem in exactly one directory and knows nothing about IDE extensions, MCP configs, browser extensions, or what’s installed globally on the machine. Registry-and-repo SCA platforms (Snyk, Socket and peers) watch your repositories and dependency manifests continuously in CI, which Bumblebee doesn’t try to do — but they sit upstream of the developer endpoint, and an engineer’s laptop with a compromised Cursor extension installed from the marketplace never shows up in a repo scan. Bumblebee is the endpoint-side layer: everything actually sitting on the machine, in one pass, from a tool with zero runtime dependencies.

It’s also a different animal from AI-native code scanners like the Claude Security plugin, which hunts for vulnerabilities in code you wrote. Bumblebee doesn’t read your code at all. The threat models this site has tracked all year — agentjacking via Sentry, GhostApproval symlink escapes, MemGhost memory poisoning — attack the agent at runtime. Bumblebee covers the quieter half of the problem: the compromised artifact already installed and waiting.

Who should actually deploy this?

Teams of five or more developers running AI coding tools with MCP servers: yes, this week. The setup cost is one Go install and a cron entry, the output is greppable NDJSON, and the next npm worm is a matter of when. When the advisory drops, bumblebee scan --profile baseline --exposure-catalog ./threat_intel --findings-only across the fleet beats asking everyone to check their own package-lock.json in Slack. Security teams get the most from pairing it with the osvcatalog converter and their own intel.

Solo developers: borderline. The honest math is that npm audit, pip-audit, and restraint about installing marketplace extensions cover most of your exposure. Where Bumblebee earns a spot even on one machine is the extension and MCP inventory — if you’ve accumulated a year of Cursor extensions and MCP servers (the open-source agent ecosystem moves fast and configs pile up), a monthly sweep against the GlassWorm catalog costs you 200 ms.

Anyone expecting a turnkey security product: no. There’s no dashboard, no feed subscription, no auto-remediation, no Windows build. Version 0.1.2 is exactly what it says it is — a sharp, narrow incident-response primitive that happens to be the only free tool reading the MCP configs your AI coding stack depends on.

FAQ

Does Bumblebee send any data off the machine? No. It makes no network calls at scan time or otherwise; output goes to stdout as NDJSON and shipping it anywhere is your runner’s job. Catalog updates arrive however you distribute files.

Can it read secrets out of my MCP configs? It parses env blocks to build server inventory but never emits environment values or key names in its records. I verified this directly: credentials planted in test configs did not appear anywhere in the scan output.

Does it detect malicious code in packages? No. It matches installed name+version pairs against exposure catalogs. A zero-day package nobody has cataloged produces a normal inventory record, not a finding.

Does it work with Cline and Claude Code? Yes — cline_mcp_settings.json, ~/.claude.json, and ~/.claude/.mcp.json are all parsed in v0.1.2. Codex CLI’s TOML config and Continue.dev’s YAML are not.

How often should the catalogs be updated? Every scan is only as good as its catalogs. Pull the repo’s threat_intel/ on a schedule, or generate your own from the OSSF malicious-packages database with the bundled osvcatalog tool.

Sources

• perplexityai/bumblebee — GitHub repository (v0.1.2, 5.1k stars, checked Oct 19 2026)
• Bumblebee inventory sources — official docs
• Bumblebee threat-intel catalogs — official docs
• Perplexity is open-sourcing Bumblebee — Perplexity Hub blog
• Perplexity open sources read-only security tool for supply-chain threats — OpenSourceForU
• node-ipc package compromised — Socket
• GlassWorm v2 campaign tracker — Socket
• Mastra npm packages compromised — Socket
• Nx Console VS Code extension compromised — StepSecurity

Last updated October 19, 2026. Versions, catalogs, and coverage change frequently; verify against the official repo before deploying. Tests in this review were run on Bumblebee v0.1.2 on Linux (amd64) on October 19, 2026, using a seeded test workspace — catalog-listed manifests and lockfile entries only, no live malware.

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.

Email address Subscribe