DEV Community: relayshieldadmin

Who can publish into your dependencies?

relayshieldadmin — Thu, 13 Aug 2026 16:43:40 +0000

Install Next.js, React, TypeScript, ESLint, Jest, axios, Tailwind, Prettier and dotenv into an empty
directory. That is not an unusual project. That is Tuesday.

You get 433 packages. Behind those 433 packages are 275 distinct accounts that can publish code
into them, and 126 of those accounts are on consumer webmail. 118 of the 126 are gmail.com.

Nobody is doing anything wrong in that sentence. That is the part worth sitting with.

We built the thing that counts it, we are releasing it under MIT today, and you can reproduce every
number in this post in about a minute.

pip install rsscan
rsscan --deps

It reads package-lock.json or package.json from the current directory, resolves each package to
the accounts that can publish it, and prints counts. It runs locally. There is no account, no API
key, and no network call to us: the only host it contacts is registry.npmjs.org.

What we measured

Six manifests, generated with npm install --package-lock-only --ignore-scripts, which resolves the
full transitive tree from registry metadata without downloading a tarball or running an install
script. Then rsscan --deps over each.

Install	Packages	Publisher accounts	On consumer webmail	Role or automation
`npm i express`	65	85	46 (54%)	11
`npm i webpack`	67	95	40 (42%)	12
`npm i eslint`	68	101	51 (50%)	14
`npm i jest`	289	208	96 (46%)	19
`npm i next`	54	29	10 (34%)	4
the nine packages above, together	433	275	126 (46%)	28

Measured 13 August 2026. These numbers will drift as maintainer lists change, which is rather the
point.

Three things about the method, because a number nobody can check is not a finding.

"Publisher account" means a distinct email in the registry's maintainers array, plus _npmUser
on the version you would actually install. That second field matters: maintainers lists everyone
who could have published, while _npmUser is whoever did push the bytes sitting in your
node_modules.

Email is a proxy for account, and it is imperfect in both directions. One human with two
addresses counts twice. Two humans sharing an address count once. We report distinct addresses and
call them accounts because that is what the registry exposes, and pretending otherwise would be
worse than the caveat.

"Consumer webmail" is a fixed domain list, and we checked it was not inflated before publishing
this. No GitHub noreply addresses landed in the count. Role and automation addresses like
security@ or oss-bot@ are counted in their own column and excluded from the webmail figure, so
nothing is double counted.

The Unresolved column is zero across all six, and it exists because it is the column that keeps
the rest honest. A package whose publishers we could not look up is not a package with no
publishers. If a run cannot reach the registry, --deps prints that count in red rather than
quietly folding it into a reassuring total.

Why this number is the one that matters

Every package security tool on the market reads the artifact. Socket, Snyk, Aikido, Endor: they
fetch the tarball, look at what the code does, and tell you whether it is dangerous. They are good
at it, and if you are not running one you should be.

They share a blind spot, and it is not a bug in any of them. It is structural.

A self-replicating npm worm does not begin with malicious code. It begins with a maintainer
account.

Reconstruct one from the end and the sequence is always roughly this:

A maintainer's laptop gets infostealer malware on it. Not a targeted attack. The usual route: a cracked tool, a fake browser update, a malicious ad.
The stealer takes everything the browser and the filesystem will give it. Saved passwords, session cookies, and, on a developer machine, the contents of .npmrc. That file holds a long-lived npm publish token.
The token is sold in a log, usually within days.
The buyer publishes a new patch version of a package that maintainer owns. The code is not subtle. It does not need to be, because nobody is reading a patch bump.
That version runs on install, in CI, on machines belonging to everyone who depends on it. It harvests their npm tokens.
It publishes itself into their packages. Now it is a worm.

Look at where the detectable code appears in that list. Step four. By the time there is a
malicious artifact for a scanner to analyse, the compromise is four steps old and propagation is one
step away. Everything before step four is an identity problem, and none of it is visible in a
tarball, because none of it has happened in a tarball yet.

Shai-Hulud, in September 2025, is the version of this most people have now heard of. It is worth
being precise about why it spread: not because the payload was clever, but because the credential
that lets you publish to npm is a bearer token that usually lives in a plaintext file on a laptop,
and laptops get infostealers.

