i found 7 CVEs in npm packages with 40M+ weekly downloads. here's the tool i used.
i used Claude Opus 4.6 to systematically audit npm packages and found 7 CVEs across mysql2, jsPDF, LiquidJS, Uptime Kuma, and node-forge. the multi-agent framework behind it — pwnkit — is now the closed-source engine powering 0sec.
update — june 2026. pwnkit is no longer open source. after this post, the engine started surfacing kernel-level vulnerabilities, and conversations with researchers at Anthropic, Google, and Intel made it clear that shipping a turnkey kernel-bug finder to the whole internet was too dangerous to keep public. so we closed it. pwnkit is now the private engine behind 0sec — the company i co-founded; an autonomous hacking engine that breaks software to secure it. pwnkit.com now redirects to 0sec.ai, and the public GitHub repo is archived. the CVE story below still stands; treat the install commands and source links as a historical snapshot. foxguard is the open-source piece that stayed open.
in three weeks, i found 7 security vulnerabilities in npm packages downloaded 40 million times a week.
node-forge. mysql2. jsPDF. LiquidJS. Uptime Kuma. all disclosed, all patched, all assigned CVEs.
every finding came from the same process: point an AI agent at source code with a structured methodology. the agent finds potential vulns. a separate agent independently re-exploits each one. if it can't reproduce, the finding gets killed.
after repeating this workflow manually for weeks, i built a framework around it: pwnkit.
here's what i found:
| CVE | package | downloads/week | what i found |
|---|---|---|---|
| CVE-2026-33896 | node-forge | 32M | certificate chain verification bypass — any end-entity cert becomes a CA |
| CVE-2026-33130 | Uptime Kuma | 86k+ stars | SSTI fix bypass via unquoted paths in LiquidJS templates |
| CVE-2026-30952 | LiquidJS | — | path traversal in the require.resolve() fallback (upstream root cause) |
| CVE-2026-31898 | jsPDF | 4M | PDF object injection via unsanitized text streams |
| CVE-2026-31938 | jsPDF | 4M | HTML injection / XSS through the HTML plugin |
| 4 findings | mysql2 | 5M | connection option override, prototype pollution, geometry DoS, OOB read |
every single one was found through the same process — and the same tool.
introducing pwnkit
AI writes the code. pwnkit hacks it.
pwnkit is an agentic harness for autonomous security research. it automates the workflow i used to find those 7 CVEs in packages with 40M+ weekly downloads. point it at an npm package, an LLM endpoint, or a git repo — autonomous agents discover attack surface, run targeted attacks, verify every finding is real, and generate a report.

(historical: at the time, the code was public on GitHub and the CLI shipped on npm. both are now retired — see the june 2026 update above. the engine is closed-source inside 0sec.)
three attack surfaces
pwnkit covers three attack surfaces out of the box:
- LLM endpoints — ChatGPT, Claude, Llama APIs, custom chatbots. prompt injection, jailbreaks, data exfiltration, tool poisoning.
- npm packages — supply chain risks, malicious code, dependency vulnerabilities.
- source code — local repos, GitHub URLs, deep AI-powered audit.
as of v0.3.4, MCP server scanning and web app pentesting are also built into the unified pipeline.
the pipeline
the core idea is a research-then-verify pipeline. a single research agent does discovery, attack, and writes proof-of-concept code. then a separate blind verify agent gets only the PoC and the file path — not the reasoning — and independently tries to reproduce it.
RESEARCH ──> BLIND VERIFY ──> REPORT
(discover, (PoC + path (only confirmed
attack, only — no findings with
write PoC) reasoning) evidence)
research — one agent session that maps the attack surface, crafts multi-turn attacks, and writes working proof-of-concept code. for npm audits, it reads actual source code (not docs), traces data flow from untrusted input to sensitive operations, and identifies patterns: prototype pollution, injection, path traversal, ReDoS, unsafe defaults.
blind verify — the most important step. a separate agent gets ONLY the PoC code and the file path — not the research agent's reasoning. it independently traces the data flow and tries to reproduce the finding. can't reproduce? killed as a false positive. same principle as double-blind peer review.
report — generates SARIF output for GitHub's Security tab, markdown for humans, and JSON for CI pipelines. only confirmed findings with severity scores and remediation guidance.
the blind verification is the differentiator. most security tools report everything that might be a bug. pwnkit only reports what it can prove is a bug — and the proof comes from an agent that can't be biased by the original reasoning.
what you can do with it
scan an LLM endpoint, audit an npm package, do a deep review of a codebase, query verified findings, or browse past scan results — and wire it into CI so findings show up directly in GitHub's Security tab via SARIF.
why this matters now
georgia tech's vibe security radar disclosed 35 new CVEs directly related to AI-generated code in march 2026 alone. researchers estimate 45% of AI-generated code contains security vulnerabilities.
AI agents are writing code faster than humans can audit it. the gap between "it works" and "it's secure" is growing every week.
existing tools (promptfoo, garak, PyRIT) are primarily evaluation frameworks — they test whether your defenses hold against known attack patterns. pwnkit is the opposite: it's an offensive tool that discovers new vulnerabilities using multi-turn agentic reasoning. working exploit code is the proof. that's what found the node-forge certificate forgery, not running a test suite against known patterns.
the methodology
pwnkit encodes the same audit methodology i used for the CVE work:
- target selection — identify high-value packages handling untrusted input, auth, crypto, parsing, or serialization. higher downloads = higher impact.
- deep source review — always audit the latest published version. read actual source code, not docs. map data flow from untrusted input to sensitive operations.
- verification — for each finding: can attacker-controlled data actually reach the vulnerable code? what preconditions are needed? does the PoC actually work? is the latest version still affected?
- honest severity assessment — rate on real-world exploitability, not theoretical impact. is it exploitable in default config? do upstream defenses block it?
- responsible disclosure — check SECURITY.md, prefer GitHub Security Advisories for CVE assignment, provide concrete fix suggestions, 90-day coordinated disclosure timeline.
the framework automates steps 1-4. step 5 is still manual — you should always review findings and handle disclosure yourself.
what's next
this is v0.3.4 — the foundation is solid. the npm audit workflow that found the CVEs works, and the LLM endpoint scanner covers 8/10 of the OWASP LLM Top 10. the areas i'm actively working on:
- MCP server security — scanning tool descriptions for injection, unauthorized access, SSRF (shipped in v0.3.4)
- web app pentesting — security headers, CORS, open redirects (shipped in v0.3.4)
- expanding the attack template library beyond the current 47 test cases
- better support for non-JavaScript ecosystems (Python, Go, Rust)
- deterministic CI replay mode for regression testing
if you find a vulnerability using pwnkit, i'd love to hear about it.
links
- pwnkit: 0sec.ai/pwnkit — where pwnkit lives now
- foxguard (open source): foxguard.dev · github.com/0sec-labs/foxguard
the original pwnkit repo and npm package are retired — the engine is closed-source inside 0sec. see the june 2026 update at the top for why.
built by doruk tan ozturk (@peaktwilight) — the same person behind those 7 CVEs. pwnkit is now the engine behind 0sec; if you're interested in security research, AI agents, or breaking AI systems for a living, come find me.