DEV Community: Ishaan Agrawal

Fable 5 Released and Suddenly I’m Much More Paranoid About My VSCode Extensions

Ishaan Agrawal — Fri, 12 Jun 2026 22:30:10 +0000

Three days ago, Anthropic released Claude Fable 5 — their first publicly available Mythos-class model, sitting above the entire Opus tier. It benchmarks over 10% better than Opus 4.8 on some coding tasks, ships with a 1M context window by default, and is built specifically for multi-agent workflows. Planning, sub-agent delegation, long-running autonomous execution.

It's available in VS Code right now via Claude Code and a growing list of extensions.

And that's what's been on my mind since Tuesday.

What AI Agents Actually Mean for Your Editor

For years, AI in your editor was passive. Copilot finishes a line, you tab or you don't. A chatbot drafts a function, you paste it in or you don't. You were always the one making the call.

That's not what agentic AI is.

Fable 5 is designed to open files, run terminal commands, make network calls, modify your workspace, and coordinate across tools — with minimal input from you. Anthropic literally describes it as built for "multi-day execution with minimal human involvement." In VS Code, that means an AI extension can now read your entire codebase, spawn processes, hit external APIs, and talk to other extensions and MCP-connected tools.

None of this is hypothetical. Amazon Q's VS Code extension was hijacked through a malicious GitHub pull request that ordered it to wipe the local filesystem and AWS resources. Replit's coding agent deleted a production database — over 1,200 records — during a code freeze. Not bugs in the AI itself. Compromised infrastructure around it.

The MCP Problem

Fable 5 arrives with deep MCP integration — the protocol that lets AI agents connect to external tools, databases, and services from inside your editor. It's genuinely useful. It's also an attack surface that most developers aren't thinking about yet.

The specific thing researchers are worried about is tool poisoning. A malicious MCP server hides instructions inside tool descriptions — the text that tells an agent what a tool does. The model reads those descriptions and follows them, the same way it follows your prompts. No code exploit needed. It just loads into the agent's context and runs silently on every invocation, for every user, until someone notices something is off.

The numbers aren't great: 43% of public MCP servers have at least one vulnerability, and 5.5% already have poisoned tool descriptions in the wild. In May, OX Security disclosed a specific issue where the official MCP SDK's local transport could be exploited through VS Code, Cursor, Claude Code, and others. Anthropic confirmed it was by design and said sanitization is on developers to handle.

So the security model for AI agents in your editor is, right now, largely on you.

Why This Changes the Extension Risk Equation

Before agents, a sketchy VS Code extension had to actively do something bad — phone home, harvest credentials, mine crypto. Behaviors you could look for, that static analysis could catch.

Agent extensions flip that. An extension that looks completely clean can install an MCP server with poisoned tool descriptions, then sit there and wait for you to use an AI agent that has real permissions in your environment. The extension doesn't do anything malicious itself. It just influences something that does.

That's a much harder thing to catch by looking at star counts and download numbers.

What to Actually Check in 2026

The basics still apply — verified publisher, active repo, recent commits. But there are a few new things worth looking at before installing any AI agent extension or MCP server.

Check what MCP servers the extension installs or connects to, and whether those servers' tool descriptions are readable and match their stated purpose. If descriptions are loaded dynamically from a remote source you can't inspect, that's worth knowing. Also worth checking: is the extension connecting your agent to remote servers you didn't explicitly approve?

And if you're upgrading to Fable 5 or enabling Claude Code in a workspace where you already have a bunch of extensions installed, that's a good moment to do a full audit. The permissions your existing extensions effectively have just increased.

VSCan covers the fundamentals — dependency vulnerabilities, permissions analysis, publisher signals. As agent extensions keep multiplying, running a check before you install is going to matter more, not less.

The Pattern Is Familiar

This has happened before. npm became ubiquitous, developers installed packages without much scrutiny, supply chain attacks followed. Browser extensions got powerful, people installed them casually, malicious ones followed. AI agent extensions are the same pattern — just with higher stakes, because the tools are more capable and the access is broader.

Anthropic built real safeguards into Fable 5 to block high-risk outputs in cybersecurity and other sensitive areas. Those safeguards are meaningful. They're also not a substitute for being thoughtful about what extensions you have in your editor and what MCP infrastructure they're connecting to.