Which is why 126 is a more interesting number than 433. A publish credential on a company domain
sits behind SSO, and when that person leaves or gets compromised there is an IT function that can
revoke it centrally. A publish credential on a personal Gmail has none of that. There is no
offboarding, no central revocation, no device management, and no security team. That is not a
criticism of the maintainers. It is a description of how open source actually gets published, by
people doing it on their own machines, on their own time, with their own accounts, largely for free,
in code that the rest of us then put in production.

What `--deps` deliberately does not do

It does not screen anybody. It counts.

That is a design decision and not a roadmap gap, so it is worth being direct about where the line
is. rsscan --deps tells you the size and shape of your publisher surface. It cannot tell you
whether any of those 275 accounts is compromised right now, because answering that means checking
identities against infostealer corpora and breach data, and that is a different job with real costs
attached. We sell that part. This part is free, and it is free in the way that matters: no account,
no key, no rate limit, and no telemetry.

It also names nobody. Not in the output, not in a log, not in a debug field. You do not need any
individual's identity in order to pin a version and require review on its updates, and naming an
uninvolved third party as a risk carries real legal exposure for zero benefit. The tool prints
integers.

On telemetry specifically, since this is a security tool asking to be run on your machine:
rsscan --deps sends nothing anywhere. The wider rsscan secret scanner has an --org flag that
reports a domain and severity counts so we can see adoption at a company, and it is opt-in, off by
default. We wrote a version that inferred it from your git commit email and turned it on by
default. We held that version back and shipped this one instead.

The honest limit

A count is not a verdict, and registry metadata is not always current. If a maintainer changed their
email and the registry still lists the old one, --deps counts an address that is not theirs any
more. That inflates the count in one direction and hides a real account in the other. We would
rather you hear that from us than find it yourself.

rsscan is MIT licensed, on PyPI and
GitHub, and also ships as a pre-commit hook, a GitHub
Action, a GitLab CI component, a CircleCI orb and a Docker image. The dependency counting is new in
this release. The secret scanning has been there since the start, matches 31 credential patterns
entirely on your machine, and never transmits your code or a matched value.

If you want the part that answers "and is any of them compromised", that is
our dependency-risk API, included flat
in a bundle rather than metered per manifest, because re-screening 400 maintainers costs us about
what re-screening four does.

But run the free one first. Point it at your own lockfile and see how many people can publish into
your production build. Most teams have never counted.

pip install rsscan && rsscan --deps

The npm Worm Does Not Start With Malicious Code

relayshieldadmin — Wed, 12 Aug 2026 18:32:50 +0000

They all share a blind spot, and it is not a bug in any of them. It is structural.

A self-replicating npm worm does not begin with malicious code. It begins with a maintainer
account.

The actual chain

Reconstruct one of these from the end and the sequence is always roughly this:

A maintainer's laptop gets infostealer malware on it. Not a targeted attack. The usual route: a cracked tool, a fake browser update, a malicious ad.
The stealer takes everything the browser and the filesystem will give it. Saved passwords, session cookies, and, on a developer machine, the contents of .npmrc. That file holds a long-lived npm publish token.
The token is sold in a log, usually within days.
The buyer publishes a new patch version of a package that maintainer owns. The code is not subtle. It does not need to be, because nobody is reading a patch bump.
That version runs on install, in CI, on machines belonging to everyone who depends on it. It harvests their npm tokens.
It publishes itself into their packages. Now it is a worm.

Look at where the detectable code appears in that list. Step four. By the time there is a
malicious artifact for a scanner to analyse, the compromise is four steps old and the propagation
is one step away.

Everything before step four is an identity problem. None of it is visible in a tarball, because
none of it has happened in a tarball yet.

The question nobody can answer

Here is the question a security lead actually wants answered before a release:

Of the 412 packages we install, is any of them currently maintained by an account that has been
compromised?

Ask your SCA tool. It cannot answer, and not because it is bad. It analyses code, and this is not a
question about code. It is a question about people, and specifically about whether a particular
human's machine is currently owned.

We can answer it, because that is what we already do. Screening an identity against infostealer
corpora, breach data and session records is the thing RelayShield was built to do. This is that
same engine pointed at a different input: instead of your employees, the maintainers of your
dependencies.

What we shipped

POST /v1/metered/dependency-risk. Send a list of package names, or a package.json or
package-lock.json.

curl -X POST https://api.relayshield.net/v1/metered/dependency-risk \
  -H "X-RS-API-KEY: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"packages": ["left-pad", "chalk", "@types/node"]}'

