FakeGit Campaign Weaponizes 7,600 GitHub Repositories to Deliver AI-Assisted Malware

FakeGit Used 7,600 GitHub Repositories and AI Registries to Deliver SmartLoader Malware 

A supply chain attack doesn't need to wait for a developer to stumble onto a poisoned package anymore. Here's how a campaign called FakeGit turned thousands of fake GitHub repos into a distribution engine for malware, and why AI agents make the problem worse.

What You Need to Know

Researchers at Trend Micro and Island have uncovered FakeGit, a malware distribution campaign that built 7,600 malicious GitHub repositories and racked up more than 14 million downloads. The repos impersonated popular consumer and enterprise tools to trick people into downloading SmartLoader and StealC malware instead. The campaign is attributed to the threat actor Water Kurita and appears to be a continuation of an earlier operation built around Lumma Stealer.

What Happened

The malicious repositories mimicked well known software, including Gmail, WhatsApp, Databricks, Jenkins, and Docker, giving them a veneer of legitimacy that made them easy to trust at a glance. Each repo's README pointed visitors to a ZIP archive posed as a legitimate installer. Instead, it delivered SmartLoader. Once active on a system, SmartLoader retrieves its command and control address and pulls down additional encrypted stages from GitHub, letting the attackers extend the infection after the initial download.

The New Angle: AgentBaiting

What sets this campaign apart from a standard repository poisoning attack is the delivery method, now being called AgentBaiting. Traditional supply chain attacks plant a malicious package somewhere and wait for a developer to find it. AgentBaiting skips that waiting period. The malicious repositories are placed directly into AI registries and MCP catalogs, the exact places AI agents actively search when looking for tools or integrations. Anyone using AI for research or development is more likely to run into one of these traps, since the agent is doing the searching and pulling on the user's behalf.

Why This Matters

The shift from waiting to baiting changes the math for defenders. A developer manually vetting a GitHub repo has a chance to notice red flags before installing anything. An agent pulling from a public registry to satisfy a task doesn't necessarily apply that same scrutiny, and the scale of this campaign shows how effective that gap can be. As more teams lean on AI agents to find and install tools, the exposure created by unverified public registries grows right along with it.

What to Do

Organizations should maintain approved, internally vetted catalogs of skills and MCP servers rather than letting agents or developers pull freely from public registries. New capabilities, whether found by a person or an agent, should be tested in an isolated environment before touching production systems. Any repository distributing a common developer tool or AI integration should be verified against the publisher's official channels before it's installed anywhere.

Apple Fixes Hide My Email Vulnerability

Apple has fixed a vulnerability in iCloud+ Hide My Email that undercut the very thing the feature promises: keeping your real address hidden behind a disposable alias.

What You Need to Know

Hide My Email generates disposable alias addresses that forward to a user's real inbox, but a flaw in the feature allowed those aliases to be linked back to the underlying Apple account. The vulnerability was first reported to Apple in June 2025 and stayed exploitable for more than a year before a patch landed on July 3, 2026. Researchers say it was reproducible with limited effort, which is what made it especially concerning for a feature built into everyday sign-ups, newsletters, and account registrations.

What Happened

Hide My Email exists to let people sign up for things without handing over their real address, generating a relay alias that forwards mail to the user's actual inbox. The flaw undermined that separation by making it possible to trace an alias back to the Apple account behind it. Researchers described the bug as turning a privacy feature into a reverse lookup tool, since it let someone connect a masked address to a real identity with little effort. Apple's July 3, 2026 patch closes the specific hole that made this possible.

Why This Matters

A relay address is supposed to be a dead end for anyone trying to trace it back to you. When that link can be reversed, a leaked alias stops being just a spam magnet and becomes a path to the person behind it, opening the door to targeted phishing, spam, and broader data harvesting. This is especially relevant for anyone who treated Hide My Email as a strong privacy boundary for sensitive accounts, since the alias alone was doing less protective work than intended for over a year.

What to Do

Apple's patch resolves the underlying flaw, so keeping devices and iCloud services up to date closes the specific exposure. Beyond that, anyone who used Hide My Email for sensitive accounts should review where those aliases were shared and consider whether any need to be rotated or retired. Aliases work best as one layer of a broader privacy habit, not a standalone shield, so pair them with cautious account practices like unique passwords and awareness of where an address gets shared.

Privacy features like Hide My Email can genuinely cut down on spam and tracking, but they only work as well as the service behind them, and this flaw is a reminder to keep that trust in check.

ASUS Critical Router Flaw

ASUS has released a fix for a critical vulnerability that let remote attackers bypass authentication on several popular router models, no user interaction required.

What You Need to Know

ASUS has patched a critical flaw that allowed remote attackers to bypass authentication and gain unauthorized access to affected routers without any action from the user. The affected lineup includes several widely deployed models, including the RT-AC68U, RT-AC86U, RT-AX57, RT-AX58U, RT-AX88U, and ZenWiFi XT8 variants, putting a large number of home and small-office networks at risk. ASUS addressed a second issue in the same advisory, and security groups are urging users to update firmware immediately.

What's Vulnerable

