Free tools

Nothing to install, nothing uploaded.

Everything on this page runs in the browser tab you already have open. There is no account, no key, no download and no server behind it: the data is compiled into the page and the check happens on your machine, which is the same rule the licensed scanner follows on a much larger surface. Start with the tool, not with the pitch.

Start the 14-day trial Open the slopsquatting checker →

No account
No install
Nothing uploaded
Runs in your browser

01 / The tools

One tool today, and it is the one worth having

A hub with one working entry is worth more than a hub with five links to nothing, so this lists what ships and stops there.

An AI assistant writes an install line for a package that does not exist. The name is plausible: right ecosystem, right naming convention, right shape for the job you just described. Nothing about the suggestion looks wrong, because the model is not misreporting a fact, it is completing a pattern.

The attack is what happens next. Someone collects the names assistants invent, registers them in the public registry, and waits. The next developer who copies that install line gets a real package, with a real download count, belonging to the attacker. That is slopsquatting, and it differs from typosquatting in who makes the mistake: typosquatting waits for a human to slip a finger, slopsquatting waits for a machine to guess confidently, which it does the same way twice and is therefore worth predicting.

It is worth checking because the failure is expensive and the check is cheap. An install script runs on a developer machine and then in continuous integration, with whatever credentials are sitting in that environment. Reading a name takes a second.

Shipped

The slopsquatting checker

Paste a list of package names, a package.json snippet or a requirements.txt snippet. Each name is checked for an exact match to a documented malicious release, an exact match to a curated AI-hallucinated name, a close typosquat of a popular package (including scope and separator confusion), and the popular-name-plus-suffix pattern that rides another package’s reputation.

npm and PyPI names. The comparison runs in the page, so nothing you paste is sent anywhere.

288

Popular npm names embedded

compiled into the page, compared in memory

230

Popular PyPI names embedded

plus curated malicious and hallucinated seed lists

Requests the check makes

the page loads once, then the check runs locally

slopsquatting checker5 names checked

Package	Verdict	Closest match	Note
huggingface-clipypi	hallucinated	huggingface-hub	The documented proof-of-concept. The real CLI ships inside huggingface-hub.
react-http-clientnpm	hallucinated	-	Commonly invented by assistants. There is no canonical package by this name.
lodahsnpm	typosquat	lodash	One transposition away from a popular name.
event-streamnpm	malicious	event-stream	Compromised in 2018 through a dependency, to steal wallet keys.
expressnpm	no signal	-	Matched nothing in the embedded lists. Not a clearance.

The verdicts the checker returns, reconstructed from its own dataset. Verdict is shape plus label plus colour, so the signal survives a greyscale print.

A verdict of no signal is not a clearance. The embedded lists are a fast screen rather than a copy of the registry, so an unrecognised name means only that it matched nothing here. Open the checker →

02 / Where the check runs

The check goes to the data, not the other way round

A free tool is the cheapest place to demonstrate the rule the whole product is built on, because you can check this one yourself in about ten seconds.

The dataset is compiled into the page and the comparison is plain JavaScript, so the work happens in the tab. There is no API behind the button, nothing you paste is stored, and there is no server that could hold a copy of your dependency list even if someone came asking for one.

You do not have to take that on trust. Open your browser’s network panel, then run the check: the page loads once and then goes quiet. A dependency list is not the most sensitive thing you own, but it does describe your stack, and the habit of sending it somewhere is the habit worth breaking.

The licensed scanner applies the same rule to a much larger surface. A scan reads your repository on your machine, builds the call graph and the taint there, and writes findings to a local database. One line leaves, and it carries an entitlement check and a usage counter: never source, never file names, never findings. That claim is harder to verify from a marketing page, which is exactly why it is worth showing you the version you can verify first.

trust boundaryone switch closes it

Everything the scan needs stays on your machine: the code it reads, the map it builds of how your product fits together, the findings it writes, and the optional local model it can consult without leaving the machine. One line leaves.