Each package is resolved to the accounts that can publish it, including the account that actually
published the version you are installing. Those accounts are screened against our infostealer
corpus. You get back findings at the dependency level:

{
  "packages_checked": 412,
  "maintainer_accounts_screened": 148,
  "role_accounts_excluded": 13,
  "dependencies_at_risk": 3,
  "high_severity": 3,
  "findings": [{
    "package": "left-pad",
    "severity": "HIGH",
    "signal": "maintainer_in_recent_stealer_log",
    "most_recent": "2026-07-28T04:12:00.000Z",
    "detail": "An account able to publish this package appears in an infostealer log dated within the last 90 days."
  }],
  "recommended_action": "Pin the flagged versions, require review on their updates, and do not auto-merge their releases until the exposure ages out."
}

That is the whole product. Three of your dependencies are maintained by an account in a recent
stealer log. Pin them, review their updates, do not auto-merge.

Four decisions worth explaining

We never tell you who the maintainer is. Not in the response, not in a log, not in a debug
field. You do not need someone's identity in order to pin a version and require review, and naming
an uninvolved third party as compromised carries real legal exposure for zero product benefit. We
did not build a version that names people even internally, because internal fields have a way of
ending up in support conversations.

Recency is the signal. Breaches are not. A maintainer's address turning up in a 2013 breach
tells you nothing about whether their laptop is owned today, and alerting on it would bury the real
finding under a decade of noise. A stealer log within 90 days is HIGH. Older is MEDIUM, and we call
it context rather than an incident.

Role addresses are excluded from alerting, not just from display. Around 9% of npm maintainer
emails are shared inboxes: security@, dev@, oss-bot@. A hit on a mailing list tells you
nothing about whether one person's machine is compromised, and a false positive on a product whose
entire pitch is the opposite of false positives is worse than no product.

npm first, PyPI later. We measured both. About 91% of npm maintainer emails are individual
humans; on PyPI it is closer to 69%, because PyPI returns a lot of contact@ and mailing list
addresses. npm is both the better join and where the self-replicating worms actually are.

The part that matters more than the scan

A one-time dependency scan is close to decorative. Your tree is clean today and a maintainer gets
phished in March. The compromise happens at a random future moment, which means this is a
continuous product or it is a decoration.

So dependency is now a subject type in Verdict Watch, alongside addresses, emails, domains and
phone numbers. Register a package, and you are notified when the answer changes, not on a
schedule and not when the same known exposure gets a new log entry. Flat rate, because the marginal
cost of re-screening 400 maintainers is approximately the same as re-screening four.

One honest caveat

A clean result means nothing was found in the sources we queried. It is not proof that your
dependencies are safe.

The specific gap worth knowing about: registry metadata is not always current. If a maintainer
changed their email and the registry still lists the old one, we screen an address that is not
theirs any more, and it comes back clean. That is a false clean, and we would rather you hear it
from us than discover it.

When an upstream source is unavailable, we say so explicitly and the response tells you the run was
incomplete rather than printing a reassuring sentence underneath a degraded flag. Nobody's threat
feed proves absence. Anyone selling you that is selling certainty that does not exist.

Getting it

dependency-risk is included at no per-call charge in the Agentic Attack Surface bundle at
$299/mo, alongside LLM credential exposure, MCP registry risk, prompt injection breach exposure,
tech stack CVE and bulk identity risk. Scan a 400-package manifest as often as you like; it costs
the same as scanning four, because that is roughly what it costs us. Buy it on
AWS Marketplace, which draws down
your existing AWS committed spend, or directly by card at
api.relayshield.net/developers.

Outside the bundle it is pay-as-you-go at $0.50 a call, priced against what it costs to serve: one
call fans out to as many as 100 registry lookups and 150 identity screens.

Point it at your own package-lock.json. If it comes back clean, you have lost a minute. If it
does not, you have found the thing four steps before the scanner would.

34 malicious packages discovered targeting Solana developers: Steals wallet credentials and SSH keys

relayshieldadmin — Sun, 31 May 2026 22:10:58 +0000

Socket Security just published research on TrapDoor malware: 34 malicious packages targeting developers building on Solana, Aptos, and Sui. If you've installed any npm or PyPI packages from these ecosystems recently, your wallet may already be at risk even if nothing looks wrong yet.

