DEV Community: jomynn

XML External Entity (CWE-611): The Bug No Automated Layer Catches — Proven and Reported Entirely by Hand, Offline

jomynn — Thu, 03 Sep 2026 07:54:43 +0000

One file path. No form, no captured traffic, no automated finding anywhere in the pipeline. Here's the
full story of a real CWE-611 (XML External Entity)
vulnerability — the first bug in this series where a static rule, a business-logic rule, and a wired
Active Test probe all come back empty, and every step from proof to report has to be done by hand — all
running locally, with no cloud AI anywhere in the pipeline.

The vulnerable code

The target is a deliberately vulnerable local training app: a hand-rolled XML "entity resolver" — not a
real XML parser, on purpose, so the demo has no native dependencies — that reproduces the classic XXE
pattern any real parser falls into when DTD/external-entity processing isn't explicitly disabled.

function resolveEntities(xml) {
  const entities = {};
  const entityRe = /<!ENTITY\s+(\w+)\s+SYSTEM\s+"([^"]+)"\s*>/g;
  let m;
  while ((m = entityRe.exec(xml))) {
    const [, name, systemId] = m;
    const filePath = systemId.replace(/^file:\/\//, ''); // BUG: no restriction on which file
    try {
      entities[name] = fs.readFileSync(filePath, 'utf8');
    } catch (err) {
      entities[name] = `[[failed to resolve entity ${name}: ${err.message}]]`;
    }
  }
  let resolved = xml;
  for (const [name, value] of Object.entries(entities)) {
    resolved = resolved.split(`&${name};`).join(value);
  }
  return resolved;
}

app.post('/import', (req, res) => {
  const xml = req.body || '';
  const resolved = resolveEntities(xml);
  const noteMatch = resolved.match(/<note>([\s\S]*?)<\/note>/);
  res.json({ note: noteMatch ? noteMatch[1] : null, resolvedXml: resolved });
});

Every declared SYSTEM entity gets read off disk with no allowlist at all, and the whole resolved
document — not just whatever lands inside <note> — comes back in the response. GET / renders
instructions and the exact curl command to try; there's no <form> anywhere on this app, which turns
out to matter for how you have to prove this one.

