You are sitting at your desk, it is late on a Tuesday, and your IDE is finally behaving itself. The syntax highlighting is perfect, your tests are passing, and you are just about to commit for the night. Then, a notification pings. It is from GitHub. Subject line: Visual Studio Code, Severe Threat, Emergency Action Alert. It looks official, it comes from the legitimate GitHub notification address, and it says your entire system is at risk because of some critical vulnerability you have never heard of. It mentions you by name, or at least by your handle. What do you do?
Most developers, especially those of us who live in our repositories and treat GitHub like our digital home, hit that link immediately. The urgency is the point. It is designed to bypass your logical filters and trigger your "fix it now" reflex. Today's prompt from Daniel is about this exact scenario, specifically a massive phishing surge we have seen throughout March twenty twenty-six that is weaponizing the very trust we place in platform infrastructure. I am Herman Poppleberry, and honestly, the sophistication of this "Living off Trusted Services" trend—or L O T S—is genuinely alarming because it turns our own tools against us.
It is the ultimate "who do you trust" moment. Daniel sent over details about a repository called "stellarwatchmanshow" and this "UrgentRelease" notification. It is clever because it is not just a random email from a suspicious domain like "security-fix-dot-net." It is a notification triggered by the platform itself. Herman, you have been digging into the "stellarwatchmanshow" incident. How are they actually pulling this off without getting flagged by enterprise-grade spam filters that usually catch this stuff in seconds?
The genius, or the villainy of it, lies in how they exploit the notification engine. They create a repository or a discussion—in this case, it was a discussion titled "Visual Code Update zero four thirty zero seven"—and then they mass mention thousands of users. When you are mentioned on GitHub, the platform generates an email from its own servers. So, when your inbox sees an email from "notifications at github dot com," it clears every security hurdle because GitHub is a trusted sender. The attackers are not spoofing the email; they are using GitHub as their personal delivery service for phishing lures. It is a structural exploit of how we communicate in open source.
It is basically like the attacker is riding in the back of a police car to get past the gate. The security guard sees the car, recognizes the siren, and just waves them through without checking who is in the backseat. And once they are in, they hit you with this "Alexander Montgomery" persona from the "Neural Dynamics Lab." I have to say, if I am going to be scammed, I at least appreciate a little bit of production value. "Neural Dynamics Lab" sounds like the kind of place that has very expensive espresso machines, whiteboards covered in Greek letters, and very questionable ethics.
That veneer of academic authority is a huge part of why this works. They are not just saying "click here for a prize." They are citing a specific, albeit fabricated, identifier: C V E twenty twenty-six, ten eight four seven, twenty-nine three eight four. To a developer, a C V E is a call to action. It is a signal that the world is on fire and you need a bucket of water. We have been trained to react to those strings of numbers like a bell. By claiming this affects Visual Studio Code versions prior to one dot one hundred and twelve dot five on Windows, they provide just enough technical detail to sound legitimate. They are counting on the fact that you are busy, you are tired, and you want to be a responsible maintainer.
But that C V E is a total ghost, right? It does not exist in any actual database. I checked the Mitre site and the National Vulnerability Database while we were prepping, and it is just... nothing.
It is completely fake. But who pauses to check the N V D when an "Emergency Action Alert" says their network is about to be taken over? The lure claims there is a high-risk security bug that allows for unauthorized access and malware execution. They even throw in phrases like "network takeover" to spike your cortisol levels. And then, they provide the "fix" through a "share dot google" URL. This is where the L O T S strategy really shines.
Right, because if you block GitHub, your developers cannot work. If you block Google, your business grinds to a halt. So the attacker hosts the malicious "update" on a Google domain, knowing that your firewall is going to look the other way. It is a double-tap of trust abuse. You trust the sender, GitHub, and you trust the host, Google.
This is part of a much broader surge we have been tracking all month. On March ninth, security firms Fortra and Trend Micro reported a twin campaign where attackers were using GitHub commit comments to send "vishing" lures. They were impersonating brands like PayPal and Norton. It was the first time we saw GitHub's notification system being used for large-scale voice phishing. They would mention you in a comment, you would get the email, and inside was a "security report" with a phone number to call. Imagine that—a GitHub notification leading to a phone scam.
Calling a "support" number because a random GitHub comment told me to sounds like something I would only do if I had been awake for forty-eight hours straight and had run out of coffee. But I suppose if you are a junior dev and you see a "Severe Threat" alert, you might panic. The psychological pressure is real.
Panic is the primary vector. Look at what happened on March sixteenth. A campaign compromised nearly twelve thousand GitHub repositories using fake "Security Alert" issues. These ones claimed there was unauthorized access to your account from Reykjavik, Iceland. It directed users to authorize a malicious O-Auth app named "gitsecurityapp." If you clicked "authorize," you were giving the attackers full account control. Twelve thousand repos in one week, Corn. That is an industrial scale of compromise.
Twelve thousand? That is not just a hobbyist in a basement. That is a coordinated strike. And the "gitsecurityapp" name is so boringly plausible. It sounds like something your I T department would force you to install on a Monday morning. It is interesting that they chose Reykjavik. It feels just exotic enough to be suspicious but not so wild that it feels like a joke. It creates that "wait, I have never been to Iceland" moment that makes you click.
The goal of these attacks is rarely just to mess with one person. They are looking for "Secret Zero." We talked about this back in episode fourteen seventy-four. They want the A P I keys, the credentials, and the O-Auth tokens that are buried in your environment. If they get control of your GitHub account through a fake security app, they can inject malicious code into your production branch, or they can scrape your private repos for hardcoded secrets. GitHub reported that over thirty-nine million secrets were leaked on the platform in twenty twenty-four alone. That is thirty-nine million keys to the castle just sitting there.
It is the ultimate supply chain poison. You think you are fixing a vulnerability in Visual Studio Code, but you are actually handing over the keys to the castle. And once they have those keys, they are not just in your GitHub; they are in your A W S, your Azure, your customer database. It is a cascading failure starting from a single "at-mention." It is terrifying how small the initial crack in the armor is.
What I find fascinating is the technical mechanism of the "stellarwatchmanshow" campaign. They are using GitHub Discussions to mass-mention users. It is a lower-friction way to trigger notifications than creating thousands of pull requests or issues, which might get flagged faster. And because GitHub is trying to be a social platform for developers, they have made it very easy to "at-mention" anyone. But that feature is now being turned into a weapon. The platform's greatest strength—its connectivity—is being used as its primary attack vector.
It is the "social" part of social coding that is the vulnerability. We want to be reachable, we want to collaborate, but that reachability is exactly what the attackers are exploiting. I noticed that Daniel himself was targeted in one of these loops. When you are a researcher or a developer with a public profile, your "at-handle" is basically a public-facing doorbell that any scammer can ring. And they are ringing it with a sledgehammer.
And it is not just about credential harvesting anymore. On March twentieth, the OpenClaw project was targeted with a mass-mention attack that promised a five thousand dollar token reward. It led to a cloned site designed to drain crypto wallets. So the lures are diversifying. They are hitting you with "fear" through the fake C V E alerts, and they are hitting you with "greed" through the fake token airdrops. They are covering the entire spectrum of human emotion to find a way in.
It is the classic carrot and stick, but both the carrot and the stick are made of malware. Herman, how does a developer actually spot this? Because if the email is from "notifications at github dot com," the "check the sender" advice we have been giving for twenty years is officially dead. We need a new playbook.
You have to move the "Zero Trust" boundary further up the chain. You cannot trust the sender domain anymore. You have to verify the content. First, look at the C V E. If someone claims a C V E is "severe" but you cannot find it on the official Mitre or National Vulnerability Database websites, it is a scam. Attackers love using high-digit, realistic-looking numbers like the one in this prompt because they know most people won't look them up. They are betting on your laziness.
Also, "Alexander Montgomery" from "Neural Dynamics Lab" sounds like a name generated by an A I that was told to create a "trustworthy scientist." If the person reporting the bug does not have a history in the security community or a verifiable profile, that is a massive red flag. Real security researchers usually have a P G P key, a history of disclosures, or at least a digital footprint that isn't two days old. If the "lab" only exists in a GitHub discussion, it probably isn't a lab.
Another big one is the "update" mechanism. Microsoft is never going to ask you to download a Visual Studio Code update from a "share dot google" link. They have their own update servers, they have signed binaries, and the I D E itself handles updates. If any tool asks you to go to a third-party file-sharing site to "patch" a security hole, it is a trap. It does not matter how official the email looks.
It is like a doctor telling you that you need emergency surgery, but then asking you to meet him in the parking lot of a Taco Bell to perform it. If the venue doesn't match the urgency, something is wrong. But what about GitHub's responsibility here? They are the ones sending the emails. They are the platform being abused. Can they actually stop this without breaking the "at-mention" feature for everyone else?
It is a difficult balancing act. GitHub is under immense pressure to secure the platform, but they also don't want to kill the community aspect. One solution being discussed is aggressive rate-limiting on "at-mentions" for new accounts or new repositories. If a repository called "stellarwatchmanshow" suddenly mentions ten thousand people in an hour, that should trigger an automatic block. It is a simple heuristic: is this account five minutes old and currently screaming at the entire internet?
You would think that would be a fairly simple thing to implement. If the account age is less than the number of mentions per second, maybe hit the pause button.
They are also looking at A I-driven scanning for notification content. If a non-official account is sending out text that includes "Emergency Action Alert" or "Severe Threat," the system could flag that for manual review before the emails go out. But the attackers are clever. They will just start using synonyms or obfuscating the text to get around the filters. It is the same old arms race, just on a more trusted battlefield.
This reminds me of our conversation in episode fourteen sixty-four about Claude Code and agentic workflows. As we move more toward agents—A I systems that can actually write and deploy code—this becomes even more dangerous. If you have an A I agent managing your repo and it receives one of these "security alerts," is it smart enough to realize the C V E is fake? Or is it going to "helpfully" download the malicious patch and execute it because its instructions tell it to prioritize security?
That is a terrifying thought. As we outsource more of our developer operations to autonomous agents, the "human in the loop" who might notice that "Alexander Montgomery" sounds fake is being removed. The attack surface is widening because the agents are designed to be responsive and efficient. If an agent sees an "Urgent Release" notification, its goal is to deploy that release as fast as possible to minimize the window of vulnerability. The attacker is essentially phishing the A I.
We are basically building a faster way for the police car to get through the gate, without checking if there is actually a cop inside. It makes the "Secret Zero" problem even more acute. If an agent has access to your O-Auth tokens and it gets tricked, the compromise happens at machine speed. By the time you wake up and check your email, your entire infrastructure could be drained.
Which is why we have to talk about hardware security keys. If you are using a Fido-two compliant hardware key like a YubiKey, even if you are tricked into giving away your password or authorizing a malicious app, the attacker cannot get into your account without that physical device. It is one of the few absolute defenses we have against credential theft and session hijacking. It moves the security from something you "know" or "see" to something you physically "have."
It is the only thing that actually works when the "human protocol" fails. We can't expect every developer to be a forensic linguist who can spot a fake "Neural Dynamics Lab" persona, but we can expect them to tap a gold disk on their desk. It is a physical check in a digital world.
We also need to be much more disciplined about O-Auth auditing. Every time you click "Authorize" on a GitHub app, you should be asking why it needs the permissions it is requesting. If a "security app" wants "full account control," that is a non-starter. Real security tools should only need read access to specific metadata or webhooks. If it asks for the keys to the kingdom, it is probably going to rob the treasury.
It is the principle of least privilege. But again, in the heat of a "Severe Threat" alert, people forget the basics. They just want the red flashing light to go away. I think the most important takeaway from this "stellarwatchmanshow" mess is that the platform is now the perimeter. We used to worry about our own servers, then we worried about our cloud providers, and now we have to worry about the social fabric of our development tools.
The trust gap is where the profit lives for these attackers. They are betting that your relationship with GitHub is stronger than your skepticism of a random notification. And as of March twenty twenty-six, they are winning that bet quite often. Twelve thousand repositories in a week is proof of concept. This is not a "weird prompt" anymore; it is a standard operating procedure for modern phishing. It is industrial, it is automated, and it is highly effective.
It is a grim reality, but at least we can laugh at the name "Alexander Montgomery" while we rotate our A P I keys. It is a small comfort, but I will take it. Before we wrap up, I want to say thanks to our producer, Hilbert Flumingtop, for keeping the show running while we dive into these rabbit holes.
And a big thanks to Modal for providing the G P U credits that power the generation of this show. Their serverless infrastructure is actually a great example of how to build secure, isolated environments for running code—something "Alexander Montgomery" would probably hate because he couldn't break out of the sandbox.
This has been My Weird Prompts. If you are finding these deep dives useful, leave us a review on your favorite podcast app. It really does help other developers find the show and avoid these kinds of traps. We want to build a community that is too smart to be phished.
You can find our full archive and subscribe to the feed at myweirdprompts dot com. Stay vigilant, verify your C V E numbers, and for the love of all that is holy, do not download patches from Google Drive. If it feels urgent, that is the first reason to slow down.
Catch you in the next one.
See you then.
