Dependency Confusion: How 33 Fake npm Packages Quietly Mapped Companies' Internal Tools

On May 28 and 29, 2026, a threat actor uploaded 33 malicious packages to npm — and notably did not try to steal anything right away. According to Microsoft's Defender Security Research Team, the packages were registered under organizational scopes that mirrored real internal corporate namespaces, and their payload ran in a "reconnaissance-only" mode: collecting system information, hostnames, environment variables, and developer context, then phoning home (Microsoft Security Blog).

That restraint is the scary part. This wasn't a smash-and-grab. It was a survey — attackers quietly building a map of which companies pull which internal-sounding packages, so a future, targeted strike can hit the most valuable doors. If your product was built in the last five years, you need to understand why this matters even though "nothing was stolen."

What is a dependency confusion attack, in plain terms?

Modern software is assembled from thousands of small open-source packages. Big companies also build internal packages — private code shared across their own teams, named things like @acme-corp/auth or @acme-corp/billing. Those names are supposed to resolve to the company's private registry.

Dependency confusion is the trick of registering a package with the same name on the public npm registry, often with a higher version number. If a developer's machine or build server is misconfigured, the package manager can "get confused" and pull the attacker's public package instead of the company's real private one — because it looks newer. The malicious code then runs wherever that build runs.

In this campaign, the attacker registered public packages matching nine targeted internal scopes, betting that somewhere, someone's configuration would fall back to the public registry and grab the impostor.

Why does "reconnaissance only" make this worse, not better?

Because reconnaissance is how targeted attacks begin. A self-replicating worm that steals credentials is loud and gets noticed fast. A quiet survey that just records "this build server belongs to Company X, runs on this host, with these environment variables" sets up something far more precise later.

Microsoft noted the payload included a server-side toggle — a RECON_ONLY flag that can be flipped to enable "full exploitation in follow-on attacks." Translation for a founder: the attacker is keeping the option open. Today it's a map. Tomorrow, for the companies on that map, it can become a door. The most dangerous breaches are the ones aimed at you specifically because someone already knows you're worth the effort.

This is the same category of risk we covered in the 2026 supply chain worm wave — except where that was theft at scale, this is target selection.

What's the actual business risk if I'm not a developer?

Translate the technical event into money and exposure:

• Reconnaissance data is targeting data. Hostnames, environment variables, and developer context are exactly what an attacker needs to plan a credential theft or a build-pipeline compromise against your company by name.
• The follow-on is a breach, and breaches are expensive. IBM's Cost of a Data Breach Report — whose 2025 edition remains the most recent as of mid-2026 — puts the global average at $4.44 million, with the U.S. average at an all-time high of $10.22 million (Help Net Security, citing IBM). The same report found organizations took a mean of 241 days to identify and contain a breach — eight months in which a quiet foothold does its work.
• Due diligence is watching. Acquirers and investors increasingly ask how you manage software supply-chain risk. "We don't know what packages our build pulls" is, itself, a finding — and technical due diligence findings reprice or kill deals.

The uncomfortable summary: a free reconnaissance survey of your build environment is a discount coupon for whoever attacks you next.

How do you know if you're exposed?

You can't manage what you can't see, and most non-technical founders have never seen their own dependency inventory. Three questions to put to whoever owns your code:

1. Do our builds ever fall back to the public registry for internal package names? If internal scopes can resolve to public npm, you're exposed to this exact class of attack. The fix is configuration — pin internal scopes to the private registry so they never fall back.
2. Do we know every package our build installs, including the ones we didn't choose directly? You "own" maybe 5% of the code that runs; the rest is dependencies of dependencies. An inventory is the baseline.
3. Would we notice a package phoning home during a build? Reconnaissance payloads run quietly at install time. If nothing watches build-time network egress, a survey like this leaves no obvious trace.

If those questions draw blank stares, that's the signal to get a look at your codebase before someone else does. Microsoft's mitigation guidance for this specific campaign is concrete: configure .npmrc so internal scopes resolve only to your private registry, and block egress to the known attacker domains.

