Fake VS Code Security Alerts on GitHub Spread Malware in Massive Phishing Attack

A large-scale phishing campaign is actively targeting developers on GitHub by abusing the platform’s Discussions feature to distribute fake Visual Studio Code (VS Code) security alerts.

The campaign appears highly coordinated, with thousands of near-identical posts discovered across multiple repositories, indicating automated mass exploitation rather than isolated abuse.

Attackers are creating GitHub Discussions with alarming titles such as “Visual Studio Code Severe Vulnerability Immediate Update Required” and “Critical Exploit Urgent Action Needed.”

These posts often include fabricated CVE references and fake affected version ranges to appear credible.

Security researchers warn that these malicious posts are designed to look like legitimate vulnerability disclosures, tricking developers into downloading malware disguised as urgent updates.

The messages urge users to download a “patched” version of VS Code via external links, bypassing official distribution channels.

In reality, VS Code updates are never delivered through third-party file-sharing services, making these links a clear red flag.

Early investigation shows these posts are frequently published by newly created or low-activity accounts. Many discussions also tag multiple developers, increasing visibility and adding pressure to act quickly.

Abuse of GitHub Notifications

One of the most effective aspects of this campaign is its use of GitHub built-in notification system. When a Discussion is created or users are tagged, GitHub automatically sends email notifications to watchers and participants.

This means the phishing messages are not limited to the platform itself they are delivered directly to developers’ inboxes, making them appear more legitimate.

The combination of urgency, trusted platform context, and direct notification significantly increases the likelihood of user interaction.

Analysis of one campaign sample revealed a multi-step redirection chain designed to filter and profile victims before delivering further payloads.

The attack flow begins with a GitHub Discussion link pointing to a Google-hosted URL (share.google domain). From there, behavior changes based on the presence of Google cookies:

• Users with active Google cookies are redirected via HTTP 301 to an attacker-controlled domain, identified as drnatashachinn[.]com.
• Users without cookies receive a fingerprinting page directly.

This selective routing suggests attackers are prioritizing real user traffic while avoiding detection by automated scanners.

The landing page contains obfuscated JavaScript that performs detailed browser fingerprinting. The script collects system and browser data including timezone, platform, user agent, and automation indicators such as navigator.webdriver.

It also uses hidden iframes to detect spoofed environments and gathers additional metadata like URL hash values for campaign tracking.

The collected data is then encoded and automatically submitted back to the server via a POST request without user interaction.

Notably, no immediate malware payload or credential harvesting occurs at this stage. Instead, the behavior aligns with a Traffic Distribution System (TDS), where victims are profiled and selectively routed to secondary attack stages such as phishing pages or exploit kits.

Evasion and Scaling Techniques

The campaign employs several evasion tactics to remain undetected:

• JavaScript obfuscation using string reconstruction and array manipulation.
• Environment checks to identify bots or analysis tools.
• Rapid, automated posting across repositories.
• Reuse of templated content with slight variations.

By leveraging GitHub’s trusted environment and repeating the same message across thousands of repositories, attackers create a sense of legitimacy and urgency.

This campaign is particularly effective because it targets developers in a platform they inherently trust. GitHub Discussions are less scrutinized than official advisories, and repeated exposure to similar messages can reinforce credibility.

Combined with urgency-driven language and direct notifications, even experienced users may be tempted to act quickly without verifying the source.

Security experts strongly advise developers to avoid downloading software from unofficial links and to verify all security alerts through trusted vendor channels.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.