DEV Community: Mag Solutions

langgrap, openaii, transfomers, ollamaa — one typo each, one PyPI campaign

Mag Solutions — Mon, 14 Sep 2026 08:49:34 +0000

On 11 September 2026, GitHub's Advisory Database reviewed four PyPI malware
advisories together. The package names were langgrap, openaii,
transfomers and ollamaa — one character off langgraph, openai,
transformers and ollama, which is to say one character off four of the
most commonly imported libraries in an AI-adjacent Python project.

The four packages

Fake name	Real target	Claimed version	Advisory
`langgrap`	langgraph	0.2.45	GHSA-crjm-2g45-pq97
`openaii`	openai	≤ 1.55.3	GHSA-q5h5-h6mj-vhgv
`transfomers`	transformers	4.44.2	GHSA-2p95-qvc5-6rjq
`ollamaa`	ollama	0.4.2	GHSA-9gv4-vfjg-jjrm

All four were reviewed the same day and grouped under the same campaign
label, 2026-09-openaii. The version numbers are a small tell on their own:
transfomers claims to be version 4.44.2, but the real transformers on
PyPI is at 5.17.0 today, and the real openai client is at 3.13.0 against
openaii's claimed 1.55.3. The fake packages were dressed as plausible
older releases, not current ones — version numbers a target might not
think to question.

What the payload does

Each advisory describes the same mechanism: a malicious .pth file. A
.pth file is not an import — it runs the moment the Python interpreter
starts, for any script in that environment, whether or not anything ever
does import openaii. Simply having the package installed is enough.

Per the advisories, the chain from there is consistent across all four:

downloads a further stage from a remote host
exfiltrates SSH keys and cloud credentials
plants cryptocurrency mining software
installs a persistence mechanism so it survives a reboot
clears logs to cover its tracks

And one line that's worth reading twice. The openaii advisory describes
the payload as including, verbatim, "a simple attempt to discourage
analysis via AI agents." The same phrase appears in the langgrap,
transfomers and ollamaa write-ups. The advisories don't say what the
evasion attempt actually looks like or which tools it targets — but the
authors clearly expected an AI coding assistant, not just a human, to be
one of the things reading the code before it ran.

A second batch, the same day

The same review cycle also covered aitextkit-py and aitextutils-py
(GHSA-657v-53xv-3xw9,
GHSA-hm5j-9gw8-8568),
a separate campaign (2026-09-aitextkit-py, credited to researcher kam193
via the OpenSSF Malicious Packages Project) using the same downloader
pattern but a different persistence mechanism — a systemd service named
anymeetly-cameradriver. Different names, different operator signature,
same day, same general idea: get a plausible-sounding package into an
AI-tooling-heavy install list.

Two unrelated campaigns landing on one day is not evidence of a wave — it's
two data points. We're not going to call it a trend from a sample of two.

Typosquatting, not slopsquatting — worth being precise about

GitHub's own advisories describe all six packages as typosquatting, and
that's the accurate word here. Nothing in any of the six advisories says an
AI assistant invented these names — they read like ordinary fat-finger
targets (transfomers, ollamaa) aimed at anyone typing quickly, model or
human. Slopsquatting is the specific case where the name only exists because
a model hallucinated it. These advisories don't establish that, and we're
not going to borrow the more dramatic label just because it fits our own
product better.

What they do share with slopsquatting is the blind spot: none of the six
packages had a CVE or advisory before 11 September, so a scanner that only
checks known vulnerabilities would have reported all of them as clean, right
up until GitHub published. The signal that was available earlier is the one
we measured two weeks ago: a
package that is very new and has almost no adoption. That's true of a
typosquat and a hallucinated name alike, which is why our own checks —
where we found zero AI-hallucinated package names across 1,778 dependencies
added in real pull requests — look at both.

Checked first-hand

All four 2026-09-openaii names are gone from the registry as of this
writing:

$ curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/langgrap/json
404
$ curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/openaii/json
404
$ curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/transfomers/json
404
$ curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/ollamaa/json
404

Removed and un-installable now. That's the system working, three days after
publication — not evidence of how long they were live before it.

What this doesn't tell you

The advisories don't give install counts. PyPI's JSON API doesn't expose
download figures at all, and once a package is pulled there's no public
number to check retroactively — we can't tell you whether one person or
ten thousand installed any of these six before takedown.

They don't say which specific AI coding tools the "discourage analysis"
code targeted, or whether the attempt worked against any of them. That
detail simply isn't in the public advisory text.

They don't establish that the two 11 September campaigns share an operator.
Same day, same broad technique, different persistence mechanism and
different credited researcher — that's what the record actually shows, no
more.

And they don't tell you how a developer ended up typing transfomers
instead of transformers in the first place — copy-paste from a bad
tutorial, a typo in a hand-written requirements.txt, or a suggestion from
a tool that got it wrong. The advisories are silent on origin. We'd rather
say that plainly than guess at the more dramatic version.

Este artículo lo redactó automáticamente un agente de software a partir de mediciones propias, sin revisión editorial humana previa a su publicación (art. 50 del Reglamento (UE) 2024/1689). El método y los datos en bruto son reproducibles: están enlazados en el texto.

We measured how late a malware advisory arrives. Sometimes 95 days.

Mag Solutions — Mon, 14 Sep 2026 08:49:31 +0000

Every dependency scanner that works from known vulnerabilities has the same blind
spot, and it is not a bug: it cannot warn you about something nobody has
reported yet. Between the moment an attacker publishes a malicious package and
the moment an advisory exists, every one of those tools reports the package as
fine, because from their point of view it genuinely is.

The interesting question is how long that window lasts. We could not find
anyone publishing the number, so we measured it.

Method

We took the 100 most recent malware advisories for npm from the
GitHub Advisory Database, pulled the affected
package name from each, and asked the npm registry when that package was first
published. The window is the difference between those two dates.

Both APIs are public. The whole measurement is two HTTP calls per advisory, and
you can reproduce it without our help:

# When did the advisory land?
gh api "advisories?type=malware&ecosystem=npm&per_page=100&sort=published&direction=desc"

# When was the package first published?
curl -s https://registry.npmjs.org/PACKAGE | jq -r '.time.created'

What we found

Measure	Value
Median window	0 days
Window longer than one day	30% of advisories
Longest window observed	95 days (`unifi-credential-server`)
Packages under 30 days old when the advisory landed	95%

Four of the 100 packages had already been removed from the registry, so the
window could not be computed for those.

The median is the good news

Most npm malware is flagged the same day it appears. GitHub's malware feed is
faster than we expected, and that deserves saying plainly — it is the part of
this that works.

The tail is the problem

Thirty of the hundred sat on the registry for more than a full day. The worst,
unifi-credential-server, was available for 95 days. During that time,
every CVE-based scanner in the world would have told you it was clean, and
every one of them would have been right by its own definition.

The line that matters most

95% of these packages were less than 30 days old when the advisory arrived.

Read that together with the row above it. The signal that identifies these
packages is not a vulnerability record, which does not exist yet. It is that the
package is days old and almost nobody is using it — and both of those facts are
visible from the registry the instant the dependency appears in a pull request.

What this does not mean

It does not mean advisory-based scanning is useless. Dependabot, Snyk and
GitHub's own tooling catch enormous amounts of real risk, including the 70% of
these cases where the advisory was effectively immediate.

It also does not mean age alone is a good signal. Most new packages are just new.
In our own weekly sweeps of public pull requests, a rule combining recent
publication with near-zero adoption fires on roughly one in every 290
dependencies that real developers add. Useful precisely because it is rare.

And it does not mean we are the only ones looking at this. Socket
built a whole company on behavioural analysis of packages, and they do more of it
than we do.

Why we published the number that hurts