Stays on this machine: source code, call graph + taint, findings, account layer, and the local model on 127.0.0.1
One crossing: A signed entitlement check and a usage counter, on a debounced cadence.
Never crosses: source code, file paths, file names, finding contents, project names, the hardware fingerprint

The boundary the licensed scanner enforces: one crossing, and it carries the account check. The browser tools sit inside the same line with the crossing removed, because there is no account to check.

03 / Vulkro Labs

The keyless command line, one step further in

Between a browser tool and a licensed scanner sits a free CLI that reads your real manifests and still asks for no account.

A browser tool is right for one name or a pasted list. Your actual project is a manifest, a lockfile and a set of agent tools you added on faith, and that is what Vulkro Labs checks. It ships as the vulkro-live CLI: free, keyless, and installed with one command.

Labs guards the front door rather than reviewing what you write. It vets the packages an assistant suggested, the Model Context Protocol servers you were about to add, the skills and stored memory an agent reads, and the agent cards it trusts. Where the browser tool compares against a small embedded list, Labs queries the public registries and the public malicious-package records directly, so public package metadata does leave your machine. Your source does not.

That is the honest ladder, and it is worth stating plainly. The browser tool sends nothing. Labs sends package names and versions to public feeds and reads code only to list what you have. The scanner reads the code and sends nothing but the account check.

$ vulkro-live verify --manifest package.json
OK        express          real, established, not flagged
[CRITICAL] MALICIOUS  lodahs   flagged in the public records
[CRITICAL] MISSING    reqwest-helper   not in the registry

One keyless command against a real manifest. Only public package metadata leaves the machine, and the result is the same list you would have read by hand.

Every Labs command and what each one checks →

04 / The limit

What a free tool cannot tell you

The free tools screen names. They do not read code, and that difference is most of the product. Here it is as a table rather than as a footnote.

What the free browser and keyless tools do not cover, and where each of those jobs is done instead.
Not covered by the free tools	What that means	Where that work happens
Your source code	A browser tool sees the names you paste. It never opens the files that import them, so it cannot say what a package is used for or whether the risky call is reached at all.	The licensed scan parses the repository on your machine, builds a call graph from it, and reports every finding at a file and a line.
Dataflow into a sink	Nothing here follows a request value into a query, a shell command or a template. That is the analysis, and it needs the code.	The scanner follows a tainted value across file boundaries for up to four hops in Python, JavaScript, TypeScript and Go. Java taint is same-file only, which is published rather than hidden.
Routes and the authorisation on them	A package list says nothing about the endpoints you expose, or which of them skip the authorisation check their siblings apply.	Route extraction and the authorisation rules run inside a scan, over the frameworks the engine understands.
Your real dependency graph	The checker compares names against a small embedded list. It does not resolve your lockfile and it does not match a CVE.	The scan parses manifests and lockfiles for the resolved versions rather than the declared ranges, and matches them against a CVE bundle on your disk. The bundle is checksummed and matching makes no network call.
A verdict you can gate a pipeline on	Nothing on this page produces an exit code, a report you can attach to a review, or a result two people can compare.	The CLI returns the same findings for the same input on every run and exits non-zero when findings are reported, which is what makes a gate safe to leave switched on.
Salesforce	Apex, Lightning components, Flow and org metadata are read by no tool on this page.	That is Vulkro for Salesforce: a separate binary running the same engine with a rule set written for the platform.

Read the middle column as the limit and the right column as where the same question is actually answered. The free tools are a screen on names by design, not a shallow version of a scan.

None of that makes the free tools a trailer for something else. They stay free and they stay keyless, because catching an invented package name before it enters a project is worth doing whether or not you ever license anything. The line is simply where the work moves from a name to the code around it.

If that is the point you have reached, what a full scan reports is the page that describes the findings, and the first run walks through installing and scanning a repository end to end. Your first sign-in on the CLI starts a 14-day trial of the full product with no card; after that, licences are issued directly by our team.