Fable 5 is a genuinely impressive model. Autonomous multi-step execution, native VS Code integration, frontier reasoning — it's a real capability jump. It's also a good reminder that your editor is only as trustworthy as what's running inside it.

Before installing AI agent extensions, run a quick check. VSCan scans VS Code extensions for permission risks, dependency vulnerabilities, and security flags.

How to Actually Check if a VS Code Extension is Safe Before You Install It

Ishaan Agrawal — Fri, 12 Jun 2026 02:54:53 +0000

You're about to install a VS Code extension. Maybe it's a formatter, a linter, a theme, an AI tool. You search, you find it, it has decent reviews. You click Install.

But here's what you probably didn't check — and what almost nobody does.

What VS Code Extensions Can Actually Do

Before we get into how to evaluate one, it's worth being clear about what you're giving permission for. VS Code extensions run with full access to:

Your filesystem — read, write, delete
Your environment variables — including secrets, tokens, and credentials your shell exposes
Network connections — outbound requests to anywhere
Child processes — spawning terminals, shell commands, background workers
Other extensions — via the extension API There is no sandbox. When you install an extension, you're running code with your own user permissions. The same permissions that can push to your git repos, read your .env files, and access your SSH keys.

This isn't hypothetical. Extensions with millions of installs have been caught doing exactly these things.

The Checklist Most Developers Skip

Here's what a 60-second review actually looks like:

1. Look at the publisher, not just the extension name

Anyone can publish to the VS Code Marketplace. The publisher ID is the only stable identifier — the display name can be anything, and typosquatting is real.

Is the publisher verified (blue checkmark)?
Does the publisher have other extensions, a website, a GitHub presence?
Does the publisher name look like a real organization or a random string? Legitimate extensions from major companies (Microsoft, Prettier, ESLint) will have recognizable, verified publishers. A one-off extension with a publisher ID like devtools-pro-2024 is worth extra scrutiny.

2. Check when it was last updated

An extension that hasn't been touched in 2+ years is a supply chain risk waiting to happen. Old dependencies, unmaintained code, and abandoned repos are exactly how attackers get in — either by compromising the account or injecting into a dependency.

Look at the "Last Updated" date on the Marketplace listing. Then open the GitHub repo (if it exists) and check the actual commit history. Sometimes the Marketplace listing shows a recent publish date that just reflects an automated re-publish, not real maintenance.

3. Look at the `package.json` permissions before installing

Every extension declares what it can do in its package.json. You can find this in the source repo. Look for:

activationEvents — when does this extension activate? * means it runs on every file you open.
contributes.commands — what commands does it register?
Any explicit permission requests An extension that activates on * and makes network calls is doing something the moment you open VS Code, before you've even used it.

4. Grep the source for network calls

This takes 2 minutes if there's a public repo. Clone it or browse it on GitHub and look for:

fetch(
axios
http.request
https.request
xhr
WebSocket

Are those calls going to localhost, or to an external server? What data is in the request body? A linter that phones home is a red flag. A language server that connects to a known service is expected.

5. Check the dependencies

The extension's own code might be clean. Its dependencies might not be. Look at the package.json for third-party packages, then check them against known vulnerability databases. A single compromised npm package can turn a legitimate extension malicious overnight — this is exactly how supply chain attacks work.

This is tedious to do manually. Tools like VSCan automate it — paste in an extension ID and get a report on permissions, dependency vulnerabilities, and behavioral flags in seconds.

Red Flags That Should Make You Pause

Not all of these are disqualifying, but each one deserves a second look:

No public source code. If there's no GitHub repo (or the repo is empty), you can't verify what the extension does. This alone should give you pause.
Downloads don't match the repo activity. 500k downloads but 3 GitHub stars and no commit activity? Something is off.
Vague description. Malicious extensions often have generic, copy-pasted descriptions that don't clearly explain what the extension does.
Requested permissions don't match the stated purpose. A Markdown preview extension shouldn't need to run child processes.
Recently transferred ownership. Extensions sometimes get sold. New owners inherit the install base and can push updates. Check the publisher history if you can.

The Specific Extensions Worth Auditing Right Now

Some of the most dangerous extensions are the popular ones, because they're the ones attackers target. If you have any of these installed, it's worth running a quick check:

Extensions you installed years ago and forgot about
Extensions that haven't been updated recently
Any extension with a name very similar to a well-known one (check the publisher ID carefully)
AI coding assistants that have broad filesystem and network access by design The "is [specific extension] safe" question is one of the most common things developers search for — and the answer is almost never a simple yes or no. It depends on the version, the publisher's current situation, and the state of its dependencies at any given moment.

A Practical Workflow

Before installing any new extension:

Check the publisher is verified or well-known
Open the GitHub repo, confirm it's active
Check the dependency list manually
Look at what events trigger activation
Or do everything automatically through VSCan

Every quarter or so, do a pass over your installed extensions:

# List all installed extensions
code --list-extensions

For anything you don't recognize or haven't used recently: uninstall first, reinstall if you actually need it.

Why This Matters More Than It Used to

A year ago, the threat model for developer tools was mostly theoretical. It's not anymore.

We've seen self-propagating worms targeting VS Code extensions. We've seen extensions with millions of downloads caught harvesting credentials. Microsoft's own telemetry has flagged thousands of extensions with suspicious behaviors.

The attack surface is your entire development environment — your code, your credentials, your git history, your cloud provider tokens. Developers are high-value targets precisely because of what they have access to.

The VS Code Marketplace is not curated the way the iOS App Store is. It's closer to npm: anyone can publish, automated scanning catches some things but not everything, and you're largely responsible for what you run.

That's not a reason to avoid extensions. It's a reason to take 60 seconds before you click Install.

Check your extensions at vscan.dev

Concerning Amounts of Malware in the VS Code Marketplace: What Microsoft’s Own Logs Reveal

Ishaan Agrawal — Fri, 09 Jan 2026 02:45:18 +0000

If you are like me, your VS Code setup is a carefully curated collection of themes, linters, and productivity boosters. We trust the Visual Studio Marketplace to be a safe haven for tools that make our lives easier. But if you take a look under the hood at what is actually getting removed from the platform, the picture gets a lot uglier.

I recently went down a rabbit hole looking at the official list of removed extensions on GitHub, and it is a wake-up call for anyone who blindly clicks "Install."

The "Install First, Ask Questions Later" Problem

The way the Marketplace works is fundamentally based on a reactive model. Microsoft does have automated scans, but a staggering amount of malicious code only gets taken down after it has already been published and downloaded by unsuspecting developers.

When you look at the logs of removed extensions, you see a constant stream of entries flagged for things like:

Credential Theft: Extensions designed to scrape your .env files or SSH keys.
Typosquatting: Malicious clones of popular extensions like Prettier or ESLint that hope you won't notice a tiny misspelling in the name.
Remote Access: Plugins that open backdoors into your development environment.

Why This Matters to You

As developers, our machines are high-value targets. We have access to production servers, API keys, proprietary source code, and personal data. A single malicious extension has the same permissions as you do. It can read your files, track your keystrokes, and send your data to a remote server without you ever seeing a popup.

The scary part isn't just that these extensions exist. It is that they are actively making it onto the store, staying there for days or weeks, and only getting purged after the damage might already be done.

How to Protect Your Workflow

You don't have to stop using extensions, but you do need to stop treating the Marketplace like a curated app store where everything is vetted. Here is how I have changed my approach:

Check the Publisher: Look for the "Verified" checkmark. If a popular tool is being published by a random account with no history, stay away.
Verify the Numbers: If an extension claims to be a popular tool but only has 500 downloads while the real one has 5 million, you are looking at a typosquatting attempt.
Audit Your List: Every few months, go through your installed extensions. If something hasn't been updated in years, maybe double-check its safety.
Do a Deeper Scan: Since we know malicious code can bypass basic store filters, you need a more aggressive way to vet what you are installing. I suggest using a VS Code extension security analyzer. It will perform a deep security assessment by looking for obfuscated code, hidden network connections, and dangerous dependencies that standard checks often miss. That will give you a clear risk report before you let the code touch your machine.

Final Thoughts

The VS Code Marketplace is an incredible resource, but we have to stop assuming it is inherently safe. The "Removed Packages" list is proof that malware is constantly slipping through the cracks.

Take five minutes today to look at what you have installed. It is much better to spend a few minutes auditing your setup now than to spend a week dealing with a compromised machine later.

What's your take? Do you check the credentials of every extension you install, or do you just hit install and hope for the best?

🚨BREAKING: A Self-Propagating Worm Is Hitting VSCode Extensions Right Now— Here’s How to Protect Yourself

Ishaan Agrawal — Mon, 20 Oct 2025 00:03:45 +0000

Hey everyone, this is a quick but urgent post. A new, highly sophisticated worm is actively targeting developers on both the VSCode and OpenVSX marketplaces.

It's called "Glassworm," and you need to know about it.

What is Glassworm?

This isn't your typical malware. According to a new incident report, Glassworm is the first self-propagating worm to use invisible Unicode characters to hide its malicious code.

This means the malicious parts of the code can be completely invisible during a standard code review, making it incredibly stealthy and dangerous.

Why This Is So Dangerous

When an infected extension is installed, it's a full-blown disaster. The worm is a Remote Access Trojan (RAT) that immediately gets to work:

Steals Credentials: It harvests your NPM, GitHub, and Git credentials.
Spreads Itself: It uses those stolen credentials to infect other packages and extensions you have access to, just like a true worm.
Drains Wallets: It actively targets 49 different cryptocurrency wallet extensions.
Hijacks Your Machine: It deploys SOCKS proxies (turning your dev box into a criminal proxy) and installs a hidden VNC for full remote access.

To make matters worse, its command-and-control server is reportedly blockchain-based, making it extremely difficult to shut down.

How to Protect Yourself RIGHT NOW

We all install extensions—themes, linters, snippets. We trust them. But this incident proves we can't be complacent. The most immediate action you can take is to scan your extensions.

A fantastic (and free) tool for this is vscan.dev.

It's a security analyzer built specifically for VS Code extensions. You can paste in the name of an extension, and it will run a deep analysis of its code, permissions, dependencies, and network activity before you install it. It's designed to catch exactly this kind of suspicious behavior.

Your New Security Workflow (Starting Today)

Audit Your Current Extensions: Go to vscan.dev and check the extensions you already have installed.
Scan Before You Install: Make this a new habit. Before you click "Install" on any new extension, run it through vscan.dev first.
Review the Report: Look for red flags like dangerous API usage, suspicious network connections, or vulnerable dependencies.

This is an active, ongoing threat. Don't assume your editor is safe. Take 10 minutes, scan your tools, and stay vigilant.

Stay safe out there.

Are Your VSCode Extensions Safe? The Risk We Don’t Talk About

Ishaan Agrawal — Mon, 15 Sep 2025 01:58:47 +0000

Every developer I know has the same ritual:

Open VSCode.
Search for an extension that solves the problem at hand.
Click Install.

Done. Back to coding.

It feels harmless — almost routine. But every click gives someone else’s code permission to run inside your editor. And sometimes, that trust is misplaced.

The Quiet Problem with Extensions

VSCode extensions aren’t sandboxed little toys. They can:

Read and write files in your workspace.
Spawn background processes.
Send data over the network.

And the scary part? Even a “safe-looking” extension can turn risky overnight if the maintainer sells it or if a dependency gets compromised. Supply-chain attacks thrive in exactly these blind spots.

We’ve already seen examples where extensions with millions of downloads were caught doing shady things: crypto-mining, credential harvesting, injecting ads. Most of them looked legitimate until someone finally dug into the code.

Why We Rarely Notice

The VSCode Marketplace gives us stars, reviews, and download counts — but none of that says anything about what’s happening under the hood. A theme extension with ten lines of CSS might still request filesystem access. A linter might quietly collect telemetry.

And honestly, most of us never read the manifest or source before installing. We just trust the numbers.

Tools That Help Us See

That’s why security analyzers for extensions matter. VSCan is one example — it scans VSCode extensions and highlights things developers often miss:

Overly broad permissions.
Vulnerable or outdated dependencies.
Privacy or security concerns.

It generates a clear report so you can make an informed decision before hitting Install.

A Better Habit

We’ve normalized running npm audit or checking Docker images for CVEs. Why not treat our editor the same way?

Next time you’re about to install that shiny “Markdown Preview Ultra++” plugin, pause. Ask:

Does it really need the permissions it’s asking for?
Who maintains it, and how active is the repo?
Has anyone looked at its dependencies lately?

And if you want a quick head start, running it through a tool like VSCan takes seconds.

Closing Thought

The extensions we install aren’t just productivity boosters — they’re part of our attack surface. The sooner we treat them that way, the safer our workflows will be.

So maybe the next time you hit Install, don’t just look at the stars. Take a peek under the hood.

👉 Try scanning your extensions: vscan.dev

VSCode Extensions are Malicious—Here's What I Found After Scanning 1,000 of Them

Ishaan Agrawal — Thu, 26 Jun 2025 20:03:47 +0000

When you're browsing the web, you wouldn't download random files from untrusted sources.

So why are we so comfortable installing random Visual Studio Code extensions—without knowing what they do under the hood?

Visual Studio Code extensions run with full access to your machine. That includes your file system, network, terminal, and even your credentials.

And here's the catch: there's no sandbox, no permissions model, and no built-in validation to stop them from going rogue.

The Hidden Risk in Everyday Development

VSCode is the most widely used code editor in the world, with over 14 million developers relying on it monthly and controlling roughly 75% of the code editor market.

Its powerful extension ecosystem is a key reason for its success. Extensions add support for languages, linters, themes, and advanced features. But they also introduce a serious and largely unaddressed risk: every extension you install executes with the same system-level privileges as the editor itself.

Extensions can:

Read and write files anywhere on your system
Open unrestricted network connections
Launch subprocesses
Modify environment variables and configuration files

It's essentially the same as running an unvetted Node.js application on your machine, under the assumption that it won't abuse its access.

I wanted to understand the real extent of this problem...

What the Data Says

Using the tool VSCan, I scanned 1,077 popular extensions from the VSCode Marketplace.

Here are the results:

Category	Count	Description
Malicious Functionality	3	Detected by reputed anti-virus engines
Malicious Network Connections	7	Contacting dangerous IPs
Vulnerable Dependencies	33	Outdated libraries with critical flaws
Hardcoded Secrets	39	Credentials, tokens, and API keys publicly exposed
Poor Security Hygiene	204	Bad permission regulation, no version control, no audits
High Permissions Usage	71	Activated on all files or using unrestricted access patterns

These aren't theoretical risks. In several cases, extensions with tens of thousands of downloads were actively reaching out to suspicious infrastructure, using dangerous APIs, or leaking secrets in plain text.

Building VSCan

As a security researcher and developer, I wanted a way to analyze extensions before trusting them. So I built VSCan—a free tool that statically analyzes VSCode, Cursor, and Windsurf extensions for malicious behavior and security risks.

VSCan inspects every part of an extension's package, looking for:

Obfuscated or malicious code
Dangerous API usage and activation patterns
Insecure permissions and shell execution
Known vulnerabilities in bundled dependencies
Hardcoded secrets like API keys or credentials
Suspicious network endpoints
Low-quality development practices flagged by OSSF Scorecard
High-risk logic, detected through AST and LLM-based code reasoning

Under the Hood: How VSCan Works

VSCan uses static analysis to inspect everything inside an extension bundle, without executing any code.

The engine analyzes:

package.json for activation events, main scripts, and permissions
JavaScript/TypeScript files using Babel ASTs
Dependency trees extracted from package-lock.json
Network calls to external domains
Command execution via child_process or dynamic imports
Secret patterns using entropy + regex-based detection
OSSF Scorecard data for repo-level security practices
AI-assisted reasoning to verify hidden or obfuscated intent

Experimental Runtime Sandboxing

Static analysis has its limits. Some malicious behavior only occurs after installation or under specific runtime conditions.

That's why I've started building a custom sandbox layer to limit extension capabilities at runtime. It works by intercepting sensitive operations—file access, shell execution, and network activity—and enforcing restrictions on a per-extension basis.

There is currently no permission isolation in VSCode. This sandbox prototype is an early step toward bridging that gap.

Who This Is For

VSCan is designed for:

Developers who want to verify third-party extensions
Security engineers auditing supply chain components
Teams managing secure development environments
Extension authors checking for issues before publishing
Users of VSCode forks like Cursor or Windsurf seeking safer defaults

Whether you're installing one extension or auditing hundreds, this tool can catch issues you won't spot by just reading the README.

Try It

No signup required. Works directly in the browser. Fully open to the community.

Start scanning extensions here: https://vscan.dev

If you're using VSCode and have never looked inside your extensions, it might be time. Because that helpful syntax highlighter or theme switcher might be doing a lot more than just highlighting code.