Hackers Are Impersonating VS Code on GitHub to Deliver Malware — Here’s What Developers Need to Know

Author

If you received a security alert about a Visual Studio Code vulnerability in your GitHub notifications recently, stop before you click anything. It may be a trap.

A large-scale malware campaign is currently targeting developers on GitHub by posting convincing fake security alerts in the Discussions sections of thousands of repositories. The attack is sophisticated, well-coordinated, and designed specifically to exploit the trust developers place in familiar tools and platforms.

The Attack: Fake Alerts, Real Consequences

According to a report by BleepingComputer, threat actors craft phony vulnerability advisories with alarming titles like “Severe Vulnerability — Immediate Update Required.” Many posts include fabricated CVE IDs and impersonate real code maintainers or security researchers to appear legitimate.

Application security firm Socket identified the campaign and confirmed thousands of nearly identical posts have appeared across repositories in a matter of minutes, launched from newly created or low-activity accounts. Because GitHub Discussions trigger email notifications for watchers and participants, these posts land directly in developers’ inboxes — not just on the platform.

This is not a small, targeted attack. This is a coordinated, automated spam operation at scale.

How the Malware Delivery Chain Works

The fake alerts direct victims to download a “patched” version of the affected VS Code extension — hosted not on the official VS Code Marketplace, but on Google Drive. That detail alone should raise red flags, but attackers count on users acting quickly out of panic.

Clicking the Google Drive link triggers a cookie-driven redirect chain that eventually lands victims on an external malicious domain. From there, a JavaScript reconnaissance script springs into action, silently collecting the victim’s timezone, locale, operating system details, user agent, and signals that indicate whether the visitor is a real human or an automated scanner.

This data gets packaged and sent to a command-and-control server. The script functions as a Traffic Distribution System (TDS) — a filtering layer that weeds out bots and security researchers before delivering the actual second-stage payload only to confirmed human victims. Socket researchers were unable to capture that final payload, but the infrastructure signals a professionally organized threat operation.

This Isn’t the First Time GitHub’s Systems Have Been Weaponized

Attackers have repeatedly turned GitHub’s own notification infrastructure against its users. In March 2025, a phishing campaign targeted 12,000 GitHub repositories with fake security alerts that tricked developers into authorizing a malicious OAuth app, handing attackers full account access.

Back in June 2024, threat actors abused GitHub’s email system through spam comments and pull requests to funnel users toward phishing pages.

The pattern is clear: GitHub’s trusted notification systems make an ideal delivery mechanism for social engineering attacks. Developers — trained to act quickly on security advisories — are particularly high-value targets. Compromising a developer’s machine or credentials can cascade into supply chain attacks that impact millions of downstream users.

How to Protect Yourself: A Practical Defense Checklist

Staying safe requires slowing down and applying a short checklist before acting on any security alert. Here’s what you should do:

1. Verify the CVE independently. Never trust a CVE mentioned only in a GitHub Discussion. Cross-check it on the National Vulnerability Database (NVD), MITRE’s CVE program, or CISA’s Known Exploited Vulnerabilities catalog. If it doesn’t appear there, treat it as fabricated.

2. Never download extensions from unofficial sources. VS Code extensions belong on the official VS Code Marketplace. A link to Google Drive, Dropbox, or any third-party file host is an immediate red flag — no legitimate extension update ever comes from there.

3. Check the poster’s account history. Before trusting any security advisory, look at the account that posted it. Newly created accounts or profiles with little activity posting urgent warnings across multiple repositories are hallmarks of automated spam campaigns.

4. Ignore mass tagging. If a Discussion post tags dozens of unrelated users to maximize reach, that’s social engineering by design. Legitimate vulnerability disclosures follow responsible disclosure processes, not mass notifications.

5. Enable two-factor authentication (2FA) on GitHub. Even if you click a malicious link, 2FA significantly limits what attackers can do with stolen credentials. GitHub supports authenticator apps and hardware security keys — use them.

6. Use endpoint security tools. A reputable endpoint detection and response (EDR) tool can flag suspicious scripts or outbound connections before they cause damage. Don’t rely solely on instinct.

The Bottom Line

Developers are not invincible to social engineering — in fact, their technical credibility can make them overconfident. Attackers know this and engineer campaigns specifically designed to exploit the sense of urgency that security alerts create.

The next time a “critical vulnerability” lands in your GitHub notifications with a suspicious download link attached, treat it with the same skepticism you’d give a phishing email. Slow down, verify independently, and trust only official channels.

Your tools are only as secure as the habits you build around them.