Step 1 — Why the static rule engine stays silent (and that's not a bug)

Before assuming "no finding" means "broken," it's worth tracing exactly why. The platform's XXE rule is
real and precise — it just targets a different library's exact call shape than this app uses:

parseXml(String)?(…, { noent: true, … })   ← the rule's actual target: libxmljs's opt-in

This app never calls parseXml or parseXmlString at all — it's a regex-based resolver, deliberately, so
the demo needs no native XML dependency. A code-scan pass produces zero CWE-611 findings, exactly as
the rule's own logic predicts. It isn't a clean zero, though: a generic missing-authorization rule flags
both routes (this app, like the rest of the series, has no auth anywhere), landing a real High finding
on POST /import — a second, entirely separate bug on the same route, worth its own line in a write-up
rather than being lost in the noise.

Step 2 — The dynamic/business-logic path comes back empty too

The path that rescued CSRF and SSRF with at least one automated finding — capture traffic through the
built-in proxy, then check it against the business-logic rules — doesn't help here either. Neither the
live HTTP-interceptor rules nor the business-logic analyzer (both run inside the same proxy command)
have ever had an entity/DOCTYPE-aware check written for them. A captured request carrying a full XXE
payload produces the same generic header findings as every other request and nothing else.

Step 3 — Proving it live, with nothing but curl

There's no form to click through — GET / is instructional only — so proof starts at the terminal:

curl -X POST http://localhost:3008/import -H "Content-Type: application/xml" --data-binary @payload.xml

{"note":"FLAG{xxe-demo-secret}","resolvedXml":"...<note>FLAG{xxe-demo-secret}</note>"}

That's the app's own intended file. The next payload proves it isn't confined to it — pointing the
SYSTEM identifier at file:///etc/passwd instead returns that file's contents just as readily. The bug
isn't "leaks one demo secret" — it's unrestricted file disclosure, any file the server process can read.

Step 4 — Escalating from scratch, because there's nothing to seed from

Every prior bug in this series had a captured request to right-click and send into the built-in Repeater.
Not this one — with no form and no proxy-captured traffic, the request has to be typed in by hand from a
blank editor: method, URL, headers, body, all composed manually. A third payload variant makes a point
worth keeping for a write-up:

<?xml version="1.0"?>
<!DOCTYPE root [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> <!ENTITY host SYSTEM "file:///etc/hostname"> ]>
<note>&xxe;</note>
<!-- &host; -->

The substitution is a literal string replace over the whole submitted document, and the response's
resolvedXml field echoes the entire resolved document — not just whatever ends up inside <note>. The
response shows note still contains only /etc/passwd (that field's own regex is scoped tightly), while
resolvedXml contains both files' contents. An attacker doesn't need to route a read through <note>
at all — anywhere in the document is enough, and several files can leak in a single request.

Step 5 — Attempting the platform's own Active Test probe — and finding there isn't one

The platform has two dozen wired Active Test probes: SSTI, GraphQL introspection, JWT verification, mass
assignment, CSRF confirmation, and more. I checked the full checklist and the CLI's --probes alias list
on camera rather than assert it from memory — neither has an XXE entry. Not a blind or limited probe like
SSRF's — genuinely absent. That's the whole phase: confirming an absence is itself the useful result here,
not a consolation prize for a failed run.

Step 6 — Filing the bug's only finding, by hand

With nothing in the pipeline ever creating a Finding object for this bug, the only way it exists in the
platform at all is filing it manually through the Assets hub's "Create finding" tool. Worth knowing before
you hit it yourself: that dialog collects a title, a risk level, and free-text evidence — no CWE or
reference field at all — so the CWE-611 citation has to go into the title text by hand. It's also worth
knowing the resulting finding will always show a "no proof of concept" submission blocker, regardless of
how much evidence you paste in — manual findings never populate the platform's structured proof field,
only free text. Cosmetic, not a real block on a normal report export.

Step 7 — An unexpected second corroboration

Running the platform's generic "Analyze response" tool over the /etc/passwd variant's captured
transaction surfaced something worth keeping: alongside the usual generic header findings, a completely
unrelated rule — a generic filesystem-path-disclosure check — independently flagged the same response,
because it literally contains an absolute path string. Different rule, different reasoning, same
underlying bug — a nice bit of corroborating evidence that cost nothing extra to collect.

Step 8 — A fully offline explanation

With the manually-filed finding's evidence in place, a local LLM generates a plain-language narrative from
it: something like "A hand-rolled XML entity resolver reads an attacker-specified file path from a SYSTEM
entity with no restriction, allowing disclosure of arbitrary files readable by the server process." No
network call is made — and this works identically whether a finding was auto-created by a rule or filed by
hand, since the narrator only ever reads the finding's own fields, never its provenance.

The fix

The demo's own bug is a hand-rolled resolver that never should have resolved external entities in the
first place — the fix isn't a configuration flag here, it's refusing to read SYSTEM identifiers at all:

function resolveEntities(xml) {
  if (/<!DOCTYPE/i.test(xml)) {
    throw new Error('DOCTYPE declarations are not permitted in submitted XML');
  }
  return xml; // no external entities are ever resolved
}

For a real XML parser, the equivalent is a configuration setting rather than a rewrite: disable DTD
processing and external-entity resolution outright (most real parsers have an explicit
disallow-doctype-decl / "external entities off" setting — e.g. libxmljs's parseXml(xml, { noent: false, dtdload: false, dtdvalid: false }), or Node's fast-xml-parser with processEntities: false), or
use a parser that doesn't support DTDs at all for untrusted input — verbatim the fix the demo app's own
README.md suggests.

What's honestly not covered

This is the starkest version of "not covered" in the whole series: no static match, no dynamic/business-
logic match, no Active Test probe at all. That's not three separate failures — it's one honest gap,
demonstrated on camera at every layer rather than glossed over. The static rule's precision (it targets a
real library's real API, just not this app's) is actually the most reassuring part: it isn't guessing,
it's correctly scoped, and this app simply falls outside that scope by design.

Try it yourself

The target app and the full step-by-step playbook (every click, every payload, every panel, plus the exact
reasoning behind each "no finding" result) are linked below if you want to reproduce this end-to-end
against your own local copy.

This is an intentionally vulnerable local training app. Never run these techniques against a
system you don't own or don't have explicit written authorization to test.

Try it yourself → https://github.com/sendwavehub/scan-target-demo-apps
Windows Store https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US
Web Site https://Sendwavehub.tech/en/apps/ai-security-studio-4

Server-Side Request Forgery (CWE-918): From Auto-Detected Finding to Live Exploit to an Honest Tooling Gap — Fully Offline

jomynn — Tue, 01 Sep 2026 04:47:35 +0000

A full walkthrough of finding, proving, and reporting a real SSRF bug with a deterministic rule engine, a live form-based exploit, an attempted (and explained) automated probe, and a fully offline local LLM — no cloud AI anywhere in the pipeline.
tags: security, javascript, node, webdev

One form field. One "internal-only" endpoint that was never supposed to be reachable. Here's the
full story of a real CWE-918 (Server-Side Request
Forgery) vulnerability, from the moment a rule engine flags it, through a form-only live exploit, to
an honest look at where the platform's own automated probe hits a real limit — all running locally,
with no cloud AI anywhere in the pipeline.

The vulnerable code

The target is a deliberately vulnerable local training app: a "URL preview" tool that fetches
whatever URL you give it, server-side.

app.post('/preview', async (req, res) => {
  const { url } = req.body;
  if (!url) return res.status(400).json({ error: 'url is required' });
  const upstream = await fetch(url, { redirect: 'follow' }); // BUG: no host/scheme allowlist
  const text = await upstream.text();
  res.json({ url, status: upstream.status, body: text.slice(0, 2000) });
});

url comes straight from the request body and goes straight into fetch() — no allowlist on scheme
or destination host. The same server also exposes /internal/admin-status, an "internal-only"
endpoint that isn't linked from any page and simulates something like a cloud-metadata endpoint or an
admin panel. /preview can reach it anyway — and because the response body gets reflected straight
back to the caller, this isn't blind SSRF: the internal endpoint's own flag comes back in the JSON,
a self-contained proof with nothing but a form submission.

Step 1 — A deterministic rule engine catches it, not an LLM

Before any AI touches this finding, the same taint-tracking rule that flags command injection and
path traversal also declares an outbound-request sink, and walks the exact shape this bug takes:

const { url } = req.body     →  source: untrusted request value
fetch(url, …)                 →  sink: outbound HTTP request

One static scan raises a High, CWE-918 finding automatically — zero manual finding-creation,
zero guesswork. The finding already carries:

Evidence — the matched source line, with the exact column of the injection point pinned inside the tainted expression
Risk Level — High
Security Reference — CWE-918 / OWASP A10:2021 (Server-Side Request Forgery)

The rule engine discovers; the LLM only ever explains an already-verified finding afterward. It
never gets to invent a vulnerability on its own.

Step 2 — Proving it live, with zero extra tooling

The form field is prefilled http://localhost:3007/internal/admin-status. Submitting it returns:

{
  "url": "http://localhost:3007/internal/admin-status",
  "status": 200,
  "body": "{\"internal\":true,\"message\":\"This endpoint should only ever be called by trusted internal callers.\",\"fakeSecret\":\"FLAG{ssrf-reached-internal-endpoint}\"}"
}

body proves the server, not the browser, reached an endpoint that "isn't linked anywhere and isn't
meant to be reachable from outside this server." One request/response pair is already enough evidence
on its own — no server access needed to confirm the bug, because the app's own response is externally
observable proof.

Step 3 — Escalating the payload (and what a rejection does and doesn't prove)

The request body is application/x-www-form-urlencoded, but the payload itself has no &/=
characters, so none of command injection's body-splitting trap applies here — values load and send as
typed:

Payload	What it proves
`url=http://127.0.0.1:3007/internal/admin-status`	Loopback literal instead of `localhost` — same flag comes back
`url=http://[::1]:3007/internal/admin-status`	IPv6 loopback — a third distinct way into the same endpoint, ruling out a naive hostname-string allowlist
`url=file:///etc/passwd`	Rejected with a 502 — but by Node's own `fetch` (undici), which only supports `http`/`https`. That's a runtime-level restriction, not an application-level allowlist, and shouldn't be mistaken for one in a write-up

Three host variations, one important negative result — and the negative result is worth writing up
carefully instead of skipping past it.

Step 4 — Attempting the platform's own Active Test probe — and explaining why it can't confirm this one

The platform does have a real, wired SSRF probe — a GUI checkbox and a CLI flag, backed by an
offline, local out-of-band collaborator (no third-party service, no internet). I set one up and ran
it against /preview's url parameter anyway, on camera, rather than just asserting it wouldn't
work.

It came back with no finding — and the reason is architectural, not a fluke: the probe always injects
its callback URL via a GET query string (ActiveTestUrls.WithQueryParameter, sent through a
GET-only client call). This app's vulnerable parameter exists only on POST /preview's form
body — there's no GET /preview route at all, so the probe's request 404s before the server ever
calls fetch(). No collaborator misconfiguration, no false negative on the app's actual exposure —
just a probe that was built for a different injection channel than this specific endpoint uses.

Two findings would have been the tidy outcome. One finding plus a documented, code-level reason for
why the second attempt didn't land is the honest one.

Step 5 — A fully offline explanation

With the static evidence and the manual proof both attached to the same finding, a local LLM
generates a plain-language narrative from the structured evidence: something like "Untrusted input
reaches an outbound fetch() call with no host/scheme allowlist, letting the server be used to reach
its own internal-only endpoints." No network call is made. The model reasons over an
already-verified finding; it doesn't discover anything new.

Step 6 — The fix

const ALLOWED_HOSTS = new Set(['api.trusted-partner.example']);

app.post('/preview', async (req, res) => {
  const { url } = req.body;
  let target;
  try {
    target = new URL(url);
  } catch {
    return res.status(400).json({ error: 'invalid url' });
  }
  if (!['http:', 'https:'].includes(target.protocol) || !ALLOWED_HOSTS.has(target.hostname)) {
    return res.status(400).json({ error: 'destination not allowed' });
  }
  const upstream = await fetch(target, { redirect: 'manual' }); // no automatic redirect to an unchecked host
  res.json({ url, status: upstream.status });
});

Allowlist the destination hosts and schemes, resolve and re-validate the actual address before
connecting (reject loopback/link-local/private ranges), turn off automatic redirect-following (or
re-validate the redirect target), and isolate the fetcher's own network egress as defense in depth.

What's honestly not covered

The Active Test tab's SSRF probe is real, wired, and wouldn't be a no-op against every SSRF bug —
just this specific POST-body-only shape. That's a narrower gap than command injection's "no GUI/CLI
entry point at all," but it's still a gap, and I'd rather show it failing on camera with the reason
attached than imply the platform caught two independent confirmations here when it only caught one.

Try it yourself

The target app and the full step-by-step playbook (every click, every payload, every panel) are
linked below if you want to reproduce this end-to-end against your own local copy.

This is an intentionally vulnerable local training app. Never run these techniques against a
system you don't own or don't have explicit written authorization to test.

Path traversal caught two ways — static analysis and a live probe, no cloud AI

jomynn — Sat, 29 Aug 2026 08:43:05 +0000

The bug

Here's the route from a small Express demo app
(scan-target-demo-apps/apps/06-path-traversal):

app.get('/files', (req, res) => {
  const name = req.query.name;
  const filePath = path.join(docsDir, name);
  fs.readFile(filePath, 'utf8', (err, data) => {
    if (err) {
      return res.status(404).json({ error: 'file not found', path: filePath });
    }
    res.type('text/plain').send(data);
  });
});

name comes straight from the query string and goes straight into path.join() — no check that the
resolved path actually stays inside docsDir. path.join('./docs', '../secret.txt') happily
resolves to a file outside ./docs. Request /files?name=../secret.txt and the server reads and
returns whatever's sitting one directory above the one it's supposed to be confined to.

Classic CWE-22, OWASP A01:2021 (Broken Access Control). Nothing novel in the bug itself — the
interesting part, again, is what caught it and how many independent ways.

What actually caught it — twice, independently

We ran this target through AI Security Studio, an offline security research platform we've been
building. No cloud calls, no code leaves the machine.

This is the first target in the series where the bug is confirmed by both ends of the pipeline
at once, not just one:

1. Static — before anyone opens the app. The same JavaScript taint rule that flags command
injection also declares a filesystem sink: fs.readFile / readFileSync / writeFile /
.sendFile(, etc. It traces req.query.name → path.join(docsDir, name) → fs.readFile(filePath, …) entirely inside server.js, and auto-creates a finding — Risk: High, CWE-22, OWASP A01:2021 —
with zero manual steps. This scores reachability: untrusted input reaches a filesystem sink.

2. Dynamic — a live, automated probe. Unlike some other bug classes in this series where the
active-probe side isn't wired up yet, path traversal has a real, on-by-default probe
(PathTraversalProbeAdapter, ProbeSafetyTier.ReadOnly). Point it at /files with parameter name
and run it: it comes back with a Critical finding, Confidence: Likely, and — the part that
usually takes a human write-up — an attached, ready-to-run curl reproduction already generated. This
scores confirmed exploitation, which is why it lands at a higher risk level than the static-only
finding for the same root cause. Different numbers for the same bug at different pipeline stages is
expected, not a bug in the platform.

Proving it by hand needs nothing but a browser, too — no tooling required:

GET /files?name=../secret.txt

returns the contents of secret.txt, a file that lives one directory above the app's intended
./docs root and was never meant to be reachable through /files at all.

Why "offline" is the actual point

You can point this at unreleased/internal code without a vendor's cloud pipeline ever touching it.
The rule engine and the active-test probe — not the LLM — do the actual finding and the actual exploitation. Results are reproducible and don't drift between runs.
The local LLM's job shrinks to something it's actually reliable at: turning the already-structured evidence (the tainted source line, the curl proof, the CWE/OWASP references) into a plain-language explanation — "untrusted input reaches a filesystem read via unsanitized path.join, allowing arbitrary file disclosure outside the intended directory." No raw request/response bodies, no raw source files, ever get handed to the model directly.

Try it yourself

The demo app is intentionally vulnerable and open source — safe to point any scanner at, including
this one:

Video walkthrough:

Built for security researchers, pentesters, and AppSec teams doing work they're authorized to do.

Command Injection (CWE-78): From Auto-Detected Finding to Live Exploit to Fixed — Fully Offline

jomynn — Thu, 27 Aug 2026 09:53:43 +0000

One tainted variable. One shell on the host. Here's the full story of a real
CWE-78 (OS Command
Injection) vulnerability, from the moment a rule engine flags it to a
disclosure-ready report — all running locally, with no cloud AI anywhere in
the pipeline.

The vulnerable code

The target is a deliberately vulnerable local training app: a tiny "network
diagnostics" tool that pings a host you give it.

app.post('/ping', (req, res) => {
  const host = req.body.host || '127.0.0.1';
  const cmd = `ping -c 1 ${host}`; // BUG: unsanitized string concatenation
  exec(cmd, { timeout: 5000 }, (err, stdout, stderr) => {
    res.json({ cmd, stdout, stderr, error: err ? err.message : null });
  });
});

No validation. No escaping. No argument array — just user input flowing
straight into a shell. And because the JSON response echoes back the exact
cmd string the server built, the vulnerable string is visible in every
response, not just the source — one of the cleanest bugs you'll ever capture
airtight evidence from.

Step 1 — A deterministic rule engine catches it, not an LLM

Before any AI touches this finding, a taint-tracking static analysis rule
walks the exact shape this bug takes:

const host = req.body.host …    →  source: untrusted request value
const cmd  = `ping -c 1 ${host}`  →  assignment: taint propagates through host → cmd
exec(cmd, …)                     →  sink: child_process.exec

One static scan raises a Critical, CWE-78 finding automatically —
zero manual finding-creation, zero guesswork. The finding already carries:

Evidence — the matched source line, with the exact column of the injection point pinned inside the tainted expression
Risk Level — Critical
Security Reference — CWE-78 / OWASP A03:2021 (Injection)

The rule engine discovers; the LLM only ever explains an already-verified
finding afterward. It never gets to invent a vulnerability on its own.

Step 2 — Proving it live, with zero extra tooling

The form field is prefilled 127.0.0.1; id. Submitting it returns:

{
  "cmd": "ping -c 1 127.0.0.1; id",
  "stdout": "PING 127.0.0.1 ...\nuid=501(demo) gid=20(staff) groups=...\n",
  "stderr": "",
  "error": null
}

cmd proves the server built exactly the string you'd expect from unescaped
concatenation. stdout proves it further — after the ping output, a
uid=…gid=… line: the output of id, a command nobody asked the app to
run. One request/response pair is already enough evidence on its own — no
server access needed to confirm the bug, because the app's own response is
externally observable proof.

Step 3 — Varying the payload (and why encoding matters)

A quick gotcha worth calling out for anyone testing this class of bug by
hand: the request's Content-Type is application/x-www-form-urlencoded,
so a literal host=127.0.0.1 && whoami gets split by the form parser on the
raw & before the payload ever reaches host — the metacharacter never
survives. Percent-encode it instead:

Payload	Encoded body
`127.0.0.1 && whoami`	`host=127.0.0.1%20%26%26%20whoami`
`127.0.0.1 \	uname -a`
`id` (substitution)	`host=%60id%60`

Four independent shell metacharacters (;, &&, |, `), four
independent proofs that this reaches a real shell — not one lucky payload.

Step 4 — A fully offline explanation

With the static evidence and the live proof both attached to the same
finding, a local LLM generates a plain-language narrative from the
structured evidence — something like "Untrusted input reaches
child_process.exec via string concatenation — full remote code
execution." No network call is made. The model reasons over an
already-verified finding; it doesn't discover anything new.

Step 5 — The fix

const { execFile } = require('node:child_process');

app.post('/ping', (req, res) => {
  const host = req.body.host || '127.0.0.1';
  execFile('ping', ['-c', '1', host], { timeout: 5000 }, (err, stdout, stderr) => {
    res.json({ stdout, stderr, error: err ? err.message : null });
  });
});

execFile with an argument array means there's no shell to interpret in the
first place — host is passed as a literal argument, never concatenated
into a command string. Add strict input validation on host (e.g. an
IP/hostname allow-list pattern) as defense in depth.

What's honestly not covered

Two active-exploitation probes for this bug class exist in the platform's
engine, but neither is currently wired to a GUI checkbox or CLI flag — so
dynamic confirmation via automated active testing isn't possible today for
this specific bug. That's exactly why this walkthrough proves the exploit
by hand instead of relying on tooling that isn't there yet. Calling out
tooling gaps honestly matters more to me than pretending coverage is
complete.

Try it yourself

The target app and the full step-by-step playbook (every click, every
payload, every panel) are linked below if you want to reproduce this
end-to-end against your own local copy.

This is an intentionally vulnerable local training app. Never run these
techniques against a system you don't own or don't have explicit written
authorization to test.

Manually Breaking Authentication — A Full Walkthrough (CWE-307, CWE-330, CWE-640)

jomynn — Wed, 26 Aug 2026 06:14:15 +0000

A fully manual security assessment of three broken-authentication bugs — no scanners, just a proxy-backed browser and raw HTTP evidence, mapped end-to-end to CWE and OWASP.

⚠️ Educational / authorized testing only. Everything below targets a local, deliberately vulnerable training application, not a live system. Never run these techniques against anything you don't own or don't have explicit written authorization to test.

Automated scanners are great at pattern-matching known vulnerability classes. They're much weaker at authentication flaws that look completely legitimate at the HTTP level — a 200, a 401, a token — and only become a bug once you understand how the value was generated. This walkthrough is a fully manual assessment of three such bugs in a deliberately vulnerable login system, captured start to finish with nothing but a proxy-backed browser and a network tab.

The bugs

#	Bug	CWE	OWASP
1	`POST /login` has no rate limit, delay, or lockout	CWE-307	A07:2021 – Identification and Authentication Failures
2	Session tokens are sequential integers, not random	CWE-330	A07:2021
3	Password-reset token is `md5(username)` — deterministic, not random or single-use	CWE-640	A07:2021

Phase 1 — No brute-force protection

Three wrong passwords for admin, back to back, then the real one. All four POST /login requests return instantly — no 429, no CAPTCHA, no increasing delay. Filtering the network tab down to login shows the whole sequence sitting there in plain sight: nothing on the server side ever notices the repetition.

That's the entire proof for CWE-307. A real attacker isn't limited to four guesses — they're limited by whatever rate their network connection allows, because the server places no limit of its own.

Phase 2 — Predictable session tokens

The login endpoint hands out tokens from a shared, incrementing counter — regardless of which account is logging in. alice gets 1001. bob gets 1002. That's already suspicious, but the real proof of impact is this: clear your cookies, open a private window, and request /whoami?session=1001 with zero credentials. The server hands back alice's full identity, because "knowing a number" and "being alice" are treated as equivalent.

Phase 3 — A reset token that isn't a secret

/reset-token?username=alice returns a 32-character hex string that looks random — until you request it again and get the exact same value back. It's not a secret; it's md5("alice"), a pure function of public data. Anyone who knows a username can compute their "reset token" offline, with no server interaction and no account access at all.

From evidence to finding

Each bug was routed from the network capture into a manual finding — evidence field populated with the actual request/response pairs, CWE and OWASP mapping attached, and a concrete fix:

Finding A (Medium) — add per-account and per-IP throttling with exponential backoff or lockout, plus a CAPTCHA after repeated failures.
Finding B (High) — issue tokens from a cryptographically secure random source (128+ bits), never a counter.
Finding C (High) — generate a random, single-use, time-limited reset token, stored server-side and delivered only to the account's verified contact method.

Takeaway

None of this required exploit tooling — it required patience, a network tab, and the discipline to capture evidence before writing a single conclusion. Scanners are excellent at known-signature bugs; deterministic secrets and predictable state are exactly the class of finding that still needs a human reading raw traffic.

What's the last "boring" auth bug your team caught that a scanner missed? Curious to hear how others are covering this gap.

Manually Proving and Documenting an IDOR (CWE-639) — A Full Walkthrough

jomynn — Mon, 24 Aug 2026 13:01:03 +0000

Most IDOR write-ups stop at "change the ID in the URL and you get someone else's data."
That's the easy part. The part that actually matters — proving it rigorously, ruling out
the boring explanation, and turning it into a report someone can act on — usually gets
skipped.

I recorded a full walkthrough doing exactly that, end to end, against a deliberately
vulnerable local training target.

The bug

A simple invoice endpoint, GET /invoices/:id. It checks that someone is logged in
(401 if not), but never checks that the logged-in identity actually owns the invoice
it's returning:


js
`invoices.find(inv => inv.id === Number(req.params.id))
// no invoice.owner === session.user check`


Log in as any user, change the number in the URL, read anyone's invoice. Classic
CWE-639 — Authorization Bypass Through User-Controlled Key, and it maps directly to:

OWASP A01:2021 — Broken Access Control
API1:2023 — Broken Object Level Authorization (BOLA)

**What the walkthrough actually covers**
The video isn't just "look, it's broken" — it's the full evidence chain a real assessment
needs:

Timestamp   Phase
0:00    Capture two separate identities (alice, bob)
1:26:19 Prove cross-owner access live, in-browser
2:06:26 Pull raw request/response evidence from the network tab
2:52:04 Run a negative control — unauthenticated request, confirm 401
4:08:06 Confirm independently with an automated IDOR probe
6:12:03 Create a structured finding (CWE/OWASP/API mapping + evidence)
8:12:07 Structure the evidence for review
10:29:00    Export a report
The negative control is the step people skip most often, and it's the one that separates
"broken access control" from "there's just no auth at all" — an important distinction if
you're writing this up for a real triager.

**Why the control matters**
Without it, you've only shown that an authenticated user can read someone else's data —
you haven't ruled out the (much less interesting) possibility that the endpoint has no
auth check whatsoever. Hitting the same endpoint with zero session and getting a clean
401 proves the app does enforce authentication — it just never enforces ownership.
That's the difference between a one-line "missing auth" bug and a systemic
authorization-model gap.

**Fix**
Load the object, then check ownership before returning it:

`const invoice = invoices.find(inv => inv.id === Number(req.params.id));
if (!invoice || invoice.owner !== session.user) {
  return res.status(404).end(); // or 403 — avoid leaking existence via 401 vs 403
}`

Every object access needs to be authorized, not just authenticated — that's the whole bug
in one sentence.

Try it yourself → https://github.com/sendwavehub/scan-target-demo-apps
Windows Store https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US
Web Site https://Sendwavehub.tech/en/apps/ai-security-studio-4

Building an Offline AI Security Scanner That Doesn't Hallucinate Findings

jomynn — Sat, 22 Aug 2026 06:47:26 +0000

How AiSec Studio pipes every scan through parser → rule engine → knowledge graph before a local LLM ever sees it — and why that order matters. 60-second Auto Scan demo included.

Most "AI-powered" security scanners work the same way under the hood: grab the target's code or HTTP responses, stuff them into an LLM prompt, and ask it to find vulnerabilities. It demos well. It also hallucinates constantly — the model pattern-matches on plausible-looking code and reports things that were never exploitable, or never there at all.

I've been building AiSec Studio, an offline AI security research platform, around the opposite assumption: the LLM should never be the thing that discovers a vulnerability. It should only reason over what a deterministic system already found.

Here's a 60-second walkthrough of the Auto Scan lane — target URL in, reviewed report out — followed by how the pipeline behind it is actually built.

The pipeline

Parser → Rule Engine → Knowledge Retrieval → Summarization → LLM → Reasoning → Finding → Report

Every stage exists to keep the model away from raw, untrusted input and away from the job of deciding something is a vulnerability.

1. Parse before you analyze

Before any AI touches a target, the code goes through Roslyn (for .NET) or Tree-sitter (everything else) to extract:

AST
Call graph / dependency graph
Controllers, services, routes
Authentication and authorization wiring
Configuration

This is the same reason a compiler front-end exists before an optimizer runs — you don't want probabilistic reasoning operating on unstructured text when a deterministic parser can hand you a structured graph instead.

2. Rule engine does the actual discovering

Vulnerability discovery is a deterministic-rules job, not an LLM job:

Secret detection
JWT validation (including algorithm-confusion, CWE-347)
Header / cookie / CSP / CORS analysis
SQL and XSS pattern detection
Dependency and configuration analysis

None of this requires a model. It requires correct rules, and it's auditable — you can point at exactly which regex or AST pattern fired for a given finding.

3. Everything lands in a per-engagement Knowledge Graph

Pages, APIs, JS bundles, auth flows, technologies, and findings all get cross-linked by canonical route into one persistent graph per engagement. This is what lets risk propagate — a leaked JWT secret on one endpoint and an IDOR on a related endpoint aren't two isolated findings, they're connected nodes with compounding risk.

It also means re-scanning is incremental: unchanged parts of the graph don't get re-analyzed.

4. The LLM only reasons over structured summaries — never raw input

This is the boundary that matters most. The local LLM (Qwen2.5-Coder or DeepSeek-Coder, served through Ollama or llama.cpp — no cloud API, ever, at any point) is only handed:

Structured summaries from the rule engine + knowledge graph
Never raw HTTP responses
Never raw bundles
Never raw source dumped wholesale

Its job is explanation and correlation: why does this finding matter, what's the business impact, which of these twelve findings should a human look at first, how should the final report read. It doesn't get to originate a finding out of nothing, because it never sees anything a finding could be originated from.

5. Confidence tiers instead of confident-sounding guesses

Every finding is tagged:

Confirmed
Likely
Possible
Hypothesis

If the evidence doesn't support any of those, the system returns "Needs Manual Verification" instead of inventing a conclusion. A finding without evidence, reasoning, a confidence score, a risk level, and a suggested fix isn't a finding — it's a guess wearing a report template.

What the demo actually shows

Mapped to the pipeline above, the video is:

Auto Scan panel — set the target URL
Scan Anonymously — passive discovery only, rule-engine + parser stage
Scan All — runs discovery → analysis → active testing end to end
Investigate → Finding Report — step through findings one by one, each with its evidence and confidence tier attached
Report → Markdown — export the write-up
Open Report — hand it straight to the OS's default viewer

Nothing in that flow leaves the machine. No target data, no code, no findings go to a cloud API at any point — that's a hard architectural constraint, not a configuration toggle.

Try it yourself: https://github.com/sendwavehub/scan-target-demo-apps
Free download: https://apps.microsoft.com/store/detail/9PJ0J7BK1M27?cid=DevShareMCLPCB

Web download:
https://sendwavehub.tech/th/apps/ai-security-studio-4

We caught a SQL injection with an offline AI security scanner — here's the exact query it found

jomynn — Thu, 20 Aug 2026 13:57:45 +0000

The bug

Here's a login endpoint from a small Express demo app
(scan-target-demo-apps/apps/01-sql-injection):

app.post('/login', (req, res) => {
  const { username = '', password = '' } = req.body;
  const query = `SELECT id, username, email, is_admin FROM users
                  WHERE username = '${username}' AND password = '${password}'`;
  const result = db.exec(query);
  // ...
});

You've seen this shape before. username and password go straight into the SQL string — no
parameter binding, no escaping. Submit admin' -- as the username and anything as the password,
and the query becomes:

SELECT id, username, email, is_admin FROM users
WHERE username = 'admin' -- ' AND password = 'anything'

-- comments out the rest of the line. The password check never runs. {"ok": true}, logged in
as admin.

Classic CWE-89, OWASP A03:2021. Nothing novel here — the interesting part is what caught it.

What actually caught it

We ran this target through AI Security Studio, an offline security research platform we've
been building. No cloud calls, no code leaves the machine — everything you're about to read
happened on a laptop with no network access to anywhere but localhost:3001.

The important design decision: the LLM never sees raw source code or raw HTTP traffic.
The pipeline looks like this:

Parser → Rule Engine → Knowledge Retrieval → Summarization → LLM → Reasoning → Finding → Report

A deterministic parser and rule engine do the actual finding. The local LLM only explains
already-discovered evidence — it's not asked to eyeball a codebase and guess where the bugs
might be. If the evidence isn't there, the platform is built to say "Needs Manual Verification"
instead of inventing a conclusion.

For this run, that meant:

Point the scanner at http://localhost:3001 as scope.
Let it run a real passive crawl — no exploitation, just discovery.
Run a source scan against the target's own directory.
The rule engine flags the string-concatenated query pattern in server.js:56 and the missing auth check on the state-changing POST /login route.

The generated report includes the actual vulnerable line as evidence, not a generic "possible SQL
injection" label:

Source preview.
  app.post('/login', (req, res) => {
    const { username = '', password = '' } = req.body;
    const query = `SELECT id, username, email, is_admin FROM users WHERE username = '${username}' AND password = '${password}'`;

Risk: High. Root cause: CWE-89 (and a separate CWE-306 finding for the missing authorization
check). Suggested fix: parameterized queries. Confidence explicitly marked — some findings from
this pass are "Confirmed," others are flagged "Needs Manual Verification" rather than asserted,
because header/config-level evidence alone doesn't prove exploitability the way a manual
Active Test / Repeater run does.

Why "offline" is the actual point

It's easy to gloss over "runs locally" as a checkbox feature. In practice it means:

You can point it at unreleased/internal code without a vendor's cloud pipeline ever touching it.
The rule engine — not the LLM — does secret detection, JWT/header/cookie analysis, and pattern matching, so results are reproducible and don't drift between runs.
The LLM's job shrinks to something it's actually reliable at: turning structured findings into a clear explanation, not hunting for vulnerabilities in raw text.

Try it yourself

The demo app is intentionally vulnerable and open source — safe to point any scanner at, including
this one:

Demo target: https://github.com/sendwavehub/scan-target-demo-apps
AI Security Studio: https://apps.microsoft.com/store/detail/9PJ0J7BK1M27?cid=DevShareMCLPCB

SendWaveHub — Hire AI Employees for Your Business Email

AI Employees that read, process, and respond to your business email. AI Accountant live now — email marketing, eSign, PDF tools, and automation included. Free plan.

sendwavehub.tech

Built for security researchers, pentesters, and AppSec teams doing work they're authorized to do.

Next up in this series: stored XSS — one comment field, every visitor who loads the page.

We Built a Security Scanner That Automates Itself — and Never Touches the Cloud

jomynn — Tue, 18 Aug 2026 07:51:55 +0000

How AI Security Studio's ASS Script engine lets you record, replay, and narrate a full offline security scan — deterministic analysis first, local LLM reasoning second.
Most "AI-powered" security tools have the same dependency: your code has to leave your machine to get an answer. That's a non-starter for a lot of security research — client engagements under NDA, regulated codebases, or just not wanting proprietary source sitting in someone else's inference logs.

AI Security Studio is built the other way: everything runs locally. Local LLM (Ollama / llama.cpp / LM Studio), no external API calls, no telemetry. This post walks through one specific piece of it — the automation engine we call ASS Script — and the small offline pipeline I built on top of it to generate narrated, subtitled walkthrough videos without touching a cloud TTS API either.

Deterministic first, LLM second

Before any AI touches a finding, it goes through:

Parser → Rule Engine → Knowledge Retrieval → Summarization → LLM → Reasoning → Finding → Report

Static parsing (Roslyn / Tree-sitter) and a deterministic rule engine — secret detection, header analysis, JWT validation, SQLi/XSS pattern matching — do the actual discovery. The LLM never sees raw source. It only reasons over structured summaries the rule engine already produced: explaining why something is a bug, correlating findings, drafting the writeup. If the evidence isn't solid, the system is designed to say "needs manual verification" rather than invent a conclusion.

Record once, replay forever

ASS Script (AI Security Studio Automation Script) is an iMacro-style record/play/edit engine built on the same node-graph designer used elsewhere in the app. Scripts are plain YAML — readable and diffable, not an opaque macro blob:


yaml
nodes:
  - id: "n5"
    kind: "GuiInteract"
    title: "Click Find bugs on this URL"
    notes: "Imports the URL as a one-host scope. Scope import only — sends no network traffic by itself."
    parameters:
      control: "ScanUrlButton"
      action: "click"
  - id: "n9"
    kind: "GuiInteract"
    title: "Click Scan All"
    notes: "Kicks off the panel's real passive sweep — genuinely live crawl traffic, same as a human operator would trigger."
    parameters:
      control: "ScanAllButton"
      action: "click"
  - id: "n14"
    kind: "RunScan"
    title: "Live source scan"
    notes: "Runs the real ScanService against the target's own source directory — footage shows a real scan, not a mockup."
    parameters:
      path: "/path/to/target/source"
Each node is a real GUI action or a real scan/analyzer call — no simulated steps. You record a workflow once, then replay it identically from the GUI or the CLI (workflow run some-script.adrflow.yaml).

The fun side quest: offline narration for the demo videos
We wanted walkthrough videos with voiceover and subtitles, but the "generate subtitles" step usually means uploading video/audio to a cloud transcription or TTS API — which would be a little embarrassing for a project whose whole pitch is "nothing leaves your machine."

So the pipeline is: write the shot list as a markdown table (beat / timecode / on-screen action / caption / VO line), then run it through a small Python script that:

Parses the table into timed cues
Synthesizes each VO line with macOS's built-in say (fully offline TTS)
Measures each clip's real duration with ffprobe
Concatenates them into one narration track with ffmpeg
Emits a .srt timed to the actual synthesized audio, not a guess
Flags any beat where the narration runs longer than the video's planned window, so you know exactly where to hold a shot longer
The output is a narration.wav + captions.srt pair generated entirely from tools already on the machine — no API keys, no cloud dependency, same philosophy as the scanner itself.

Why this matters beyond the demo video
The pattern generalizes: treat the LLM/AI step as optional and swappable, put the deterministic and local-first parts first. It's true for the security pipeline (rule engine before LLM) and it turned out to be just as true for the tooling around the project (offline TTS before cloud TTS). If your architecture assumes "AI" every time it actually means "network call," that's worth questioning.

🛡️ NPM Safety Guard — All 23 Security Layers Explained

jomynn — Mon, 29 Jun 2026 06:20:23 +0000

Every npm project is one malicious package away from a supply-chain breach. NPM Safety Guard catches threats that npm audit completely misses — from DPRK backdoors and typosquatted packages, to exposed API keys and AI credential theft hidden inside your node_modules.

This video walks through all 23 detection layers, one by one, showing exactly what each layer catches and how it protects your project in real time.
🛡️ Intro
NPM Safety Guard is the most comprehensive npm security scanner for developers. It ships as a VS Code extension (also works in Cursor and Windsurf) and a JetBrains plugin (WebStorm, IntelliJ IDEA, and all IntelliJ-based IDEs). It runs silently in the background and alerts you to supply-chain threats, malware, CVEs, and credential leaks — before they can cause damage.

Layer 1 — Known Malicious Packages
Checks every package in your package.json against a bundled database of documented supply-chain attacks, including DPRK/Lazarus Group backdoors, the infamous event-stream compromise, and dozens of other confirmed malicious packages. The database is also synced against a live remote feed so newly discovered threats are caught even before you update the extension.

Layer 2 — CVE Vulnerabilities
Queries the Google OSV.dev API for known CVEs across all your direct dependencies. No API key needed — it is completely free. Results are cached for 24 hours to minimize network calls. CVSS scores are mapped to severity levels (Critical, High, Medium, Low) so you always know exactly how serious each vulnerability is and which version fixes it.

Layer 3 — Install Script Hooks
Flags packages that declare preinstall, postinstall, install, or prepare npm scripts. These hooks run automatically during npm install — before any of your own code executes — making them the number one real-world vector for supply-chain malware delivery. Legitimate packages that genuinely need install scripts (like node-gyp and imagemin) are automatically whitelisted.

Layer 4 — Deep Tarball AST Scan
Downloads the actual npm tarball for flagged packages and scans every JavaScript and TypeScript file inside it for 14 malware patterns: eval() with encoded payloads, new Function(), vm.runInNewContext(), child_process spawning, dynamic require() calls, Base64-decoded payloads, zero-width and Zalgo character obfuscation, network exfiltration patterns, self-publication via npm publish, and more. This catches threats that registry metadata alone cannot reveal.

Layer 5 — Typosquatting Detection
Detects three classes of package name attacks entirely offline with no network calls. First, classic typosquatting — misspelled names like recat instead of react — using Damerau-Levenshtein edit distance checked against 250+ top npm packages. Second, homoglyph attacks where Unicode look-alike characters (Cyrillic, Greek) replace Latin letters, making reаct look identical to react on screen. Third, AI hallucination squatting — package names that AI coding assistants commonly invent but that do not actually exist on npm, leaving a gap for attackers to register.

Layer 6 — Dependency Confusion
Identifies internal or private package names that have been planted on the public npm registry. Attackers register a name like @yourcompany/internal-utils on public npm with an inflated version number (e.g., 99.0.0). Because npm resolves the highest semver by default, the malicious public package silently wins over your private registry. This layer detects freshly published packages with inflated versions and near-zero download counts under scopes that should be private.

Layer 7 — Registry Risk Heuristics
Scores each package against a set of behavioral signals pulled from the npm registry. The risk score combines: package age (newly published packages score much higher), number of maintainers, weekly download velocity relative to package age, whether the publisher account matches the listed maintainers (a key account-takeover signal), whether the GitHub organization matches the npm publisher, and whether the unpacked package size is suspiciously large. A single flagged signal is informational; multiple signals together produce a High or Critical rating.

Layer 8 — Lockfile Full-Tree Scan
Expands the complete dependency tree from your lockfile and checks every transitive package — not just the ones listed in your package.json. Supports npm lockfile versions 1, 2, and 3, yarn.lock v1, pnpm-lock.yaml versions 5 through 9, and Bun lockfiles. It also validates that every resolved URL points to the standard npm registry, flagging packages silently pulled from alternative or attacker-controlled registries. The 2018 event-stream attack only worked because the malicious payload was three levels deep in the dependency tree — exactly what this layer is designed to catch.

Layer 9 — Overrides / Resolutions CVE Poisoning
Checks the overrides field (npm) and resolutions field (yarn) in your package.json. These fields are commonly used to force a safe version of a transitive dependency — but they can also accidentally or maliciously pin a vulnerable version that overrides a safe one. Every version pinned in these fields is checked against OSV.dev for known CVEs, exactly like direct dependencies.

Layer 10 — Deprecated Packages
Queries the npm registry for the official deprecation flag on each of your packages. Deprecated packages receive no further security patches — any vulnerability discovered after deprecation will remain permanently unpatched. The alert shows the deprecation message left by the maintainer and, where available, the recommended migration path or alternative package.

Layer 11 — License Compliance
Checks the SPDX license identifier of each package against a configurable deny-list. The default deny-list covers licenses that are incompatible with closed-source commercial software: GPL-2.0, GPL-3.0, AGPL-3.0, and SSPL-1.0. AGPL-3.0 in particular requires you to open-source your entire application if you distribute it or run it as a network service. The deny-list is fully customizable per team via a .nsgrc.json file in the project root.

Layer 12 — Unmaintained Packages
Flags packages that have not received a new publish in longer than a configurable threshold, defaulting to 12 months. Unmaintained packages are a common entry point for supply-chain attacks: threat actors acquire abandoned maintainer accounts through credential stuffing or social engineering, then push malicious updates to packages that still have millions of weekly downloads from years-old package.json files that nobody has touched. The age threshold is fully configurable via npmSafetyGuard.unmaintained.months.

Layer 13 — Phantom Dependencies
Scans your entire workspace source code — all .ts, .js, .tsx, and .jsx files — for import and require() statements referencing packages that are not declared in your package.json. These are called phantom dependencies. They appear to work locally because npm hoists packages into a flat node_modules structure, so a package required by one of your declared dependencies is incidentally available to your code. They break silently in CI pipelines, Docker builds, or whenever the transitive provider is updated or removed.

Layer 14 — OSSF Scorecard
Queries the Open Source Security Foundation Scorecard API for each package's GitHub repository and retrieves a security hygiene score from 0 to 10. The score is based on 18 automated checks including: whether branch protection is enforced, whether pull request reviews are required before merging, whether CI tests run on every commit, whether releases are cryptographically signed, and whether known vulnerabilities are tracked and patched. A low score means the project has weak practices and would be easy for an attacker to compromise. The API is free, requires no key, and results are cached for 24 hours.

Layer 15 — Socket.dev Supply Chain Score
Integrates with the Socket.dev API to retrieve deep behavioral supply-chain intelligence for each package. Socket analyzes packages at the AST level before you install them, flagging unexpected environment variable reads, network calls, shell spawning, obfuscated code, and author-change signals that indicate a possible account takeover. Requires a Socket.dev API key. Results are cached for 6 hours.

Layer 16 — ReversingLabs Spectra Assure
An optional premium integration with ReversingLabs, the same binary analysis platform used by enterprise security teams and government agencies. It provides malware classification, tampering detection (identifying when a published package has been modified after upload — a definitive sign of supply-chain compromise), CVE enumeration with fix availability, and C2 callback detection. A free community tier is available for individual developers.

Layer 17 — npm Provenance Attestations
Checks whether each package has a Sigstore-signed provenance attestation, a feature introduced in npm 9.5 in 2023. A provenance attestation cryptographically links the published package to the exact GitHub repository, commit SHA, and CI workflow run that built it. Without an attestation, there is no proof that the published tarball matches what was in the source code — it could have been built locally, tampered with, or published from a compromised machine.

Layer 18 — Package Upgrade Diff Scanner
When you bump a package version, this layer downloads both the old tarball and the new tarball, runs the full 14-pattern AST scan on each, and reports only the patterns that are newly present in the upgraded version. Patterns that existed in both versions are intentionally suppressed to eliminate noise. This means you see exactly what new capabilities or risks were introduced in the upgrade — eval() that was not there before, a new child_process call, an unexpected HTTP request — and nothing else.

Layer 19 — Supply Chain Graph
Renders an interactive force-directed graph of your entire dependency tree inside a VS Code webview. Every node is color-coded by its highest severity finding: red for Critical, orange for High, yellow for Medium, green for clean. Edges connecting risky packages are highlighted. You can pan, zoom, drag nodes, and search. A statistics overlay shows the total package count and a breakdown by risk level. The graph is truncated at 500 nodes, prioritizing the riskiest packages first.

Layer 20 — MCP Server Config Scanner
Scans Model Context Protocol configuration files across your workspace and home directory — including .cursor/mcp.json, .vscode/mcp.json, and ~/.claude/claude_desktop_config.json — for malicious or typosquatted MCP server packages. MCP servers run as persistent background processes inside AI coding sessions like Cursor and Claude Code. A malicious MCP server can intercept every AI query, read your entire codebase, and exfiltrate any API keys passed to it through the env configuration block.

Layer 21 — AI Config Guard
Scans up to three levels deep inside your node_modules directory for packages that contain code designed to target AI developer tool credentials. Using approximately 20 attack signatures, it detects attempts to read Claude Code settings, Cursor configuration, GitHub Copilot tokens, and 1Password CLI credentials, followed by exfiltration patterns like unexpected network calls carrying the stolen data. This layer addresses an emerging class of supply-chain attack specifically targeting the AI-assisted development workflow.

Layer 22 — Exposed Secrets Scanner
Scans your workspace files for accidentally exposed secrets in .env*, .npmrc, *.pem, *.key, credentials.json, and secrets.json files. Detects over a dozen secret types: AWS access keys, Stripe live keys, GitHub Personal Access Tokens, Slack tokens, Google API keys, SendGrid keys, npm auth tokens, private keys in PEM format, and generic API_KEY, SECRET, TOKEN, and PASSWORD patterns. Severity is escalated to Critical if the file is not listed in .gitignore, because the secret will be committed to your repository on the next git commit. Files like .env.example and .env.sample are never scanned.

Layer 23 — Native Binary Detection
Detects precompiled .node binary files inside npm package tarballs. Native Node.js Addons are compiled C or C++ shared libraries that are loaded directly into the Node.js process. They are completely opaque to JavaScript static analysis tools — none of the 14 AST scan patterns in Layer 4, none of the other JS-based layers, can inspect what a .node binary actually does at runtime. Many legitimate packages use native bindings for performance (image processing, database drivers, cryptography), so findings are flagged as High rather than Critical, with guidance to audit the source code on GitHub and consider whether a pure-JavaScript alternative exists.

⭐ Outro
NPM Safety Guard covers the entire threat surface of the npm ecosystem — from known malware databases and CVEs, through behavioral heuristics and tarball analysis, all the way to AI credential targeting and exposed secrets. Most layers require no API keys and work completely offline. Install it once and your entire team is protected on every project, in every file, on every save.

Available free on the VS Code Marketplace (ext install jomynn.npm-safety-guard) and the JetBrains Marketplace. Open source under the MIT license. Built by SendWaveHub.

🔧 INSTALL

VS Code / Cursor / Windsufl:
Search "NPM Safety Guard" in the Extensions panel, or run:
ext install jomynn.npm-safety-guard

JetBrains (WebStorm, IntelliJ IDEA, Rider…):
Settings → Plugins → Marketplace → search "NPM Safety Guard"

🔗 LINKS

VS Code Marketplace → https://marketplace.visualstudio.com/items?itemName=jomynn.npm-safety-guard
JetBrains Marketplace → https://plugins.jetbrains.com/plugin/com.sendwavehub.npmsafetyguard
GitHub (open source, MIT) → https://github.com/jomynn/npm-safety-guard
SendWaveHub → https://sendwavehub.tech

💛 SUPPORT THE PROJECT

⭐ Star the repo on GitHub — it helps more developers discover it
☕ Ko-fi one-off tip → https://ko-fi.com/sendwavehubtech
💖 GitHub Sponsors (recurring) → https://github.com/sponsors/jomynn
🏢 Corporate sponsorship → https://sendwavehub.tech/contact

I built a free IDE extension to catch malicious npm packages before they wreck your project

jomynn — Thu, 18 Jun 2026 10:16:30 +0000

Supply-chain attacks via npm are up year-over-year — packages like event-stream,
the Lazarus group drops, and AI-hallucinated typosquats keep landing in real codebases.
I got tired of finding out after the fact, so I built NPM Safety Guard.

What it does

It scans your package.json and lockfiles right inside your editor — no separate CLI step.

Here's what it currently catches across 22 detection layers:

Known malicious packages — DPRK RAT drops, Lazarus-linked packages, event-stream clones
CVEs — via OSV.dev, cached locally (free, no API key needed)
Typosquatting & homoglyph attacks — catches lodahs, reàct, and AI-hallucinated package names
Install script hooks — flags preinstall/postinstall before you run them
Deep tarball AST scan — detects obfuscation, eval, and payload patterns in the actual source
Dependency confusion — scoped packages planted on public npm to hijack private installs
Exposed secrets — API keys, tokens, private keys accidentally left in .env, .npmrc, .pem
MCP server config scanner — catches typosquatted or malicious MCP transport configs
Supply chain graph — interactive force-directed graph with risk overlay from your lockfile
OSSF Scorecard + Socket.dev score — security hygiene at a glance

Where to get it

VS Code / Cursor / Windsurf → VS Code Marketplace
VS Codium / open-source IDEs → Open VSX Registry
WebStorm / IntelliJ IDEA / all JetBrains IDEs → JetBrains Marketplace

All free. No account required for the core layers. MIT licensed on the VS Code side.

Under the hood

The VS Code extension is TypeScript. The JetBrains plugin is Kotlin. They share the same
detection signatures bundled at build time — no cloud dependency for the core scan.

CVE lookups hit OSV.dev with a 24-hour local cache so you're not waiting on a network
call every keystroke.

Have you been burned by a supply-chain attack before? Or do you have a detection layer
you wish existed? Drop it in the comments — I'm actively adding new signatures.

How We Catch the Axios DPRK RAT — Directly in Your IDE

jomynn — Fri, 22 May 2026 02:26:06 +0000

Published by SendWaveHub · NPM Safety Guard v1.12.0

The Attack

In April 2025, security researchers discovered that axios 1.14.1 — a package with hundreds of millions of downloads — had been briefly replaced on npm with a version containing a Remote Access Trojan (RAT) attributed to DPRK-linked threat actors (the Lazarus Group).

The malicious version was live for a short window. Developers who ran npm install during that window pulled down a backdoor that connected to attacker-controlled infrastructure.

This isn't an edge case. It's the same pattern used in the event-stream attack (2018), ua-parser-js (2021), and dozens of others. Supply chain attacks now account for a significant share of real-world breaches — and they bypass most traditional security tools because the package itself is the attack vector.

The Problem with Existing Tooling

npm audit only catches known CVEs — it doesn't flag malicious payloads injected into legitimate packages. By the time a CVE is filed, the damage may already be done.

OSV.dev, Snyk, and similar tools are excellent at CVE tracking, but they rely on a package being reported and catalogued. A supply chain attack that's live for 48 hours may never make it into those databases in time to protect you.

What NPM Safety Guard Does Differently

NPM Safety Guard is a free VS Code extension that runs 13 detection layers directly in your editor, before npm install even runs.

For the Axios DPRK RAT specifically, it:

Matches against a curated malicious-package database — the bundled DB includes axios@1.14.1, flagged as CRITICAL with the exact version and attack description
Pulls a live remote feed — updated independently of extension releases, so new attacks light up within hours of discovery
Checks OSV.dev in real time — CVEs filed against your installed versions are flagged inline
Audits install hooks — preinstall/postinstall/prepare scripts are flagged before they run, since they're the #1 supply-chain execution vector

Here's what it looks like when axios@1.14.1 appears in your package.json:

🔴 CRITICAL — DPRK RAT (Lazarus Group) — axios@1.14.1
This version was replaced with a Remote Access Trojan.
Safe version: 1.7.9
npm install axios@1.7.9

The warning appears inline, in the Problems panel, and in a full Security Report — all before you've run a single npm command.

The Other 12 Detection Layers

Catching known-malicious packages is the floor, not the ceiling. NPM Safety Guard also detects:

Layer	What it catches
Typosquatting	`lодash` (Cyrillic о), `expres` — packages designed to look like legitimate ones
Dependency confusion	Scoped packages (`@company/pkg`) that have been planted on public npm
Overrides/resolutions poisoning	Teams pin versions to fix a transitive CVE, accidentally pinning to a vulnerable version
Phantom dependencies	Packages your code imports but aren't in `package.json` — fail silently in clean installs
Unmaintained packages	Last release >24 months ago → accumulating unpatched CVEs
Deprecated packages	npm-deprecated packages with auto-upgrade suggestions
Install script audit	Every `preinstall`/`postinstall` hook flagged with package context
OSSF Scorecard	Security hygiene scores from the OpenSSF for each dependency
Socket.dev integration	Supply chain risk scores (requires token)
License compliance	GPL/AGPL in commercial projects
ReversingLabs	Real-time CVE + malware detection (requires free token)
Lockfile scan	Full resolved dependency tree, not just direct deps

Install It Free

The extension is free, open source (MIT), and available on:

VS Code Marketplace
Open VSX (for VSCodium users)

ext install Sendwavehubtech.npm-safety-guard

No API key required for the core features. The malware DB and OSV.dev integration work out of the box.

Why This Matters Now

The Axios attack was caught relatively quickly — but only because it targeted a high-profile package with many eyes on it. The next attack will target a smaller package, with fewer watchers, and stay live longer.

Your best defense is catching the package before it's installed — at the point where you're editing package.json in your editor.

That's exactly what NPM Safety Guard is built for.

Built by SendWaveHub. If this saves your project, consider sponsoring the work.

Tags: security npm javascript devsecops supplychain

DEV Community: jomynn

XML External Entity (CWE-611): The Bug No Automated Layer Catches — Proven and Reported Entirely by Hand, Offline

The vulnerable code

Step 1 — Why the static rule engine stays silent (and that's not a bug)

Step 2 — The dynamic/business-logic path comes back empty too

Step 3 — Proving it live, with nothing but curl

Step 4 — Escalating from scratch, because there's nothing to seed from

Step 5 — Attempting the platform's own Active Test probe — and finding there isn't one

Step 6 — Filing the bug's only finding, by hand

Step 7 — An unexpected second corroboration

Step 8 — A fully offline explanation

The fix

What's honestly not covered

Try it yourself

Server-Side Request Forgery (CWE-918): From Auto-Detected Finding to Live Exploit to an Honest Tooling Gap — Fully Offline

The vulnerable code

Step 1 — A deterministic rule engine catches it, not an LLM

Step 2 — Proving it live, with zero extra tooling

Step 3 — Escalating the payload (and what a rejection does and doesn't prove)

Step 4 — Attempting the platform's own Active Test probe — and explaining why it can't confirm this one

Step 5 — A fully offline explanation

Step 6 — The fix

What's honestly not covered

Try it yourself

Path traversal caught two ways — static analysis and a live probe, no cloud AI

The bug

What actually caught it — twice, independently

Why "offline" is the actual point

Try it yourself

Command Injection (CWE-78): From Auto-Detected Finding to Live Exploit to Fixed — Fully Offline

The vulnerable code

Step 1 — A deterministic rule engine catches it, not an LLM

Step 2 — Proving it live, with zero extra tooling

Step 3 — Varying the payload (and why encoding matters)

Step 4 — A fully offline explanation

Step 5 — The fix

What's honestly not covered

Try it yourself

Manually Breaking Authentication — A Full Walkthrough (CWE-307, CWE-330, CWE-640)

The bugs

Phase 1 — No brute-force protection

Phase 2 — Predictable session tokens

Phase 3 — A reset token that isn't a secret

From evidence to finding

Takeaway

Manually Proving and Documenting an IDOR (CWE-639) — A Full Walkthrough

The bug

Building an Offline AI Security Scanner That Doesn't Hallucinate Findings

The pipeline

1. Parse before you analyze

2. Rule engine does the actual discovering

3. Everything lands in a per-engagement Knowledge Graph

4. The LLM only reasons over structured summaries — never raw input

5. Confidence tiers instead of confident-sounding guesses

What the demo actually shows

We caught a SQL injection with an offline AI security scanner — here's the exact query it found

The bug

What actually caught it

Why "offline" is the actual point

Try it yourself

SendWaveHub — Hire AI Employees for Your Business Email

We Built a Security Scanner That Automates Itself — and Never Touches the Cloud

Deterministic first, LLM second

Record once, replay forever

🛡️ NPM Safety Guard — All 23 Security Layers Explained

I built a free IDE extension to catch malicious npm packages before they wreck your project

What it does

Where to get it

Under the hood

How We Catch the Axios DPRK RAT — Directly in Your IDE

The Attack

The Problem with Existing Tooling

What NPM Safety Guard Does Differently

The Other 12 Detection Layers

Install It Free

Why This Matters Now