The core issue is an authentication bypass rated critical, meaning an attacker could gain access to an exposed router without needing credentials or any interaction from the person using it. That makes the flaw especially dangerous for home and small-office setups, where routers are often left with remote administration enabled and firmware updates applied inconsequently. A compromised router does not stop at a login bypass. Once inside, an attacker can intercept traffic, alter router settings, steal credentials passing through the network, and establish persistence that spans every device connected to it, including the kind of foothold used to build larger botnets.

Why This Matters

A router sits at the center of every home or office network, so a compromise there does not just affect one device, it affects everything connected to it. This risk is compounded for older, end-of-life models, which may not receive future firmware support at all. For those users, patching is not an option going forward, leaving hardware replacement as the more realistic long-term fix.

What to Do

Update firmware on any affected model as soon as possible. If an immediate update is not possible, limit remote administration, change any default credentials still in use, and keep the router's management interface off the public internet where feasible. For end-of-life models that will not receive further updates, start planning for replacement rather than relying on workarounds indefinitely.

Hackers Clone Microsoft Login Portals

A new phishing wave is using Microsoft's real login infrastructure as a launchpad for fake sign-in pages, making the scam far harder to spot than a typical spoofed login screen.

What You Need to Know

Attackers are cloning the Microsoft login experience or routing victims through legitimate Microsoft-owned domains before redirecting them to a malicious page, borrowing trust from real infrastructure to make the phishing chain feel credible. The tactic works because the first step often looks completely normal, even when the address is genuinely Microsoft-related, and it lets attackers capture passwords, tokens, and approval codes rather than just login credentials.

What Happened

Researchers have observed attackers using Microsoft's own login and OAuth flows to redirect victims into phishing pages, capturing whatever the victim submits once they follow through. The chain often starts with something familiar: a Microsoft login screen, a CAPTCHA, or a prompt to continue authentication. From there, the flow quietly shifts to a lookalike page collecting account details and session access. What makes this approach dangerous is the combination of real branding, legitimate-looking redirects, and social engineering working together in a single chain, rather than relying on any one weak link.

Why This Matters

A phishing page that looks fake is easy to catch. A phishing chain that starts on Microsoft's actual domain is not, and that's precisely what makes this tactic effective. Beyond passwords, attackers walking away with tokens or approval codes means an account can stay exposed even after a victim realizes something went wrong and changes their password, since a stolen token or approval code can outlive the original login attempt.

What to Do

Treat any unexpected Microsoft sign-in prompt as suspicious, particularly if it arrives through email, chat, or a search ad rather than something the user initiated. Strong MFA methods, especially FIDO security keys or Windows Hello, meaningfully reduce the risk of token theft compared to weaker MFA options. Organizations should also watch for unusual redirect behavior, block known malicious login domains, and look for signs that users are being redirected away from Microsoft's genuine authentication pages before credentials are entered.

Trust in a familiar login screen is exactly what this attack is built to exploit, which makes a second look at unexpected sign-in prompts worth the extra few seconds.

Adobe Acrobat Chrome Extension Exposed WhatsApp Chats

A chain of three vulnerabilities in the Adobe Acrobat Chrome extension let any website read a victim's WhatsApp Web conversations, no malware or authentication required.

What You Need to Know

Guardio Labs researchers discovered HermeticReader, a chain of three vulnerabilities tracked as CVE-2026-48294, affecting Adobe Acrobat's Chrome extension in versions up to and including 25.5.2.1. The flaw allowed any website to silently read a victim's WhatsApp Web conversations, contact names, chat list, profile name, and message content without authentication. Because the extension is installed on roughly 329 million browsers, the exposure was immediate and massive in scale, putting a significant share of the world's population at risk of having private conversations read without their knowledge.

What Happened

The attack chain exploits how the Adobe extension handles internal messaging. The extension includes an internal HTML resource that any page can load as an iframe, and from there, an attacker-controlled website can write directly into the extension's own storage without authentication. That write access is enough to activate Hermes, Adobe's integration engine responsible for interactions between Acrobat and WhatsApp Web. Once Hermes is active, the attacker can direct commands straight to the victim's WhatsApp Web tab by supplying a predictable Tab ID. No malicious software is involved anywhere in the chain. Simply visiting a webpage while the vulnerable extension was installed was enough to expose the full contents of an active WhatsApp Web session.

Why This Matters

The scale here comes from two things stacking on top of each other: an extension installed on hundreds of millions of browsers, and an attack that needs nothing more than a visit to an ordinary looking webpage. There's no phishing link to click, no attachment to open, and no separate malware to detect. That combination means the exposure was already sitting on a huge number of machines the moment the flaw became exploitable, and anyone with the extension installed and WhatsApp Web open was at risk without doing anything unusual.

What to Do

Adobe has patched the vulnerability in version 26.5.2.3 and pushed it out automatically to users. Verify that the Adobe Acrobat Chrome extension on any managed or personal browser has updated to version 26.5.2.3 or later, since automatic delivery does not guarantee every installation has picked it up yet. Given how widely this extension is deployed, it's worth treating this as a fleet-wide check rather than assuming updates landed everywhere on their own.

A vulnerability this quiet, requiring nothing more than a visit to a webpage, is a reminder that browser extensions deserve the same scrutiny as any other software with access to sensitive sessions. If your organization needs to verify extension versions across a large browser fleet, Hunter Strategy can help you build that visibility before the next silent vulnerability like this one surfaces.