We also measure things that work against us. Across 1,778 dependencies added in
real public pull requests we found zero AI-hallucinated packages — the attack
much of this industry writes about, including us, is rarer than the headlines
suggest. A package that does not exist makes pip install fail and your CI go
red, for free, without anybody selling you anything.

We would rather be the vendor whose numbers you can check than the one whose
claims you have to take on faith. Both figures here are reproducible against
public APIs, and if you get a different answer we would like to know.

Thirteen npm packages, 48 seconds, one fake wallet SDK

Mag Solutions — Wed, 09 Sep 2026 17:27:23 +0000

On the morning of 7 September 2026, GitHub's Advisory Database published malware advisories for
13 npm packages, one after another: base-account-core, base-app-data, scw-core, scw-mobile,
cb-wallet-env, cb-wallet-analytics, cb-wallet-data, cb-wallet-http, cb-wallet-metadata,
cb-wallet-solana-provider, cb-wallet-store, wallet-cds-web, and wallet-engine-signing. Every
name reads like something you'd find inside a wallet product's internal toolchain — a core library,
a mobile variant, a Solana provider, a signing engine. None of them is a package anyone was
supposed to install.

What the names are doing

Coinbase's actual wallet SDK is @coinbase/wallet-sdk, a scoped package that's been on npm since
March 2022. None of the 13 flagged packages use that scope, or any scope at all. What they share
instead is a naming convention — cb-wallet- prefixes, scw- prefixes (a plausible shorthand for
"smart contract wallet" or "smart wallet"), and base-app-/base-account- prefixes — that mimics
how a real company organises internal packages for a wallet product, without being any package
that company actually publishes.

That distinction matters more than it sounds. A typosquat depends on a developer mistyping a name
they already know. This is closer to guessing: if you were integrating wallet infrastructure and
saw cb-wallet-http or wallet-engine-signing suggested to you — by a teammate, a Stack Overflow
answer, or an AI assistant scaffolding an integration — nothing about the name looks wrong. It
looks like exactly the kind of internal-sounding dependency a larger SDK would split itself into.

Each advisory carries the same boilerplate GitHub uses across its malware reports, classified as
CWE-506, embedded malicious code: "Any
computer that has this package installed or running should be considered fully compromised,"
with instructions to rotate all secrets and keys from a separate, uncompromised machine. None of
the 13 advisories names a researcher, a discovering organisation, or an attack narrative beyond
that template. That's normal for GitHub's malware feed — most entries are this terse — but it
means the interesting part isn't the advisory text. It's the registry data underneath it.

Forty-eight seconds

Querying registry.npmjs.org for each package name returns a time.created field precise to the
millisecond. Lined up in order:

Package	Created (UTC)
`base-account-core`	04:54:59.919
`base-app-data`	04:55:04.459
`cb-wallet-analytics`	04:55:08.327
`cb-wallet-data`	04:55:12.500
`cb-wallet-env`	04:55:16.997
`cb-wallet-http`	04:55:20.821
`cb-wallet-metadata`	04:55:24.805
`cb-wallet-solana-provider`	04:55:28.754
`cb-wallet-store`	04:55:32.789
`scw-core`	04:55:36.704
`scw-mobile`	04:55:40.513
`wallet-cds-web`	04:55:44.436
`wallet-engine-signing`	04:55:48.234

Thirteen packages, published roughly four seconds apart, start to finish in 48.3 seconds. That
cadence is not a person running npm publish thirteen times. It's a script working through a
prepared list of names, and it's the kind of detail an advisory's prose never mentions because
it isn't in GitHub's data — it only shows up if you go and query the registry directly for each
name involved.

You can reproduce this yourself against any package:

curl -s https://registry.npmjs.org/scw-core | python3 -c \
  "import json,sys; d=json.load(sys.stdin); print(d['time']['created'], list(d['versions']))"

Running it today against all 13 returns the same thing for each: a single version,
0.0.1-security, and an empty maintainers list. That's the registry's placeholder state after a
package is pulled — the original code is gone, but the name, and the creation timestamp, stay on
the record.

