TL;DR: Two counterfeit VS Code Marketplace extensions masquerading as Markdown All in One beaconed usernames and hostnames over cleartext HTTP and fetched remote files to disk after installation, without user interaction, according to Manifold Security. The case shows why marketplace trust, runtime behavior, and extension governance matter more than static review alone.
At a glance
What this is: Manifold Security identified counterfeit VS Code extensions that impersonated a popular Markdown plugin, beaconed host details over cleartext HTTP, and pulled remote content to disk at runtime.
Why it matters: It matters because developer tooling can become an execution path inside trusted endpoints, bypassing code review and dependency controls while still exposing identity and host data.
Context
A malicious editor extension is a supply chain problem because the code executes inside a trusted developer workstation, often with broad local access and little scrutiny after installation. The risk is not just what the package looked like at publish time, but what it does once it is active in the editor.
This case also has a clear identity and access angle: the extension collected local username and hostname, then used a remote server as a live delivery channel. That makes the problem about runtime trust boundaries as much as about marketplace abuse and deceptive packaging.
Key questions
Q: What should teams do when a developer extension is imitating a trusted tool?
A: Treat it as a supply chain and endpoint risk, not a simple hygiene issue. Remove the extension, revoke trust in the publisher and package name, inspect the machine for downloaded artifacts or follow-on traffic, and check whether similar lookalike packages have already been installed elsewhere in the estate.
Q: Why is a harmless-looking extension payload still a security problem?
A: Because the risk is not only the first file the extension ships with, but the server-side channel it can reach after install. If the extension can fetch content at runtime, the operator can change behavior without changing the package version, which turns a benign snapshot into an ongoing control problem.
Q: How can security teams detect malicious behavior in editor extensions?
A: Look for process-level network telemetry, unexpected HTTP requests, file writes to user download paths, and automatic activation on startup. Static package review is useful, but it will miss runtime actions that only appear after the extension is installed and executed in a real environment.
Q: Should organisations treat marketplace reputation as sufficient trust for developer tools?
A: No. Marketplace listing quality helps, but it does not prove runtime safety, publisher intent, or supply chain integrity after installation. Organisations should combine allowlisting, telemetry, and periodic review of installed extensions so that trust is based on observed behavior rather than branding alone.
Technical breakdown
How counterfeit extensions abuse editor trust
VS Code extensions run inside the editor process and inherit the user's local privileges, which makes them materially different from ordinary downloaded files. A counterfeit package can borrow the name, description, and branding of a legitimate extension to trigger installation, then activate automatically on startup. In this case, the extension did not need command execution or explicit user consent after install. The threat is the combination of trusted marketplace placement, automatic activation, and a runtime environment that is usually outside normal software supply chain inspection.
Practical implication: Treat editor extensions as executable software with runtime access, not as static assets that can be approved once and ignored.
Why cleartext beaconing and remote file drops matter
The sample sent usernames and hostnames to a hardcoded IP over HTTP and then fetched a file to disk from the same operator-controlled server. Even if the first payload is harmless, a remote-content-to-disk path is a live delivery mechanism because the server content can change later without republishing the extension. Cleartext transport also makes the traffic easier to observe but not safer, because the goal is collection and staging, not secrecy. The important control gap is that the extension's behavior is determined at runtime, outside the original package review. See the Command and Control (C2) Guide.
Practical implication: Monitor outbound requests from developer tools and treat any extension that pulls operator-controlled content at runtime as a high-risk supply chain event.
Why marketplace reputation does not equal runtime safety
The counterfeit package relied on resemblance to a well-known extension and on the expectation that marketplace listing signals trust. That is a common failure mode in software ecosystems: installation decisions are made from identity cues, while the actual risk sits in runtime behavior that is easy to miss. When a package can change its effect through server-side content, static scanning only answers what shipped, not what executed later. This is a governance gap between publisher reputation, artifact inspection, and operational control over code after install.
Practical implication: Add runtime verification and extension allowlisting to your software governance model, because package metadata alone cannot prove safe behavior.
Threat narrative
Attacker objective: The objective is to establish a trusted foothold in developer environments, collect basic host identity data, and retain a controllable delivery path for future payloads.
- Entry occurred when a developer installed a counterfeit VS Code extension that imitated a trusted Markdown tool and activated automatically on startup.
- Credential or identity exposure happened when the extension collected the local username and hostname and transmitted them to operator infrastructure over cleartext HTTP.
- Impact came from the live delivery channel, because the extension could fetch remote content to disk and allow the operator to change what was delivered without changing the installed package.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Counterfeit developer extensions are a governance failure, not just a malware problem. The real issue is that trusted tooling can be impersonated, installed, and then operate inside the developer runtime with little resistance from conventional code review or dependency scanning. That means the control boundary sits at execution time, not at package publication. Practitioners should treat editor marketplaces as an extension of the software supply chain, not as a separate trust domain.
Host identity collection is enough to matter even without password theft. A username and hostname may look low-value, but in a developer environment they are useful for targeting, profiling, and correlating later activity. The fact that the sample used cleartext HTTP makes the exfiltration obvious, but the more important point is that the extension had no legitimate reason to collect or transmit that data. Security teams should treat even small data flows from developer tools as indicators of broader intent.
Runtime delivery channels are the real control gap here. A package that pulls content from an operator-controlled server can change behavior after installation without any republish event, which breaks the assumption that a clean artifact stays clean. That is especially relevant to secrets management and software governance because the threat is not limited to source code or signed artifacts. Continuous inspection of live behavior is the only way to see this class of abuse reliably.
Marketplace takedown is incident response, not prevention. The reported removal shows that abuse can be detected and disrupted, but it does not close the underlying distribution model. Counterfeit extensions can reappear under new identities, which means teams need controls that work before install and after activation. The practitioner implication is to govern developer toolchains as a runtime-risk surface, not as a one-time procurement decision.
What this signals
Editor marketplaces are becoming an identity security surface. A package that impersonates a trusted tool can collect host identity, establish a runtime delivery path, and bypass the places defenders usually look first. That means developer environments need the same kind of policy enforcement and runtime monitoring applied to other high-trust execution paths.
Secret and asset governance now extends to tooling that can change after install. The practical lesson is that the security posture of a developer workstation is not determined only by source repositories and CI pipelines. Any extension or plugin that can reach external infrastructure should be treated as a governed runtime dependency, not a convenience add-on.
For practitioners
- Enforce extension allowlisting for developer environments Restrict installation to approved publishers and approved package names, and block lookalike extensions that borrow the identity of trusted tools.
- Monitor outbound traffic from editor processes Alert on cleartext HTTP beacons, unexpected host telemetry, and remote file retrieval from extension runtimes and other developer tooling.
- Remove suspicious extensions and inspect local downloads Uninstall any counterfeit or unapproved editor extension, then delete downloaded payload files such as a.txt or update.txt and review the host for similar artifacts.
- Treat editor extensions as live runtime code Add them to your software supply chain governance and review their post-install behavior separately from the marketplace metadata and published package contents.
Key takeaways
- This incident shows that counterfeit developer tools can become execution paths inside trusted endpoints, even when they appear small and harmless at install time.
- The extension collected basic host identity and used a live remote channel, which is enough to create targeting, staging, and follow-on risk.
- Allowlisting, runtime telemetry, and post-install review are the controls that matter when a package can change behavior after it is installed.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Secrets Management Guide · Ultimate Guide to NHIs · Top 10 NHI Issues
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | The extension consumes a remote operator-controlled HTTP endpoint as part of its malicious behavior. |
| Recommendation — Review outbound API consumption from developer tools and block unsanctioned runtime fetches. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The extension exfiltrates host identity data and uses a hidden delivery channel that can expose sensitive context. |
| NHI-06 — Insecure Cloud Deployment Configurations | The abuse depends on weak trust in a remotely controlled payload source rather than the published package. | |
| Recommendation — Detect and revoke suspicious runtime channels that leak environment data from non-human assets. Treat remotely updated payload channels as governed deployment surfaces and restrict them tightly. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Unauthorized extensions are software assets that need inventory, approval, and removal controls. |
| Recommendation — Inventory installed editor extensions and remove any package that is unapproved or impersonating a trusted tool. | ||
| NIST SP 800-53 Rev 5 | SA-22 — Unsupported System Components | Counterfeit editor extensions function as untrusted components introduced outside approved acquisition controls. |
| Recommendation — Prevent unsupported or unapproved components from entering developer environments. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The extension inherits the developer's privileges, so authorization scope is central to the risk. |
| Recommendation — Limit developer workstation entitlements so extensions cannot access more than their required runtime scope. | ||
Key terms
- Counterfeit Extension: A counterfeit extension is a malicious or deceptive plugin that imitates a legitimate tool to gain user trust and execution rights. In editor ecosystems, the risk is not only installation fraud but also what the code does after activation inside a privileged runtime.
- Runtime Delivery Channel: A runtime delivery channel is a live remote path that an installed component can use to fetch content or instructions after deployment. It matters because the behavior of the installed software can change without a new package version, which defeats static approval checks.
- Developer Toolchain Security: Developer toolchain security is the practice of protecting the software development environment as a security boundary. It covers IDEs, extensions, package managers, build tools, and assistants that can access code, secrets, or production-connected workflows.
- Extension Allowlisting: Extension allowlisting is the policy of permitting only approved plugins or add-ons on developer systems. It reduces exposure by preventing unknown tools from reading source code, collecting tokens, or opening outbound channels without oversight.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a practical fit for teams that need to govern runtime trust, secrets, and machine identity risk across modern environments.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org