When Manifold Security pulled 77 malicious extensions from Open VSX between July 26 and August 1, 2026, many security teams thought, "We don't use Open VSX, so this doesn't affect us." This mindset allows these attacks to succeed.
Evil twin extensions exploit assumptions about developer tools. Here are five myths that need to be debunked.
Myth 1: "We only use official marketplaces, so we're safe"
Reality: Marketplace approval doesn't equal security validation.
The 77 malicious extensions were on Open VSX, a legitimate marketplace. They passed automated checks and appeared official enough for developers to install them.
Your official marketplace has a submission process, not a security audit. Most marketplaces check for basic malware signatures and policy violations. They don't reverse-engineer every extension to verify its claims.
Even if you've standardized on VS Code's official marketplace, you're facing the same issue: minimal verification. Anyone can publish with just a developer account and patience.
Myth 2: "If an extension isn't accessing source code, it's not a threat"
Reality: Metadata is the reconnaissance phase of a targeted attack.
The extensions identified by Manifold Security didn't steal code. Instead, 19 collected CI environment identifiers, cloud development environment details, installed packages, and system configurations. To some, that might not seem like a breach.
Here's what an attacker does with that metadata: they map your tech stack, identify your CI/CD tools, catalog your dependencies, and profile your development patterns. They learn which teams use which cloud providers and see which packages you rely on.
Then they launch a targeted attack based on this information. It could be a malicious package mimicking one you use, a phishing campaign referencing your tools, or a supply chain attack against a dependency you can't easily replace.
Metadata exfiltration is patient reconnaissance. By the time you notice the actual attack, they've already spent weeks understanding your environment.
Myth 3: "Our developers know how to spot fake extensions"
Reality: Evil twins succeed because they're visually and functionally identical to legitimate tools.
Your developers check publisher names, download counts, star ratings, and descriptions. So do attackers. They copy everything: the icon, the feature list, the screenshots, the documentation structure.
The malicious extensions on Open VSX impersonated real tools. They used names close enough to the originals that autocomplete would suggest them. They often worked exactly like the legitimate version because they were wrappers around the real extension, with exfiltration code added.
A developer installing "prettier-code-formatter" versus "prettier-codeformatter" isn't being careless. They're being human. The cognitive load of checking every character in every package name for every tool is unrealistic.
Myth 4: "We'll catch malicious extensions through code review"
Reality: Most organizations don't review extension code, and even if you do, obfuscation defeats casual inspection.
How many extensions has your team installed this month? Now ask yourself: for how many did someone read the source code?
Extensions are treated like SaaS tools. You evaluate them based on functionality and reviews, not code audits. Even teams with strong security practices rarely decompile and analyze every browser extension or IDE plugin before installation.
When you do review code, you're looking at obfuscated JavaScript or compiled binaries. The malicious extensions used standard obfuscation techniques. The exfiltration logic was buried in initialization routines and disguised as telemetry or update checks.
Unless you're running static analysis tools specifically configured to detect data exfiltration patterns, you're not going to spot this in a manual review.
Myth 5: "We can block this at the network level"
Reality: Exfiltration traffic looks identical to legitimate extension telemetry.
The extensions sent data to external endpoints. Your network monitoring saw HTTPS POST requests to domains that looked like analytics services or CDN endpoints. Nothing triggered an alert because nothing looked abnormal.
Modern extensions communicate constantly. They check for updates, send usage metrics, fetch configuration data, and sync settings. Blocking all outbound traffic from developer tools would break half your productivity stack.
You can't distinguish malicious metadata collection from legitimate telemetry without deep packet inspection of encrypted traffic, which means SSL interception, which means breaking your developers' workflows and potentially violating tool licensing agreements.
Network-level blocking is necessary but not sufficient. By the time you've identified the malicious endpoint, the data has already left.
What to do instead
Stop treating developer tools as low-risk productivity enhancers. They have access to your entire development environment, your credentials, your infrastructure configurations, and your deployment pipelines.
Implement extension allowlisting. Don't let developers install arbitrary tools. Maintain a vetted list of approved extensions, review it quarterly, and require security approval for additions. This slows down tool adoption, which is the point.
Monitor extension installations. Your endpoint detection should log when extensions are installed, by whom, and from which source. Alert on installations outside your approved list. This won't prevent the initial installation, but it limits exposure time.
Audit extension permissions. Many extensions request far more access than they need. Review the permissions your approved extensions actually require. If a code formatter needs access to your clipboard and network stack, question why.
Segment development environments. Don't let developers run production credentials or access production systems from the same machine where they're installing third-party tools. Assume the development environment is compromised and architect accordingly.
Track your exposure. When a campaign like this gets disclosed, you need to know within an hour whether any of your developers installed the affected extensions. If you can't answer that question, you don't have visibility into your attack surface.
The 77 extensions were removed by August 3, 2026. The next campaign is already being prepared, and it won't target Open VSX. It'll target whatever marketplace your team actually uses, with whatever tools your developers actually need. The tactics don't change just because the platform does.