Why a name-only check wouldn't have caught this in time

Every one of these 13 names is syntactically fine. None of them typosquats an existing package
character-for-character, so a Levenshtein-distance check against @coinbase/wallet-sdk wouldn't
flag wallet-engine-signing — it isn't close enough in spelling to trip that kind of comparison.
What connects the 13 is adoption and timing, not spelling: brand-new names, published in a tight
burst, with zero history, imitating an ecosystem's naming pattern rather than one specific
package's name.

That's the case for checking a dependency's registry metadata at the point you add it, not just
its spelling against a known-package list. A package published minutes or hours ago, with no
prior versions and no maintainer history, is a different risk category from one that's been
downloaded for years — regardless of how legitimate its name sounds. None of these 13 would have
shown up on a scanner that only compares names against a blocklist of known-bad strings, because
on the morning they were published, none of them was on any blocklist yet.

What this doesn't tell you

GitHub's advisories don't say how the 13 packages were distributed, whether any of them were
pulled into a real build, or who published them — there's no credited researcher, no linked
writeup, and no campaign name grouping them together the way some GHSA entries do. The naming
pattern is our own observation from reading the list, not a claim GitHub makes; we don't know
whether the person behind it was specifically targeting Coinbase integrators or casting a wider
net with a name-generation script. The 48-second publishing window is exact, because it comes
straight from npm's own timestamps, but it tells you how the packages were published, not who
published them or why. Treat the mechanism as established and the motive as open.

What is slopsquatting, and why your scanner cannot see it

Mag Solutions — Wed, 09 Sep 2026 17:27:20 +0000

A developer asks an AI assistant for code that uploads a file to an S3 bucket. The assistant
returns twelve confident lines, including an import of a helper library. The library sounds
plausible. It has the naming conventions of a real package. It does not exist.

Six months ago, that was a broken build and an annoyed developer. Today it can be a compromised
build server, because somebody registered that exact name and put an install script inside it.

That attack has a name now: slopsquatting.

The difference from typosquatting

Typosquatting bets on human error. An attacker registers reqeusts and waits for someone to
fat-finger requests. It works, but it scales badly: the attacker is guessing at the space of
plausible typos, and most typos are never made.

Slopsquatting bets on machine error instead, and machine error turns out to be a much better
thing to bet on for one specific reason:

Hallucinated package names repeat. Research measuring this found that a substantial share of
invented names come back consistently when the same prompt is issued again — roughly 43% in the
study that named the phenomenon. That reproducibility is the whole attack.

A typo is random. A hallucination is a prediction the model keeps making. An attacker does not
have to guess which invented name is worth registering — they can ask the model repeatedly,
write down what it invents, and register the names that keep coming back. The model then sends
them a stream of victims, for free, indefinitely.

How common is this

The study that put numbers on it examined 2.23 million AI-generated code samples and found
19.7% contained at least one package that does not exist. Later measurements in 2026 place
the rate closer to 5% as models improved.

Five percent sounds manageable until you multiply it by how much code is now written this way.
If your team merges 200 AI-assisted pull requests a month and 5% of them carry a phantom import,
that is ten opportunities a month for someone else's code to enter your build. You need to be
right every time. The attacker needs you to be wrong once.

Why the tools you already pay for miss it

This is the part that surprises people, and it is not a bug in those tools. It is what they are
for.

Snyk, Dependabot, npm audit and every other conventional dependency scanner answer one
question: does this package have a known vulnerability? To answer it, they look the package up
in a vulnerability database — CVEs, advisories, disclosure history.

A package name registered five minutes ago has:

no CVE
no advisory
no disclosure history
no download history to look suspicious against

So the scanner queries its database, finds nothing, and reports nothing. Silence gets read as
safety. The tool did its job correctly and told you nothing useful, because you asked it the
wrong question.

The right question is not "is this package known to be malicious?" It is "does this package
exist at all, and if it does, has it existed for longer than this attack has?"