How it works:

The packages execute on install. They silently harvest crypto wallet credentials, SSH keys, cloud credentials, browser-saved passwords, and environment variables — then exfiltrate everything to attacker infrastructure. The theft of your wallet doesn't happen immediately. Attackers wait for the right moment: a large deposit, a token unlock, a liquidity event.

Three things to do right now:

Check if your developer email appeared in an infostealer log: Stealer logs from infected machines are actively traded on criminal Telegram channels. If your email is in one, your credentials from that machine are compromised regardless of whether your wallet looks fine today

Audit your browser extensions: TrapDoor harvests browser data. Malicious extensions re-harvest credentials on every login after initial infection. Remove anything you don't actively use or can't verify

Move assets to a fresh wallet on a clean device if you installed packages from affected ecosystems in the last 30 days and can't confirm they were clean

The on-chain monitoring fires after the transfer is already out. The attack starts in your dev environment, not on the blockchain.

Full breakdown with remediation steps: https://medium.com/p/a4343023b319

Your Okta Is Only As Strong As Your SIM Card

relayshieldadmin — Mon, 18 May 2026 21:32:52 +0000

Most security teams sleep well knowing MFA is enforced in Okta,
Azure AD, or Duo. Then someone ports an employee's phone number to
a burner SIM in under 10 minutes and the identity perimeter
unravels silently.

This is the SIM swap blind spot in enterprise identity. Almost
nobody is talking about it.

The attack chain

Attacker identifies target via LinkedIn
Calls carrier, provides scraped personal data (DOB, address, last 4 SSN — all available from prior breaches)
Carrier ports the number. Target loses mobile service.
Attacker hits the Okta portal, triggers SMS OTP or recovery
Code arrives on attacker's device. Session established.

Total time: under 30 minutes. No malware. No zero-day.

Where Okta and SMS intersect

SMS OTP as primary factor — Many Okta deployments enable SMS
because app-based authenticators create support tickets. If SMS is
an allowed factor, a SIM-swapped number gives the attacker a live
OTP delivery channel. Your policy is satisfied. Access granted.

Account recovery fallback — Even if primary MFA uses Okta
Verify or TOTP, recovery often falls back to SMS. That single
fallback path is all an attacker needs.

Downstream email compromise — Gmail and Outlook offer SMS
account recovery. SIM swap the employee → reset their Google
account → own the email Okta is registered to. Game over.

The carrier layer is outside Okta's scope

Okta, Microsoft, and Duo will tell you to use phishing-resistant
MFA. They're right. But the carrier layer is invisible to every
identity platform — always has been.

Detecting it with code

SIM swap detection requires querying carrier data directly. Here's
how to check whether a number has been ported before triggering
account recovery or a high-risk action:

REST API (Python)


python
import requests

def check_sim_swap(phone: str) -> dict:
    """
    Returns swapped (bool), swap timestamp, and current carrier.
    Call before any high-risk action gated by SMS-based auth.
    """
    response = requests.post(
        "https://xhh3tfrhng.execute-api.us-east-1.amazonaws.com/prod/v1/sim-swap",
        headers={"x-api-key": "YOUR_RAPIDAPI_KEY"},
        json={"phone": phone}
    )
    return response.json()

result = check_sim_swap("+14155551234")

if result.get("swapped"):
    print(f"⚠️  SIM swap detected at {result['swap_timestamp']}")
    print(f"   Current carrier: {result['carrier']}")
    # Block account recovery, alert security team
else:
    print("✓ No SIM swap detected — safe to proceed")

**MCP Server (for AI agents)**
If you're building agents that handle user identity or account
actions, add SIM swap detection as a pre-flight check:

pip install relayshield_mcp

from plugins.relayshield.relayshield_game_plugin import relayshield_functions
# Drop into any GAME agent worker — check_sim_swap is ready to call

**Where to gate it in your stack**
def okta_account_recovery_hook(user_phone: str) -> bool:
    """
    Pre-recovery hook — block if SIM swap detected in last 24hrs.
    Wire this into your Okta inline hook or recovery flow.
    """
    result = check_sim_swap(user_phone)

    if result.get("swapped"):
        # Log security event, require in-person verification
        security_alert(user_phone, result)
        return False  # Block recovery

    return True  # Safe to proceed

