DEV Community: jomynn

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

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