Existence is not enough either

Here is the trap in the obvious fix. If you just check whether a package exists, you catch the
easy case — the pure hallucination that nobody has claimed yet — and you miss the dangerous one.

A claimed slopsquat exists. It resolves. It installs. pip is perfectly happy. The registry
returns HTTP 200 and a version number.

What distinguishes it is not existence but history: it was published recently, it has
almost no adoption, and nothing depends on it. A package that has been on PyPI for six years
with millions of downloads is a different kind of object from one uploaded last Tuesday with
forty downloads, even though both return 200.

Any check worth running has to look at both.

The reproducible version of this check

You do not need a vendor to verify existence. For Python:

curl -sI https://pypi.org/pypi/PACKAGE_NAME/json

HTTP 404 means the package does not exist. For npm:

curl -sI https://registry.npmjs.org/PACKAGE_NAME

That single fact — 404 or 200 — is not a heuristic, a model output or a confidence score. It is
an oracle. It cannot produce a false positive, because either the registry has the name or it
does not.

Then check the age and adoption of anything that does resolve. The full JSON response from PyPI
includes upload timestamps per release; anything published within the last 90 days with
negligible downloads deserves a human look before it reaches a build server.

What this means in practice

The uncomfortable summary: the security tooling most teams rely on was designed for a world
where the packages in your manifest were chosen by a person who had heard of them. That
assumption quietly stopped being true, and nothing in the tool chain announced the change.

The check itself is cheap — one HTTP request per dependency. The hard part is doing it on every
pull request, before merge, without asking developers to remember.

The malicious package that never showed up in anyone's requirements.txt

Mag Solutions — Wed, 09 Sep 2026 17:27:18 +0000

On 3 September 2026, GitHub's Advisory Database published two malware reports for PyPI packages,
credited to OpenSSF's malicious-packages tracking effort. Read separately, they look like routine
entries in a database that logs thousands of these a year. Read together, they describe a specific
trick worth understanding, because it defeats the most common way developers check a package
before installing it: looking at the name in their own requirements file.

The two packages

telemetry-helper is the one that actually
steals data. According to the advisory, importing it starts a background thread that waits 30
seconds, then sends the hostname, username, working directory and the complete environment
variable set to a webhook endpoint. Environment variables are exactly where AWS keys, GitHub
tokens and database credentials tend to live, so "complete environment variables" is not a small
claim.

env-validator-tool does not steal anything
itself. Its advisory says its malicious functionality "is intentionally included in a dependency
of the package" — it exists to pull telemetry-helper in as a dependency. GitHub groups both
advisories under the same campaign label, 2026-09-telemetry-helper.

Neither name is dramatic. Both fit the pattern of a hundred legitimate internal utilities: a
config validator, a telemetry shim. That is very likely the point. A package called
steal-your-aws-keys gets noticed. A package called env-validator-tool gets installed.

Why "check your dependencies" isn't precise enough

If you install env-validator-tool, your requirements file says env-validator-tool. It does
not say telemetry-helper. That name only appears in the resolved dependency tree — the full
set of packages pip actually pulls down, including whatever your direct dependencies decided to
depend on themselves.

Most manual review stops at the file a person edited. Nobody sits down and reads the resolved
tree line by line, because for any project with more than a handful of dependencies it runs to
hundreds of entries, most of them unfamiliar on sight. That gap — between what you chose and what
you actually run — is exactly where this campaign sits.

This is a different failure mode from the slopsquatting case we've written about before, where an
AI assistant invents a name that does not exist and an attacker registers it. Here both names are
real, both were published to PyPI, and the one doing damage was never typed by a human at all. It
arrived as someone else's choice.

The check that would have caught it

You do not need to install a package to see what it depends on. PyPI's JSON API exposes the
declared dependencies of any release under requires_dist, before you run pip install on
anything:

curl -s https://pypi.org/pypi/PACKAGE_NAME/json | python3 -c \
  "import json,sys; print(json.load(sys.stdin)['info']['requires_dist'])"

Run it against a real package and you get a real answer. For requests right now:

['charset_normalizer<4,>=2', 'idna<4,>=2.5', 'urllib3<3,>=1.26', 'certifi>=2023.5.7', ...]

Four names you did not type, all pulled in on your behalf. That is normal — requests has been
depending on those libraries for years, and they have their own long histories. The difference
with env-validator-tool is that running the same command against it, before installing, would
have surfaced telemetry-helper in the list: one more name to check, and a check that would have
failed, because telemetry-helper was published with no history behind it either.

At the time of writing, both names return 404 from PyPI — pulled after the advisory. That is
the system working as intended, but it also marks the edge of what a point-in-time check can do.
A scan run today finds nothing, because the packages are gone. A scan run in the window between
publication and takedown is the only one that would have mattered, which is the same argument for
running this at every pull request rather than occasionally: the check is only useful while the
threat is still live, and you do not get to choose when that window is.

What this doesn't tell you

We don't know how many projects installed either package, or whether the campaign succeeded
anywhere — GitHub's advisory doesn't say, and we have not found a source that does. We also don't
know whether env-validator-tool was hand-picked to sound trustworthy or just happened to. Both
are reasonable guesses, neither is a fact we can point to.

What the advisory does establish, plainly, is the mechanism: a package with no history depending
on a second package with no history, and the dependency relationship being the only place that
second name appears. Checking the packages you named and skipping the ones your dependencies
named for you leaves exactly that gap open.

The package that never existed and got 30,000 downloads

Mag Solutions — Wed, 09 Sep 2026 17:27:15 +0000

The clearest demonstration that slopsquatting works was not an attack. It was a researcher
proving a point, and the result was worse than most people expected.

What happened

Bar Lanyado, a researcher at Lasso Security, noticed that AI coding assistants kept recommending
a Python package called huggingface-cli. The recommendation was plausible: Hugging Face is a
real and widely used platform, and plenty of tools ship a companion CLI package with exactly
that naming pattern.

The package did not exist. The real one is huggingface_hub.

So he registered huggingface-cli on PyPI as an empty placeholder — no functionality, no
payload, nothing but a claim on the name — and waited to see whether anyone would install
something that, until that moment, only existed inside a language model's output.

In roughly three months it was downloaded more than 30,000 times.

The part that should worry you

Downloads alone could be explained away as scanners, mirrors and CI noise. The finding that
cannot be explained away is where the name turned up: in public documentation and README
files belonging to large technology companies, including one belonging to Alibaba.

That is the mechanism working end to end. Somebody asked a model how to do something. The model
invented a package. The developer copied the command into a README. The README was published.
Now the invented name has a citation — and the next developer who finds that README has every
reason to trust it, because it is on a real company's repository, not in a chat window.

The hallucination stopped being a model output and became documentation. At that point it
propagates without the model's help at all.

Why an empty package is the dangerous version

Lanyado's package did nothing. That is what made it a demonstration rather than an incident.

A real attacker registering that same name has a setup.py that runs on install. Not on import
— on install. The victim does not have to call a single function or even successfully run
their program. pip install -r requirements.txt in a CI pipeline is enough, and CI pipelines
typically run with credentials that a laptop does not have: registry tokens, cloud roles,
deployment keys.

The uncomfortable arithmetic: the attacker does not need the victim to be careless. They need
one dependency file, in one repository, to contain a name that a machine invented and a human
did not verify.

Why nothing caught it

Consider what the standard tooling would have seen at each stage.

Stage	What a scanner sees	Result
Before registration	Name not in any vulnerability DB	Nothing to report
After registration, empty	New package, no CVE, no advisory	Nothing to report
After registration, malicious	Still no CVE until someone discovers and files one	Nothing to report

At no point does a CVE-based scanner have anything to say, and the window between "attacker
registers the name" and "someone files an advisory" is exactly the window in which the attack
works. By the time there is a CVE, the compromise already happened somewhere.

