A new type of VSCode phishing attack is targeting freelancers via Upwork. Here’s how it works and how to protect yourself.
Hi, I'm Peter and I ...
For further actions, you may consider blocking this person and/or reporting abuse
This is a real eye-opener. I usually think about security in my code, but I don't always think about the security of the editor itself. It is a great reminder to be more careful about which extensions I install on my Windows machine. Thanks for sharing these risks!
I am a web hoster for some 15 years. The internet is an attack vector by definition. It's a real Mobland. 😂 🍭
Never was there a truer word said.
I see that my code works mostly by "client blocked, limited, incorrect password" in my logs... Neverending Story 😂
This is a fantastic breakdown. The social engineering layer is what makes it so effective - the Upwork dynamics create the perfect pressure cooker where developers skip their usual caution.
I'd add another dimension: AI coding agents make this worse. Tools like Cursor, Windsurf, and Claude Code read project-level config files (
.cursorrules,CLAUDE.md, etc.) that can influence what code gets generated. A malicious repo could include instructions that subtly introduce vulnerabilities through the AI's suggestions - and the developer would trust the output because "the AI wrote it."The attack surface is expanding in directions most devs aren't thinking about:
.vscode/tasks.json(as you showed).husky/and git hookspostinstallscripts in package.jsonFor freelancers specifically, I'd recommend: always open client repos in a disposable VM or container first. The 5 minutes it takes to spin up a dev container is nothing compared to losing your crypto wallet or SSH keys. Great article, Peter.
The
runsOn: "folderOpen"behavior overridingtask.allowAutomaticTasksafter clicking "Trust" is a genuinely bad design decision. That trust dialog trains you to click yes — it shows up constantly and blocking it means you can't work. So it becomes muscle memory, which is exactly what this attack exploits.fwiw I've started grepping
.vscode/in any repo I clone before opening it. Takes two seconds and would catch this immediately.I don't usually like to throw shade at decisions I don't know the constraints of, but yeah, this seems pretty unforgiveable.
Grepping for what string exactly? I'm not sure I understand your process.
Thanks for the eye-opening post—this hits home as a fellow freelancer juggling Upwork and Jobbers gigs daily. I'm grateful you highlighted IDE vulnerabilities; it's already got me double-checking extensions and sandboxing my setup to protect client trust. Your practical tips are a game-changer for staying secure without slowing down the hustle!
Thanks for your reply. I am very happy I managed to reach another Upworker!
Have you spotted the jobs I am talking about?
One other commonality they all seem to share is the jobs are usually posted from the Philippines or Ukraine. I didn't add it to the article because it's not a trait of the attack and could be misread. I only mention it here because you're on the frontlines.
Thanks Peter—spot on about vigilance with postings from those regions; scams thrive there. If I spot any suspicious jobs like that on Upwork/Jobbers, I'll report them immediately to keep the platform clean. Everyone who's seen this thread, please do the same—let's all protect freelancers from misuse and info theft!
That's why I have a firewall. Everything that starts with microsoft is banned. Better use Notepad++ or a reliable firewall
It would have been a HTTPS request originating with you and hitting a Vercel endpoint. Not much a Firewall would have done for you.
And Notepad++ was supply chain attacked 2 weeks ago. You should probably update your install.
Notepad++ Attack
Ah, okay, looks like I'm switching to the standard Microsoft Windows Notepad. Although... No, let them attack me, there's no point in stealing my code anyway. Oh, I remembered, by the way, I don't have an antivirus.
I still have a mini panic every now and then about not having a whole suite of AV software. It's just old hang-ups though. The truth is... Windows Defender got good. Like really good. Adding 3rd party AV is adding another attack surface.
Remember the days when 2 of your AV tools would decide they had beef with each other?
I use antivirus software once a year, so I never really think about it. Its absence hasn't made any noticeable difference yet (at least I do think so...)
This is exactly why I built VibeCheck. When you're vibe coding with AI assistants, you often just accept whatever code gets generated, and now with AI doing file operations and creating configs, tasks.json becomes a huge blind spot. Most devs never even look at .vscode/ unless something breaks. The Upwork targeting is smart too, freelancers are under time pressure so they skip security checks. Curious if you've seen this extend beyond tasks.json? Like are settings.json or launch.json being exploited similarly?
Not that I’ve seen in the wild.
In theory, settings.json or launch.json could be used to set the stage for an attack, but neither of them can silently execute code or pull in dependencies on their own. They’re declarative configs, not execution surfaces.
launch.json only runs anything if the user explicitly starts a debug session, and even then it’s just doing what it says on the tin. If malware is already present and intercepting that flow, you’re already compromised, so the file itself isn’t the meaningful attack vector.
Messing with these files would mostly just be a red flag with very little payoff compared to things like tasks, extensions, or social-engineering workspace trust.
Fair point about launch.json needing explicit debug session. I think the real danger isn't those declarative configs anyway, it's the combo of workspace trust + extensions like you said. When you're moving fast with AI generating code, you kinda get in the habit of just accepting workspace recommendations and trusting whatever pops up. That's where I've caught myself being sloppy tbh, not even reading what permissions I'm granting. The social engineering angle is probably way more effective than trying to get creative with config files.
Exactly this. Humans are the weakest point in any system cos they get tired, they make mistakes, they don't know what they don't know.
More generally, I don't AI has changed our field at all. You review PRs the same whether it was generated by AI or a random coworker. You hold the mental model of "distrust by default". I kinda feel like it is similar to lumberjacks getting chainsaws. The safety protocols didn't change. The scope of the damage did if you don't follow them did.
The chainsaw analogy is perfect actually. The tool got way more powerful but the safety fundamentals are the same - you still need to know what you're cutting. I think the one thing that did change though is the volume. Like a junior dev with AI can generate 10x more code than before, which means 10x more surface area to review. The "distrust by default" mindset is right but now you need it at a scale most teams aren't used to.
I don't disagree at all. A junior with a chainsaw is a scary thing. I think at the end of the day it is gonna come down to blast radius management. If your junior PRs a bug fix that hits 32 files, close the PR. Don't even waste your time reading it.
Essentially, complete removal of "the boy scout method".
blast radius management is such a good framing for this. the 32-file PR thing is real - I have seen AI agents do exactly that, you ask it to fix one test and it refactors half the codebase "while it was in there."
the boy scout method dying is interesting though. like in theory leaving code better than you found it is great, but when your junior is an AI that "improves" things based on vibes rather than understanding the system... yeah close that PR.
I wonder if the answer is just smaller blast radius by default - like sandboxing AI changes to only the files explicitly mentioned in the ticket. we have been experimenting with that approach and it catches a lot of the scope creep before review even starts
Hope for the best, prepare for the worst! 😅
😄 basically the entire philosophy in one sentence. at least sandboxing the AI changes gives the "prepare" part some actual teeth
Good to know about this attack vector. My instict are saved me, because on project which I work I add .vscode/ to .gitignore.
In other way my editor preference is vim, zed, nvim, VScode.
But for my focus on minimalism I am writing a cli based editor in rust, even a lot fever funcionality than vim
I haven't checked if vim et al have lifecycle hooks that can be exploited, but I know what rabbit-hole I'm going down for the day!
Unfortunately, this won't save you from this particular attack because the creator of the repo didn't add it to the
.gitignoreso when you clone it is already in the project.In general I agree though; saving the
.vscodefolder to the repo is something that only makes sense on a team repo, and even then I would prefer to just enforce anything I need to enforce in the CI pipeline. I don't care what is happening on the dev's local machine.I really rare clone repo from github for example, that why do not open in VSCode
Maybe I missing where this attack happen not under local development, when you open a repo with .vscode/task.json ?
Oh okay. I misunderstood what you were saying. If you don't use VSCode, you are immune to this specific attack.
I think that "tooling as an attack vector" is the wider danger though. As @nedcodes pointed out, git hooks and husky also introduce this type of repository-level attack. They're not auto-initiated, but the risks are similar.
Solid writeup. The folderOpen task execution is genuinely scary - most devs I know have never even looked at .vscode/tasks.json in repos they clone.
This extends to AI coding tools too. A malicious .cursorrules or CLAUDE.md in a repo could influence the AI to generate vulnerable code, disable security checks, or exfiltrate context through crafted suggestions. The trust boundary keeps expanding and most people aren't thinking about it.
100%. Everything works on a "local is trusted" model that is no longer true and our machines hold valuable credentials in a way they just didn't a few years ago.
Your point about AI is very powerful. If you let an agent run wild, it's very hard to be sure nothing on the environment level was changed. Git doesn't track that.
Exactly. And git hooks are another blind spot - most people run whatever is in .husky/ or .git/hooks/ without a second thought. The whole local dev environment is basically an honor system at this point.
Lucky all the big players are trying to move local to the cloud. 💀
what a nasty attack that is.
Yeah, I think it's scary because we are the targets. It's a dev hunting game for them.
Let the dev hunting games begin! .. just joking 😆
🤓🎯🔫
😆
Great article! Supply chain attacks on IDE extensions are underrated, most devs trust their editor implicitly.
I've been working on an open source scanner for npm/PyPI malware detection.
It's a personal project, not comparable to enterprise tools, but if anyone wants to test it:
github.com/DNSZLSK/muad-dib
Would be curious to hear if you've seen malicious VS Code extensions in the wild beyond the examples you mentioned.
Oh that looks awesome. I was very amused when i opened the repo and it has
.vscodefolder and husky pre-commits! 😅Have you considered integrating with the VirusTotal api to check hashes against? That way you could leverage an always-up-to-date definitions database and not have to invent new discovery techniques yourself.
Ouuuuupss on the .vscode folder, I’ll clean that up. Thanks for the VirusTotal sugg : I’ve been thinking about external APIs but I’m hesitant to add runtime dependencies on third-party services for security reasons. Idk i’m student. Maybe an opt-in flag with user’s own API key could work. Appreciate the feedback!
Understandable, especially with a supply chain attack analyzer, but it's the central virus database for Google Security Operations. If your dependency on Google is supply chain attacked, you got bigger problems! 😅
I'll look into it as an opt-in feature. Thanks!
Very good article, very clear, thanks for sharing and saving the developers from this attack. VS Code should take note of this to prevent these types of attacks.
I think they're in a bit of a "damned if you do, damned if you don't" situation. The underlying tech is good, but it relies on assumptions that no longer hold.
But I mean... A simple setting to toggle between "my settings are the source of truth / my actions are the source of truth". It would be annoying, but I would prefer to be in the scenario where I'm trying to figure out why my script isn't running after I clicked "trust", than one where I'm trying to figure out why someone's script ran after I set it not to in my settings.
The Upwork social engineering angle is what makes this devastating. Freelancers are already in "prove yourself" mode — high stakes, short timelines, competing against other devs. Nobody's going to say "hold on, let me spin up a VM before I look at your take-home."
One thing worth adding: this pattern isn't limited to VSCode. Any tool that executes project-level config on open is vulnerable. Makefiles, docker-compose with host mounts, even .envrc files with direnv. The attack surface is basically "anything the ecosystem trains developers to run without thinking."
The real fix isn't technical — it's cultural. We need to normalize treating every cloned repo like an untrusted email attachment. Dev containers help, but the friction has to be near-zero or people won't use them under deadline pressure.
Very true.