Listen to this Post
Introduction: When a Familiar Extension Name Becomes a Hidden Security Risk
Developer tools are built on trust. Engineers install extensions to improve productivity, automate repetitive work, connect repositories, manage cloud environments, and simplify software development. In many cases, an extension is selected because its name looks familiar, its publisher appears legitimate, or an automated setup script installs it without requiring a human to inspect the source.
That trust is now becoming a valuable attack surface.
A newly discovered campaign involving counterfeit extensions on the Open VSX registry demonstrates how attackers can impersonate trusted developer tools without stealing source code, passwords, or access tokens. Instead, the malicious extensions focused on something that can be equally valuable during the early stages of a cyber operation: organizational identity.
The campaign collected details about development environments, Git repositories, CI/CD systems, cloud workspaces, and internal project structures. Much of this activity was openly described in the extensions’ own telemetry disclosures, creating an unusual situation in which the malware appeared transparent while still gathering intelligence that could help attackers identify valuable targets.
The discovery raises an important question for software teams: How safe is an extension name when the same name can exist under different ownership rules across multiple registries?
Original Summary: 77 Counterfeit Extensions Appeared in One Week
A Coordinated Wave of Extension Impersonation
Security researchers at Manifold Security reported that 77 suspicious packages appeared on the Open VSX registry between July 26 and August 1. Each package reused the name and namespace of a legitimate extension but was published through an account that did not own the original project.
The campaign was not limited to obscure or random software names. The impersonated namespaces included organizations and brands associated with major technology, enterprise, education, government, and developer ecosystems.
Among the names reportedly targeted were AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforce OSS, a U.S. federal agency, and marketplace.visualstudio, a namespace resembling the extension marketplace itself.
The scale and consistency of the campaign suggested organized automation rather than isolated abuse.
A Shared Infrastructure Point Connected the Packages
Although the counterfeit extensions impersonated many different organizations, they all communicated with a single external domain.
The domain had reportedly been registered only 11 days before the first suspicious package appeared. This timing created a strong connection between the infrastructure and the extension campaign.
Most of the packages transmitted only limited information, such as the hostname of the system where the extension was running. However, 19 extensions contained a more detailed information-collection component.
These higher-capability packages gathered information shortly after activation and transmitted it to the remote collector.
The Disclosure Was the Disguise
Telemetry Notices Created an Appearance of Transparency
One of the most unusual aspects of the campaign was that the extension listings openly included telemetry information.
The descriptions identified many of the fields collected by the software and stated that source code, credentials, passwords, and authentication tokens were not being taken.
Manifold Security examined the extension code and found that many of those claims were technically accurate.
The extensions did not appear to upload repository files. They did not directly collect access tokens. They did not behave like traditional credential-stealing malware.
However, the information they gathered could still provide attackers with a detailed map of an organization’s software-development environment.
This distinction is important because data does not need to be a password to create security risk.
The Collected Data Revealed Developer and Repository Identity
Seconds after activation, the more capable extensions reportedly collected system and editor information.
The data included:
The hostname of the device
The operating-system username
Editor-related details
A machine identifier
The Git remote host
The Git organization associated with the repository
The domain connected to the commit email
The active Git branch
The current HEAD commit
GitHub repository information
GitLab project paths
Codespaces-related identifiers
On a developer workstation, some of these details may appear ordinary. In a cloud development environment or build runner, however, they can expose the full identity of a private repository.
That information may reveal internal project names, business relationships, product development activity, infrastructure ownership, and the technology platforms used by an organization.
Repository Metadata Can Become High-Value Reconnaissance
A repository name may look harmless when viewed in isolation.
When combined with a Git organization, commit email domain, branch name, cloud workspace identifier, and CI/CD project path, it can become a powerful intelligence package.
For example, a repository named:
company-internal/payment-platform
could reveal information about a sensitive business system even if no source code is transmitted.
A branch named:
release/enterprise-cloud-migration
could expose an upcoming infrastructure change.
A Git remote such as:
[email protected]:organization/private-security-tools.git
could identify both the organization and the purpose of an internal project.
Attackers can use this information to prioritize targets, build phishing campaigns, search for exposed infrastructure, identify software supply-chain relationships, or prepare future intrusion attempts.
The One Disclosure That Did Not Match the Code
Continuous-Integration Data Was More Sensitive Than Advertised
Most of the telemetry disclosures reportedly matched the behavior found in the code.
However, researchers identified one important exception.
One extension claimed that its continuous-integration telemetry included only marker names and did not transmit their values. The code reportedly contradicted that statement by sending both the names and the values.
This was significant because the affected information was potentially the most sensitive data collected by the extension.
CI/CD environments frequently contain repository identifiers, project paths, workspace names, build metadata, deployment context, and other details that are not intended for public exposure.
Even when authentication secrets are excluded, CI-related values can reveal internal architecture and development activity.
A Small Disclosure Error Can Create a Large Security Gap
The misleading telemetry statement illustrates a broader challenge in software security.
Users may read a privacy or telemetry notice and assume that the description accurately represents the behavior of the software.
In this case, the listing appeared unusually transparent, but one of its most important claims was reportedly incorrect.
This creates a difficult trust problem: users cannot always verify whether a marketplace description matches the code that is actually executed.
Security teams should therefore treat telemetry disclosures as useful information rather than as proof of safety.
The Extensions Had Almost No Legitimate Function
A Checkmark Was Used to Create the Appearance of Normal Software
The counterfeit extensions reportedly offered little or no meaningful functionality.
One displayed a checkmark in the editor’s status bar. Another exposed a command that opened a message box. The telemetry beacon then transmitted collected information.
This design reduced complexity and limited the amount of suspicious behavior visible to users.
An extension does not need to perform a sophisticated attack to create risk. It only needs to install successfully, activate inside a trusted development environment, and communicate with an external service.
The minimal functionality may also have helped the packages appear harmless during casual inspection.
Built to Outlive the Takedown
The Collection System Was Designed for Persistence
The campaign’s infrastructure showed signs of resilience.
The collector domain was reportedly registered through a service that concealed registrant information and was purchased for a three-year period.
The extensions also treated nearly any HTTP response as a successful connection, including responses indicating an error.
This behavior may have allowed the beaconing process to continue without requiring a perfectly functioning server response.
The extensions reportedly retried communication for up to seven days and resumed attempts whenever the editor restarted.
DNS TXT Records Offered a Backup Communication Channel
If the primary collection endpoint became unavailable, the payload could query a DNS TXT record for a replacement address.
This design allowed the operator to move the collection infrastructure without publishing a new version of the extension.
The technique is strategically important because removing a malicious package does not automatically eliminate the infrastructure behind it.
A remote configuration channel can give an operator flexibility after discovery, takedown, or server disruption.
The ability to change destinations without updating the package also makes traditional blocklists less reliable if defenders focus only on the original domain.
The Payload Could Identify How the Extension Was Installed
The malicious code reportedly detected whether the extension had been installed because of workspace configuration.
It could distinguish between an extension installed intentionally by a developer and one introduced through repository configuration, such as development-container or extension recommendation settings.
This distinction may help attackers understand how the package spread.
An extension installed through a repository configuration could affect multiple developers or automated environments without each user manually searching for the extension.
Automated Installation Is Expanding the Risk
AI Agents and Provisioning Scripts May Trust Names Too Easily
The campaign emerged as developer environments become increasingly automated.
AI coding agents, development containers, cloud workspaces, provisioning systems, and setup scripts may install extensions based on names rather than manually verified ownership.
If two registries apply different ownership rules, the same extension name may point to different publishers.
This creates a dangerous ambiguity.
A tool that requests:
publisher.extension-name
may not be able to determine whether the result is the original extension or an impersonating package unless publisher identity and registry origin are explicitly validated.
Automation can therefore amplify a single naming weakness across many systems.
Registry Differences Can Turn Name Reuse Into a Supply-Chain Problem
Developer ecosystems often rely on multiple extension registries.
Each registry may have different rules for namespace ownership, publisher verification, package moderation, and name reuse.
A name that is protected in one ecosystem may be available to another publisher elsewhere.
When internal registries mirror external packages, this issue can become more complex.
An organization may unintentionally import a counterfeit package into a trusted internal environment if its synchronization process validates only the extension name.
The result is a supply-chain risk created not by compromised source code, but by inconsistent identity controls.
Deep Analysis: Detecting Suspicious Extension Activity
Checking Installed VS Code Extensions
Security teams can begin by reviewing installed extensions and their publishers.
code –list-extensions –show-versions
The output should be compared with an approved extension inventory.
Unexpected publishers, duplicate-looking names, or extensions that appeared without user approval should be investigated.
Reviewing Extension Installation Directories
On Linux systems, extensions may commonly be located under:
ls -lah ~/.vscode/extensions/
Administrators can review recently created directories with:
find ~/.vscode/extensions/ -maxdepth 1 -type d -printf '%TY-%Tm-%Td %TT %p ' | sort
This may help identify extensions installed during the period of suspected activity.
Searching for Suspicious Network Domains
Security teams can inspect extension files for embedded URLs.
grep -RInE 'https?://|dns|TXT' ~/.vscode/extensions/ 2>/dev/null
Any domain that is unfamiliar, recently registered, or unrelated to the extension’s expected publisher should be reviewed.
A domain discovered shortly after extension installation may deserve additional attention.
Reviewing Extension Package Metadata
Extension metadata can provide information about the publisher, version, activation events, and declared capabilities.
find ~/.vscode/extensions/ -name package.json -exec sh -c '
echo "===== $1 ====="
grep -E "\"name\"|\"publisher\"|\"version\"|\"activationEvents\"" "$1"
' _ {} \;
The publisher name should be checked against the legitimate project.
A familiar extension title does not guarantee that the publisher is authentic.
Monitoring Unexpected Connections From Editor Processes
On Linux, active network connections associated with the editor can be reviewed using:
ss -tpn | grep -Ei 'code|code-insiders'
Administrators may also inspect active processes:
ps aux | grep -Ei 'code|extensionHost'
Unexpected outbound connections shortly after the editor launches should be correlated with installed extensions.
Searching Development Logs for Network Indicators
Depending on the environment, editor logs may contain useful information.
grep -RInE 'http|https|dns|telemetry' ~/.config/Code/logs/ 2>/dev/null
The exact log location may vary by operating system and editor distribution.
Security teams should avoid relying on a single log source and instead correlate endpoint, DNS, proxy, and firewall data.
Checking Git Metadata Exposure
Developers can inspect the repository information available to extensions.
git remote -v
The active branch can be checked with:
git branch --show-current
The current commit can be reviewed using:
git rev-parse HEAD
These commands demonstrate why Git metadata can be useful to attackers even when source files are not copied.
Reviewing Dev Container Configuration
Repositories may automatically recommend or install extensions through development-container settings.
find . -path '/.devcontainer/' -type f -maxdepth 4 -print
A configuration file can be reviewed with:
cat .devcontainer/devcontainer.json
Teams should verify that every extension listed in development-container configuration belongs to a trusted publisher.
Applying Extension Allowlisting
Organizations can maintain an approved extension list.
An example policy file might contain:
[email protected]
[email protected]
[email protected]
The goal is to validate both the publisher and the version rather than trusting the extension name alone.
What Undercode Say:
Identity Is Becoming the New Attack Surface
This campaign demonstrates that software identity is no longer a minor marketplace detail.
The publisher, registry, namespace, version, and installation source must all be treated as security signals.
The Attack Did Not Need Source-Code Theft
The extensions reportedly avoided directly stealing source code.
That may have reduced the chance of triggering immediate security alarms.
Metadata Can Be Enough for Target Selection
Repository names, organization identifiers, branch information, and CI/CD paths can reveal where valuable systems are located.
Attackers may use that information before launching a more aggressive operation.
The Campaign Appears Designed for Reconnaissance
The collected data is consistent with target mapping.
It can help identify organizations, development platforms, internal projects, and potentially valuable infrastructure.
Transparency Can Be Used as a Trust Mechanism
The telemetry disclosures created an appearance of openness.
Users may have interpreted the detailed descriptions as evidence that the extensions were legitimate.
A Mostly Accurate Disclosure Can Still Hide a Critical Problem
The fact that many claims matched the code may have made the incorrect CI statement more difficult to notice.
Trust can be strengthened by partial accuracy.
Minimal Functionality Reduced Suspicion
A checkmark and a simple command can make an extension appear functional.
The real purpose may remain hidden behind ordinary interface behavior.
Persistence Was Built Into the Communication Design
Seven-day retries and editor-restart behavior increased the chance that information would eventually reach the collector.
Temporary network failures were unlikely to stop the campaign.
DNS-Based Redirection Added Operational Flexibility
A DNS TXT record could allow the operator to replace infrastructure without republishing the extension.
This is a notable resilience feature.
Removing Packages Does Not End the Entire Threat
Registry takedowns are important, but they may not remove already installed extensions.
Endpoints still require investigation.
Recently Registered Domains Should Receive More Attention
A new domain contacted immediately after an editor launches can be a meaningful detection signal.
Domain age should be part of behavioral monitoring.
Automated Development Environments Increase Exposure
Cloud workspaces and build runners may activate extensions without traditional user interaction.
This can make malicious packages harder to notice.
Repository Configuration Can Become a Delivery Mechanism
Development-container settings and workspace recommendations may distribute extensions across teams.
A single configuration change can affect many users.
AI Coding Agents May Expand the Risk
AI systems that install tools by name could reproduce the same trust mistake at machine speed.
Agentic workflows require stronger identity validation.
Extension Names Are Not Sufficient Security Controls
A familiar name does not prove ownership.
The publisher and registry must also be verified.
Internal Mirrors Need Stronger Validation
Organizations that mirror external registries should preserve publisher identity and package provenance.
Name-only synchronization is increasingly risky.
Publisher Verification Should Become Mandatory
Unverified-publisher warnings should not be treated as cosmetic notices.
Automated installation should stop when publisher identity cannot be confirmed.
Version Pinning Can Reduce Unexpected Changes
Pinning a trusted version limits the risk of silently receiving a different package.
It also improves incident investigation.
Security Teams Should Monitor Developer Tools Like Production Software
Extensions run inside environments that may access repositories, cloud services, build systems, and internal networks.
They deserve equivalent security oversight.
Developer Productivity Tools Have Become Supply-Chain Components
An editor extension is no longer merely a user-interface enhancement.
It can be part of the organization’s software supply chain.
CI/CD Metadata Requires Better Protection
Build identifiers and project paths may reveal sensitive internal information.
Security controls should classify this data appropriately.
Telemetry Must Be Independently Validated
Marketplace descriptions should not be considered authoritative evidence.
Code review and behavioral monitoring remain necessary.
Behavior-Based Detection Is Essential
A malicious package may use a legitimate-looking name.
Network activity may reveal the threat more reliably than branding.
The Campaign Shows the Value of Low-Noise Collection
Small metadata requests can avoid the attention generated by credential theft.
Quiet reconnaissance may be more difficult to detect.
Organizations Should Track Extension Provenance
Teams should know who published an extension, where it came from, and how it entered the environment.
Unknown provenance should be treated as a risk.
Developers Need Clear Security Guidance
Security teams should explain why publisher identity matters.
A simple extension-installation policy can prevent many mistakes.
Registry Operators Should Improve Namespace Protection
Cross-registry identity conflicts should be addressed through stronger ownership controls.
Verified publishers should receive better protection against impersonation.
The Industry Needs Portable Publisher Identity
A trusted publisher should not become unverified simply because software is distributed through another registry.
Identity should be consistent across ecosystems.
Extension Review Should Include Network Behavior
Static inspection alone may not reveal every risk.
Outbound communication should be monitored after activation.
New Domains Should Be Correlated With New Packages
The combination of a recently published extension and a recently registered domain is a strong investigative signal.
Neither indicator should be viewed in isolation.
Cloud Development Environments May Reveal More Than Local Machines
Cloud workspaces can expose complete project identifiers and service metadata.
Their telemetry should be monitored carefully.
Build Runners Are Valuable Intelligence Sources
CI systems often contain information about projects, environments, deployment stages, and infrastructure.
Even limited collection can support future attacks.
Security Automation Must Verify Before Installing
Automation should not assume that a package is legitimate because its name is familiar.
Publisher validation must happen before deployment.
The Threat Model Is Shifting From Code Theft to Context Theft
Attackers may first collect information about what an organization builds and how it operates.
That context can guide later attacks.
Organizations Should Prepare for Follow-On Activity
Teams affected by similar extensions should review phishing attempts, repository access events, and suspicious infrastructure activity.
The initial collection may only be the reconnaissance stage.
The Most Important Lesson Is Simple
Trust the identity of the publisher, not only the identity of the package.
✅ The Campaign Included 77 Counterfeit Open VSX Packages
The reported campaign involved 77 packages appearing between July 26 and August 1.
The packages reused legitimate extension names and namespaces while being published by accounts that did not own the original projects.
This supports the conclusion that the activity was coordinated and relied on identity impersonation.
✅ The Extensions Collected Developer and Repository Metadata
The more capable packages reportedly gathered host, user, editor, Git, repository, branch, commit, and CI/CD information.
Researchers indicated that the extensions generally did not collect source code, credentials, or authentication tokens.
However, the metadata could still expose valuable organizational intelligence.
✅ The Campaign Used Persistent Beaconing and DNS-Based Fallback
The payload reportedly retried communication for several days and resumed activity after editor restarts.
It could also query a DNS TXT record for an alternative collection destination.
This indicates that the infrastructure was designed to remain operational even if the original endpoint changed.
❌ A Telemetry Disclosure Was Not Fully Accurate
One package reportedly claimed that CI telemetry included marker names but not their values.
Code analysis indicated that both names and values were transmitted.
This discrepancy is significant because CI information may contain sensitive project and environment context.
✅ Open VSX Removed the Reported Packages
The suspicious packages were reportedly removed from the registry on August 3.
Package removal reduces future exposure through the registry but does not automatically remove copies already installed on developer systems.
Organizations should still investigate affected endpoints and related network activity.
Prediction
(+1) Stronger Publisher Verification Will Become a Standard Requirement
Developer registries are likely to introduce stronger publisher identity controls, namespace protection, and clearer verification indicators.
Organizations will increasingly require extensions to be approved by publisher and version before automated installation.
This should reduce the risk of simple name-based impersonation.
(-1) AI Agents Could Increase the Speed of Extension Supply-Chain Abuse
As AI coding agents become more capable of installing tools and configuring development environments, attackers may attempt to exploit registry identity gaps at a larger scale.
An agent that trusts names without validating publishers could deploy counterfeit software faster than a human user.
Future attacks may therefore target automated developer workflows rather than individual developers.
(+1) Behavioral Monitoring Will Improve Detection
Security platforms are likely to focus more heavily on editor processes contacting newly registered domains.
Correlating extension installation, editor startup, DNS activity, and outbound connections could expose suspicious packages earlier.
This may help defenders identify malicious extensions even when their names appear legitimate.
(-1) Metadata-Only Collection May Become More Common
Attackers may increasingly avoid direct credential theft and instead collect organizational context.
Repository names, CI/CD identifiers, cloud workspace details, and development metadata can support targeted attacks while generating less immediate suspicion.
The next generation of supply-chain threats may therefore be quieter, more selective, and more difficult to classify as traditional malware.
▶️ Related Video (84% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.infosecurity-magazine.com
Extra Source Hub (Possible Sources for article):
https://www.quora.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