Where SystemAudit fits

You don't need to become a security engineer to get a baseline. SystemAudit takes a GitHub link and returns a full system health report in under three minutes — an architecture map, a security scan that surfaces hidden risks, business-ready cost estimates, and a prioritized fix plan — with no developer needed to run or read it. For a founder trying to answer "are we exposed to things like this?", it turns an opaque codebase into a plain-language risk picture you can act on. The scanner engine is open source, so the checks aren't a black box.

It won't catch every possible vulnerability — no tool does, and any honest one says so — but surfacing your dependency surface and obvious misconfigurations is exactly the kind of first look that this attack rewards companies for skipping. Pair it with the manual habits in our guide to finding exposed secrets in GitHub.

The supply-chain reconnaissance checklist for non-technical founders

Most founders can't read code, but every founder can ask the right questions and recognize a bad answer. Use this checklist as a standing agenda item with whoever owns your engineering — it's built specifically for the "they're mapping us before they hit us" threat this campaign represents.

1. Inventory. Do we have a current list of every package our product and build pull in, including indirect dependencies? If the answer is "no" or "sort of," that's the first gap to close — you can't defend a surface you can't see.
2. Registry hygiene. Are our internal package names pinned so the build can never fall back to the public registry for them? This single configuration is the direct counter to dependency confusion. Microsoft's guidance for this campaign was exactly this: lock internal scopes to the private registry.
3. Build-time visibility. Would we notice if a package phoned home during a build? Reconnaissance payloads run quietly at install time, so without egress monitoring a survey leaves no obvious mark.
4. Secret exposure. Are credentials and tokens kept out of environment variables that an install-time script could scoop up? Reconnaissance specifically harvests environment context — the less that context contains, the less useful the map.
5. Provenance. Do we verify where packages and updates actually come from, rather than trusting a version number? Attackers in 2026 have published malicious packages carrying valid-looking authenticity signals, so "it has a high version number" is not proof of safety.
6. Response readiness. If we learned tomorrow that one of our internal scopes had been impersonated, who would we call and what would we check first? A plan written in calm beats one improvised in panic.

A team that can answer all six confidently is in a small minority. If yours can't, that gap is the finding — and it's far cheaper to discover it yourself than to learn about it from an attacker who already did the survey.

Reconnaissance now, exploitation later: why patience is the threat

Loud attacks get patched fast because they announce themselves. The thing that makes this campaign worth your attention is its discipline: by taking only a survey, the attacker stays under the radar while quietly assembling a target list. For every company on that list, the cost of the eventual attack drops, because the attacker no longer has to guess — they know your hostnames, your stack, and your context. Treat a reconnaissance event against your ecosystem the way you'd treat someone photographing the locks on your building. Nothing was stolen. That's not the same as nothing happened.

Frequently asked questions

Was anything actually stolen in this attack? According to Microsoft, the observed payload operated in reconnaissance-only mode — collecting environment data rather than immediately exfiltrating credentials. But it included a server-side flag to enable full exploitation in follow-on attacks. So "nothing stolen yet" is the accurate framing, not "nothing to worry about."

Does this only affect companies with internal packages? The dependency confusion technique specifically targets internal/private package names, so organizations with internal npm scopes are the direct targets. But any company whose build configuration can fall back to the public registry shares the underlying exposure. The mitigation — pinning internal scopes to your private registry — applies broadly.

We're a small startup. Are we too small to be targeted? This campaign profiled environments indiscriminately to find worthwhile targets — being small doesn't keep you off the map, and small teams often have the weakest build-pipeline controls. The reconnaissance step exists precisely to sort the haystack; you don't get to decide whether you're interesting until after you've been surveyed.

What's the single most useful thing to do this week? Get a dependency inventory and confirm your build can't pull internal package names from the public registry. If you can't answer those from memory, run a scan or have someone audit the build configuration. Knowing what your code pulls is the foundation everything else sits on.

Want to see your codebase the way an attacker's reconnaissance would? Paste a GitHub link and get a plain-language risk report in under three minutes at systemaudit.dev.