Here’s a sentence that sounds like it has nothing to do with your business: North Korean hackers have planted more than 100 malicious packages across major open-source software platforms. Here’s why it actually does — almost every piece of software your business relies on, from your website to your accounting tools to your customer portal, was built using smaller, reusable pieces of code borrowed from public repositories that developers trust by default. That trust is exactly what this campaign, known as PolinRider, is designed to exploit.
What Happened
Security researchers identified an ongoing campaign, active since late 2025 and still expanding as of this writing, in which threat actors linked to North Korea compromised legitimate developer accounts and used them to publish tainted versions of trusted software packages. The affected ecosystems include npm (used heavily in web development), Packagist (PHP), Go modules, and even Chrome browser extensions. Researchers have tracked over 100 unique malicious packages tied to this single campaign, with new ones continuing to surface.
How This Kind of Attack Actually Works
You don’t need to understand code to understand the mechanics. Modern software is rarely built entirely from scratch — developers commonly pull in pre-built components maintained by other people, the way you might use a trusted supplier’s part instead of manufacturing everything in-house. Attackers in this campaign compromised the accounts of real, established maintainers and quietly slipped malicious code into otherwise legitimate updates. When a developer or an automated build system pulls in that update — which happens constantly and often without a human double-checking every line — the hidden code activates, aiming to steal credentials, source code, and other sensitive information.
Why This Matters Even If You Don’t Write Code
Most small and mid-sized business owners aren’t writing software themselves — but your website developer, your SaaS vendors, your custom application partner, and any in-house technical staff almost certainly are relying on these same public repositories every day. If one of their tools or dependencies was quietly compromised, the attack doesn’t stay contained to that developer. It can move downstream into anything they built or maintain for you, which means the actual exposure to your business runs through your vendors, not just your own systems.
This is the same reason vendor and third-party risk keeps coming up as a priority for regulated and non-regulated businesses alike — your security posture is only as strong as the weakest link in everything you depend on. Our earlier piece on software supply chain attacks covers the broader pattern this campaign fits into.
What SMBs Can Reasonably Do About It
You’re not expected to audit your vendors’ source code. What is reasonable is asking direct questions and having someone on your side who knows what to ask for: Does your web developer or software vendor have a process for vetting and updating third-party components. Do they know which dependencies their tools rely on, and do they get notified when a known vulnerability or compromise is disclosed. Is there a documented risk assessment covering your key vendors and technology partners, reviewed on a regular schedule rather than once and forgotten.
This kind of ongoing vendor oversight is core to what a vCISO manages — not because every business needs to become a software security expert, but because someone needs to be asking these questions on your behalf, consistently, before a compromise reaches you through a vendor you trusted.
Frequently Asked Questions
What is the PolinRider supply chain attack? PolinRider is an ongoing campaign, linked to North Korean threat actors, in which attackers compromised legitimate developer accounts to publish malicious versions of software packages across platforms including npm, Packagist, Go modules, and Chrome extensions.
Does this affect my business if we don’t write code? Yes, indirectly. If any vendor, developer, or SaaS provider you rely on uses affected open-source components, a compromise in their supply chain can reach your business even though you never interact with the code directly.
How do I know if my vendors are secure? Ask your vendors directly whether they have a documented process for monitoring and updating third-party software dependencies, and consider a formal third-party risk assessment to evaluate your key partners on a recurring basis.
Is this attack still happening? Yes. As of this writing, researchers report the campaign remains active, with new malicious packages continuing to appear as attackers compromise additional maintainer accounts.
If you’re not sure how exposed your business is through your vendor relationships, a third-party risk assessment is a good, low-friction place to start.