As reported by BleepingComputer, the FakeGit malware campaign has resurged with 17,610 malicious GitHub repositories distributing SmartLoader malware, ultimately delivering the StealC infostealer. The scale and adaptability of this operation expose systemic weaknesses in how the cybersecurity community approaches software supply-chain trust.

Threat Alert: As reported by BleepingComputer, the FakeGit malware campaign has resurged with 17,610 malicious GitHub repositories distributing SmartLoader malware, ultimately delivering the StealC infostealer.

The Hydra Problem: Why Takedowns Are Failing

Apiiro's research reveals a sobering reality: traditional blocklist-based remediation is structurally inadequate against this type of operation. With 71% of the malicious fleet absent from URLhaus and payload copies scattered across forks, release assets, issue attachments, and backup repositories, killing one link simply prompts the operator to redirect to a spare. This is not a whack-a-mole problem — it is a distributed resilience problem that GitHub's current abuse-response architecture is not equipped to handle.

The most alarming detail is not the volume of repositories — it is that 700 accounts belong to legitimate developers. This suggests either credential compromise or a social engineering pipeline that has co-opted real trust capital.

AI Registries as an Attack Surface Multiplier

FakeGit's earlier wave in July demonstrated that 800 malicious repos masqueraded as AI skills or MCP (Model Context Protocol) servers, appearing in public AI registries and catalogs. This is a critical escalation vector. As organizations rush to integrate AI agents and MCP-based tooling, the verification infrastructure for these ecosystems is immature. A malicious MCP server positioned in a public catalog can intercept sensitive prompts, exfiltrate credentials, or manipulate agent behavior — and defenders are largely blind to this attack surface.

Who Is Most at Risk

AI Registries as an Attack Surface Multiplier
Development teams sourcing tools, scripts, or AI skills from GitHub without verification — especially those cloning repos for internal use
AI/ML engineers integrating MCP servers or AI skills from public registries — the trust model for these catalogs is underdeveloped
Organizations with developers whose GitHub accounts may be compromised — the 700 legitimate accounts identified suggest a broader credential theft or session hijacking campaign
Build pipelines and CI/CD environments — SmartLoader execution on a developer workstation can pivot into source code repositories and deployment systems

StealC: The Payload Behind the Curtain

The endgame payload, StealC, is a commercially available infostealer capable of exfiltrating browser credentials, cryptocurrency wallets, session cookies, and system information. In a developer context, this means source code access tokens, cloud API keys stored in local configurations, and SSH keys are all at risk. The blast radius extends far beyond the individual workstation — a single compromised developer machine can lead to full supply-chain compromise.

Shield53 Recommendations

Immediate Actions

  • Inventory and audit GitHub dependencies: Identify all repositories your organization clones, forks, or references. Verify the owner account, commit history, and contributor legitimacy. Flag any repository with a README that prominently features a "Download" button pointing to an external ZIP archive.
  • Audit MCP and AI skill integrations: Remove any AI skills or MCP servers sourced from public catalogs that cannot be traced to a verified vendor. Prefer official registries and vendor-published repositories only.
  • Hunt for SmartLoader and StealC indicators: Search endpoint telemetry for suspicious ZIP extraction activity from GitHub-derived downloads, followed by unexpected child processes (PowerShell, cmd, regsvr32). Check for browser credential database access patterns and unexpected network exfiltration to unfamiliar C2 infrastructure.
  • Revoke and rotate credentials: If any developer workstation shows signs of compromise, revoke all active GitHub sessions, rotate access tokens, and rotate any credentials that may have been stored in browser vaults or local configuration files.

Strategic Hardening

  • Implement allowlisting for external code sources: Use policy-driven controls (e.g., GitHub Enterprise managed users, SSO-enforced access) to restrict which repositories and accounts developers can interact with.
  • Deploy runtime behavioral monitoring on developer endpoints: Signature-based detection will not catch SmartLoader variants. Focus on behavioral indicators: unexpected archive execution, process tree anomalies, and credential store access.
  • Adopt software composition analysis (SCA) with provenance verification: Ensure your SCA tooling validates not just package integrity but repository origin and contributor reputation.
  • Establish a GitHub account monitoring program: Monitor for unauthorized changes to developer accounts, new SSH keys, new OAuth app authorizations, and unexpected repository creation or forking activity.

FakeGit is not a one-time event — it is a durable operational template. The combination of platform trust, distributed payload hosting, and AI ecosystem exploitation makes this a campaign class that will persist and evolve. Defenders must shift from reactive blocklist management to proactive trust verification and behavioral detection.