**What to fix right now**
**Audit factor enrollment** — find every Okta user with SMS
enabled
**Disable SMS as primary factor** — enforce Okta Verify or TOTP
**Harden recovery flows** — no SMS fallback for privileged
accounts
**Add detection** — query carrier data before account recovery
or high-risk actions
**Brief your help desk** — social engineering is the human
version of the same attack

**The bottom line**
Enterprise MFA is only as strong as its weakest factor. For most
organizations, that weakest factor is a phone number on a carrier
database that can be socially engineered in minutes.

The carrier layer is invisible to every identity platform. That's
the gap. Now you know where it is — and how to close it.

*SIM swap detection API: [RelayShield on RapidAPI](https://rapidapi.com/relayshielduser/api/relayshield-security-intelligence) — free tier available.*

5 Crypto Security Signals in One API Call — Wallet Risk, Token Honeypots, SIM Swap and More

relayshieldadmin — Fri, 15 May 2026 14:12:03 +0000

If you're building a crypto app, a trading bot, a DeFi dashboard, or an AI agent that touches wallets or tokens, you need security signals baked in — not bolted on after something goes wrong.

RelayShield Security Intelligence is a single REST API that gives you:

Wallet risk scoring: Multi-chain (EVM, Solana, TON)
Token honeypot + rug pull detection: Before your users ape in
NFT contract risk scanning: Ownership, minting, verification flags
SIM swap detection: Live carrier-layer data via Twilio Lookup v2
Email breach checking: 13B+ compromised records

No SDKs. Plain JSON in, plain JSON out. Available on RapidAPI (subscription) or x402 USDC micropayments on Base (pay per call, no subscription needed).

Quickstart — Wallet Risk in Python

import requests

url = "https://relayshield-security-intelligence.p.rapidapi.com/v1/wallet-risk"

payload = { "address": "0xYourWalletAddress" }
headers = {
    "x-rapidapi-key": "YOUR_RAPIDAPI_KEY",
    "x-rapidapi-host": "relayshield-security-intelligence.p.rapidapi.com",
    "Content-Type": "application/json"
}

response = requests.post(url, json=payload, headers=headers)
print(response.json())

Works with EVM addresses, Solana public keys, and TON wallet addresses — the API auto-detects chain type.

Quickstart — Token Security (Honeypot Check)

payload = {
    "chain_id": "1",  # Ethereum mainnet — use 8453 for Base
    "contract_address": "0xTokenContractAddress"
}

response = requests.post(
    "https://relayshield-security-intelligence.p.rapidapi.com/v1/token-security",
    json=payload,
    headers=headers
)
print(response.json())

Returns honeypot status, buy/sell tax flags, ownership renounced, hidden owner, and more.

Pay Per Call with x402 (No Subscription Needed)

If you're building an agent or a low-volume integration and don't want a monthly subscription, the PAYG endpoints accept x402 USDC micropayments on Base:

Endpoint	Price
`/v1/payg/wallet-risk`	$0.15 USDC
`/v1/payg/token-security`	$0.10 USDC
`/v1/payg/nft-security`	$0.10 USDC
`/v1/payg/wallet-screen-batch`	$0.50 USDC (up to 10 addresses)
`/v1/payg/breach`	$0.10 USDC
`/v1/payg/sim-swap`	$0.25 USDC

x402 flow:

Call the endpoint with no payment header → receive 402 + PAYMENT-REQUIRED
Pay USDC on Base to the address in the response
Retry with X-PAYMENT header containing payment proof
API verifies via Coinbase x402 facilitator → returns result

Use Cases

DeFi dashboard: Screen every inbound token for honeypots automatically
Trading bot: Run wallet-risk on counterparties before executing swaps
AI agent: Give your Claude/GPT agent live security intelligence via MCP or direct API
Wallet app: Alert users when their SIM is swapped before their 2FA is compromised
Portfolio tracker: Flag high-risk wallets and scam tokens in real time

MCP Server (Claude / AI Agents)

If you're building with Claude or want to use these signals inside Claude Desktop:

pip install relayshield-mcp

Exposes all endpoints as native MCP tools — no API calls to write.

Links

RapidAPI listing (subscribe + test in browser): RelayShield Security Intelligence
API docs + landing page: relayshield.net
MCP package: pypi.org/project/relayshield-mcp

Built by a 25-year telecom security professional. Questions welcome in the comments.