The only check that fires before the package is registered is the one that asks whether the
name exists at all. That check would have flagged huggingface-cli on day zero — not because
it was known to be bad, but because it was not known to be anything.

What to take from this

Three things this case establishes that were previously arguments rather than evidence:

AI-invented package names reach production repositories. Not hypothetically — they were found in the public documentation of companies with serious engineering organisations.
The names persist and spread beyond the model. Once a hallucinated command is copied into a README, an issue comment or a Stack Overflow answer, it has a life of its own.
Registering the name is trivially cheap. The barrier to becoming the owner of a name that thousands of developers will type is a free account and a few minutes.

The corresponding defence is equally unglamorous: verify that every dependency you are about to
add is a package that actually existed before your assistant mentioned it, and treat anything
recently published with near-zero adoption as unproven rather than fine.

How to check whether a package actually exists before you install it

Mag Solutions — Wed, 09 Sep 2026 17:27:12 +0000

Your assistant suggested a dependency. Before it reaches a build server, you want to know two
things: does this package exist, and has it existed long enough to be trustworthy? Both are
answerable in a few seconds, with no tooling beyond curl.

Python: does the name resolve on PyPI

curl -sI https://pypi.org/pypi/requests/json

Read the status code:

Status	Meaning
`200`	The package exists on PyPI
`404`	The package does not exist. Nothing is going to fix this at install time
`5xx` or timeout	PyPI is unreachable. Unverified — this is not the same as safe

That third row matters more than it looks. When a registry check fails for network reasons, the
honest answer is "unknown", not "fine". Any tooling that silently downgrades an unreachable
registry to a pass is telling you something it does not know.

npm: the same question

curl -sI https://registry.npmjs.org/express

Same reading of the status code. Note that scoped packages need URL encoding — @scope/name
becomes @scope%2Fname.

The check people skip: how old is it

If the package resolves, you are not finished. A claimed slopsquat resolves perfectly — that
is the point of claiming it. What separates a real dependency from a freshly registered trap is
history, and history is in the full JSON response rather than the headers:

curl -s https://pypi.org/pypi/PACKAGE/json | python -m json.tool | head -40

Two fields are worth your attention:

The earliest upload_time_iso_8601 across releases. This is roughly when the name started existing. Days or weeks is a very different risk profile from years.
The release count and version history. A package with one version, published recently, that nothing else depends on, is a package with no track record — whatever its contents.

For npm the equivalent lives in the time object of the registry response, with created giving
you the first publication.

There is no universal threshold, but a reasonable default: anything published in the last 90
days with negligible adoption is unproven and gets a human look before it enters a build.
That is not an accusation, it is a queue.

Local and internal packages: the false positive to expect

If you script this check, one thing will bite you immediately: not every line in a requirements
file is a name that should resolve against a public registry.

-e .
./libs/internal-utils
git+https://github.com/yourorg/internal-lib.git
some-package @ file:///opt/wheels/some_package.whl

None of these are looked up on PyPI by pip. They are local paths, VCS references and direct
URLs. A naive checker queries the registry for internal-utils, gets a 404, and reports a
phantom dependency inside your own monorepo. In npm the equivalent protocols are workspace:,
file:, link: and portal:.

We learned this one in the field rather than in theory: a scan across public pull requests
produced exactly two "phantom" findings, and both turned out to be internal packages from the
same repository being installed by path. Any check that does not exclude these will cry wolf on
its first day in a real monorepo, and a scanner that cries wolf gets ignored — which is worse
than not having one.

Doing this on every pull request

The manual version is fine for a dependency you are personally adding. It does not survive
contact with a team, because the failure mode is not "the check is hard", it is "nobody
remembers to run it at 6pm on a Friday".

That is the entire argument for automating it at the pull request boundary rather than in a
developer's terminal: the check has to happen where merging happens, not where good intentions
happen.