When I write about bad actors, I sometimes try to imagine where they are and how they work. For this article, it’s clearer than usual because there is some evidence around. You can use your imagination to fill in the gaps.
Imagine there’s a job going in Pyongyang. Long hours, of course, with probably brutal OKRs. The job is creating malicious packages, measured by how many you can publish a week, how many credentials you can steal, etc. The successful candidate will never meet a customer face to face, but they will meet you occasionally via the npm install you run, or the pip install your CoPilot runs for you.
This year the successful candidate probably had new targets. They certainly have new tools. In fact, the new tools are the same ones you’re using. Theirs just have the safety features turned off, and they are applied at industrial speed and scale.
The AI assistant that you use to build a cool new app: a backend in Java, a frontend in Node, maybe an LLM connected via some Python is not itself the target. The target is still you. The change that’s being exploited is what you build with this tool and how you do it.
Let’s explore.
Big money, lots of players, automation and dark times ahead. What’s that got to do with Vibe Coding?
Strangely, it’s not to do with the code your tools generate. It’s mostly about the dependencies your assistant selects.
Unless you do something specific, your AI will do its thing, and that often leaves you vulnerable.
Before we get to how, it’s worth looking at the factory on the other side.
I keep explaining the scale of the return that bad guys get from their actions. The numbers are huge. In 2025, the global cost of cybercrime was $10.5 trillion, up from $6 trillion in 2021.
Two worrying aspects are that no one seems to pay attention and that we continually underestimate the results. It takes a couple of years to get a good handle on the overall cost for any particular year, and it’s always more than we estimated.
Now, estimates for cybercrime vary widely anyway since it’s hard to get a tax return from bad actors, and of course no one wants to own up to attacks and the damage they cause. But the numbers do trickle out and get collected.
The trend, never mind the amount, is always up.
That money funds weapons programmes and investments that make the attacks more sophisticated. The incentive to keep the factory running is not going anywhere, which means neither is the factory.
North Korea’s factory continues to profit — $2bn in 2025. The United Nations estimates that these attacks account for around 13% of North Korea’s GDP.
The estimate is that if cybercrime were a separate country, then its annual takings would make it the third-largest country by GDP.
That’s just cybercrime. Let’s not forget the other modern bedfellow.
All the tools that the bad actors use to make money, especially denial-of-service and ransomware types, are favourite weapons of those with less financial motives.
If you can take down a company, corrupt its systems, steal (and plant new) data for money, you can do it towards military objectives too. If you can steal money to fund your attacks, all the better.
The reality is — and hear the sound of my drum — that you’re as much at risk from a cyber attack because of your economic position, intelligence or infrastructure control as for any traditional value that a cyber criminal might be after.
Unless you have cryptocurrencies.
In March, OFAC sanctioned six people and the groups they were part of over a scheme which stole an estimated $800 million in 2024 alone.
The U.S. State Department put the two-year haul, January 2024 through September 2025, at $2.8 billion across more than 40 separate crypto heists.
TRM Labs attributes 76% of all crypto hack value through April 2026 to North Korea, and more than $6 billion cumulatively since 2017.
Cyber war is here and is active all the time. No one needs a physical war to play the game. For many, it’s a continuation of historic and ongoing strategies of political influence. New players are turning up. “Cyber privateers” are emerging, blurring the line between commercial and military activities.
When I say everyone is getting involved, I sort of mean that literally. Six trillion dollars is one heck of a weapons demonstration. North Korea might be the poster child for cyberattacks, but of course there’s nothing technically unique about it.
The net is that the scale of interest in using cyberattacks to make money, steal secrets, crash economies, influence elections, etc., makes even William Gibson’s Neuromancer seem a little tame.
So, back to the other factory.
Ask your assistant for that cool new app and watch what arrives. By default, the backend will usually be Python or Node. For anything else, you usually have to ask.
The frontend will be React or Vue, because that’s what “modern web app” means in the training data. Ask for some AI, some machine learning and, likely or not, a Python script calling a model turns up. Simply because that’s where the SDKs and tutorials live.
Some of the most popular AI app builders, v0 and Lovable, for instance, are designed to give users a working, deployed URL in seconds. To achieve that speed without errors, they limit user choices.
Imagine you chose Java, Rust, or some other language. Would that have made a difference?
Not really, because as I said before, it’s not the code; it’s the dependencies.
Two things are going on here. Firstly, you’re getting code created in a programming language you might not be too familiar with. That will reduce your ability to decide if it’s ‘good’ code or not and, more importantly, it takes you into ecosystems where the rules of the game will be different.
Java developers, for instance, are used to a strong central repo and may not realise that simply downloading a dependency can cause harm. Node and Python folk know that downloading dependencies can trigger install scripts (and other things) that could be harmful.
What happens when the Vibe coder isn’t a developer, or isn’t one who understands Node or Python install processes? What happens when the coder does understand but doesn’t review the dependencies enough? What happens when a Java developer does review the Java dependencies but doesn’t understand where even Maven Central stops protecting them?
Let me just add some more fuel to the situation.
AI generates 28% more code than a human for the same task.
28% of AI dependency recommendations pointed to versions that were non-existent, deprecated, or fundamentally unsafe.
20% of dependencies chosen by AIs were hallucinations.
What Vibe coding, in fact, any AI code gen, gives you is fast development.
I’ve done my fair share of building large applications (and simple demos) with various CoPilots, LLMs, etc. Get it right, and you have fantastic productivity. Get it wrong, and it’s either procrastination-in-code (you keep tweaking the prompt, but nothing ever seems to get you closer to the end goal) or, worst case, a messy, useless set of unreadable, unmaintainable code.
The cost of this productivity is that we’re not reviewing the code anywhere near enough, and we’re certainly not reviewing the dependencies chosen. If we’re out of our ecosystem comfort zone, then doubly so. For hosted vibe-coded apps, there’s not even a point where the human-in-the-loop gets to choose dependencies.
The consequence of being outside our usual ecosystem (or outside any ecosystem) is that we’re putting applications into production with more security vulnerabilities than ever.
Bad actors know this, so the flood of malware and deliberately vulnerable packages across all ecosystems is growing at an almost exponential rate, and it’s turning towards AI code gen tools as a distinct target.
So your project’s security posture is now the posture of its weakest ecosystem and registry, and you didn’t pick which ones are in play. Your AI partner did.
And it shops at machine speed.
The pip install your CoPilot runs for you happens mid-flow, while you’re thinking about the feature. There’s no point where you read the package name, because there’s no point where you type it.
The human checkpoint supply chain attacks used to have to get past, a developer checking what they’re about to install, has been optimised away.
Even if you do some level of review (or ask the AI to do it for you), that’s not going to be the success you might think. SCA tools might be a great safety net and catch some of the bad packages, but even that’s being challenged.
Which brings us back to those safety features being turned off.
Expel published research this spring on a North Korean crew it tracks as HexagonalRodent. They run ChatGPT and Cursor operationally, day to day.
The main finding: they fed their own malicious code to US-owned AI models and asked the models to audit it for signs of malware, so their backdoors would survive a target’s AI-assisted review.
Read that again.
The attacker is using AI to check that their malware evades your AI.
More?
In July, researchers talked about a new attack dubbed PolinRider, which shipped 108 packages and extensions, including 61 Go modules, complete with rewritten Git history and anti-dated commits to make the packages look established.
Even a module’s GitHub history can be fake.
An AI-assisted attacker can run the “does this look normal to the scanner?” loop cheaply and at volume until the answer is yes.
The aim is obviously to defeat the most sophisticated detectors, and we’re seeing AI being used on both sides of that new arms race.
But honestly, the bad guys really don’t need anything close to that sophistication to work in the first place because we’re not paying attention to how the game has changed or even how the game was played before.
Attitudes to software security by anyone other than security professionals have always been complicated. An abstract understanding of the necessity, but limited focus on the actuality.
Vibe coding and the like widen that gap and bring people into the space with less security awareness than ever.
They can perhaps be excused for thinking that these tools provide security because they are not culpable.
But every professional involved in software creation is.
Two groups have the same AI capability this year. One of them is you, building faster than you ever have. The other is the successful candidate from the start, somewhere in Pyongyang, hitting their targets.
You both got more productive.
Their work only has to become a dependency of yours or any one of the applications your non-developer colleagues just vibe-coded.
There’s enough evidence and helpful suggestions out there. Time to do some reading
https://cycode.com/blog/vibe-coding-security/
https://snyk.io/articles/package-hallucinations/
https://unit42.paloaltonetworks.com/phantom-squatting-hallucinated-web-domains/
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.