DEV Community: Michael Kayode Onyekwere

Four iteration rounds on a security scanner I run, all of them visible. Here is what the loop actually looks like.

Michael Kayode Onyekwere — Thu, 21 May 2026 15:04:52 +0000

Four iteration rounds on a security scanner I run, all of them visible. Here is what the loop actually looks like.

This is a worked example of running a continuous security scanner on a public surface and being wrong, in both directions, in close succession. The scanner is AgentScore, which scans MCP packages on npm and publishes a public security record. Over four days in mid-May 2026 it went through three corrections: an over-flagged class, a too-broad mitigator pass that produced a false negative on a known-credential-leak package, and a fresh sample-check that uncovered new sanitiser patterns we had not yet recognised. Each correction is in the public changelog. None of them was silent.

The point of the post is the loop, not the resolution.

What the data looked like on 2026-05-15

A class-tracker counts how many MCP packages have HIGH command_injection findings in a rolling 7-day window. Mid-April that number was a handful. Mid-May it was 31 distinct packages. Most were in the browser, CLI, or terminal-automation segment, where shell execution is genuinely common because the packages drive other CLIs.

The first hypothesis was real maintainer drift: maybe enough package authors in this segment were writing unsafe ${...} shell wrappers that the public-record arc had a story.

The second hypothesis, which became more probable when one more advisory took the count to 31 distinct packages, was that the scanner's regex was over-flagging legitimate template-literal patterns. Thirty distinct maintainers all genuinely shipping unsafe shell exec in 30 days, in a community of ~1,300 packages, would be an ecosystem failure. More likely the scanner had a false-positive class.

The actual answer, after four rounds of work over 96 hours, turned out to be mixed. Some of the 31 were false positives the scanner could downgrade with new context-aware mitigators. Some were real static-analysis hits in single-user CLI threat models that the scanner correctly continued to flag. The post is about how I got from "31 packages, hypothesis unclear" to "scanner correctly distinguishes which is which" and what each iteration round had to fix.

Round 1: the initial sample audit

The first move on 2026-05-16 was to manually inspect a sample of the flagged packages. Five were picked across the class: safari-mcp, brave-real-browser-mcp-server, memoir-cli, s3db.js, and claude-flow. Each was rescanned by hand against the regex that originally flagged them.

Of the five samples, four had patterns the scanner was catching incorrectly. Examples:

A postinstall script invoking codesign against an internal helper path constructed via path.join(__dirname, ...). Not user-controllable.
A this.exec(\SELECT ${fields} FROM ...) SQL query in a sqlite client. Not a child process call at all.
Hardcoded ALL_CAPS module constants like ${REPO_URL} interpolated for readability. Not user input.
A numeric ID from a GitHub webhook payload (event.pull_request.number). Cannot carry shell metacharacters.
A .md file titled v3-security-architect.md with the line literally annotated // ❌ Dangerous: shell injection possible as a teaching example. The scanner caught a security tutorial.

Initial estimated false-positive rate on the sample: high, but the number itself ended up being revised twice over the next 48 hours as the scope of "false positive" tightened.

Rounds 2 and 3: shipping the fix, then catching the fix's bugs

Three corrective passes shipped within hours of each other on 2026-05-16. Each was followed by external review that caught a structural issue in the previous one.

Pattern-level mitigators (round 1 of these three). Seven extensions to the existing sanitizer category (recognise this.exec, __dirname, ${ALL_CAPS}, numeric coercion, code-signing toolchain, npm auto-update patterns) plus a new documentation_context category for markdown code fences and anti-pattern annotations. A local verifier reported 100% suppression on the five-package sample.

Per-file iteration (round 2, caught by review): the 100% was an artifact. The scanner had been reading the gunzipped tarball as one buffer and running mitigators against a ±2000 character window in that buffer. A README heading three files away could downgrade a real finding in another file. The fix: walk the tar archive entry-by-entry, run mitigators against each file's own content only. Re-verification: still 100%.

All-matches per file (round 3, caught by review again): even per-file, single-match-per-file was masking. The scanner ran each pattern as a single .exec() per file, so an early benign shell call in a file would silently hide a later real unsafe one in the same file. Replaced with an all-matches walk that scores each match independently and keeps the worst-severity result. Re-verification: 75 percent, not 100.

The honest number was 75. memoir-cli@3.6.1 actually does contain exec(\open "${url}") in upgrade.js and execSync(\git clone ${config.gitRepo} .) in diff.js. In a single-user CLI threat model these are benign because the user is attacking only themselves. But the scanner cannot infer the threat model from static analysis, and the flag is correct at that level.

The previous "100%" claim was a measurement bug, not progress.

What I did with the historic advisories

Two paths were possible.

Option A: rewrite each of the affected advisories to the corrected severity. Clean for the casual reader. But quietly editing past records contradicts the public-correction-loop principle that is literally on the methodology page.

Option B: keep the original advisories visible at their original severity, add a correction record at the top of the advisories page pointing readers to the mitigator changelog, and let the live /report/<package> pages reflect the corrected severity once the monitor cron re-scans each affected package over the following 3-4 days.

I took Option B. The yellow correction banner on /security/advisories reads:

The scanner shipped a precision pass on 2026-05-16 targeting a self-detected false-positive class in browser/CLI/terminal MCP packages. Advisories below published before that pass on the affected class remain visible at their original severity. The live /report/<package> page will reflect the corrected severity once the monitor cron rescans that package. Until then, the cached scan-history value on the report page may still show the pre-mitigator severity. We do not silently rewrite the public record.

The mitigator changelog at /scanner/precision carries the May 16 mitigator-pass entry AND a follow-up entry documenting the per-file iteration and the corrected 75 percent suppression number. Both are on the public surface. Neither was edited after the fact.

What rounds 1 to 3 proved

It did not prove the scanner was correct. It proved three other things.

One: the in-class running count plus a sample audit is enough to detect a false-positive class before it does serious damage to credibility. I caught this in a 30-day window with no maintainer pushing back.

Two: the iteration loop works on me, not just on the packages I scan. The same /scanner/precision page that documents mitigators shipped in response to maintainers like Agions and HomenShum now carries an entry where the trigger was my own internal review.

Three: refusing to silently rewrite history is uncomfortable but it is the only credibility move. A reader who finds an old advisory on a package and a corrected scan on the live report page can see the gap and the correction note explaining it. They do not have to trust that the system always told the truth. They can read both versions and decide.

Round 4 (the false-negative correction, 48 hours later)

The work above was substantially complete after the 2026-05-16 fix. Two days later it needed an update, because the fix itself had introduced a false negative.

The new documentation_context mitigator category shipped on 2026-05-16 included a markdown-heading pattern /^#{1,4}\s+\S/m. That regex matches markdown headings. It also matches YAML comments, shell-script comments, TOML headers, and anything else that starts with #. Without a filename gate, the category fired on any file that happened to contain a #-prefixed line within 2000 characters of a real finding.

Concrete miss: fa-mcp-sdk, the package whose config/local.yaml we publicly disclosed in late April for shipping credentials in the published tarball, scored 30 / HIGH on every scan from April 25 through May 13. On May 17 a fresh scan with the new v2.2 ruleset returned 65 / ELEVATED. The CRITICAL hardcoded_secret finding was now MEDIUM. Looking at it on May 18 morning, the digest showed a score recovery that looked like maintainer action after four weeks of silence. It was not. The YAML file's own header comments matched the markdown-heading regex, the documentation_context mitigator fired, and the credentials we'd publicly disclosed were silently downgraded by our own scanner.

Two other packages had the same effect with materially-changed public severity (mcpbrowser and opencode-gitlab-dap). Four more had the same misfire but their findings were already correctly downgraded by parallel sanitizer mitigators, so the public score did not move.

The fix was a six-line patch: a CATEGORY_FILE_GATES table that requires documentation_context patterns to fire only on files whose extension is .md, .mdx, .markdown, .rst, .txt, .adoc, or .asciidoc. Other mitigator categories were not file-gated because their patterns are tied to language syntax that does not overlap with comment characters in other languages.

Within the same morning, I rescanned the seven affected packages with the fixed scanner and pushed the corrected scan_history rows. fa-mcp-sdk is back at 45 / HIGH with the CRITICAL credential finding restored. The /scanner/precision changelog carries a new entry documenting the fix exactly the same way the original false-positive entry was documented two days earlier.

So now the public correction record contains two entries: one for an over-correction on the false-positive side that affected 31 advisories, and one for an under-correction on the false-negative side that affected 3 public scores. Both visible. Neither rewritten silently.

The pattern this surfaces: precision passes on a scanner have a natural overshoot. You catch a class of false positives, you ship mitigators, the mitigators are slightly too broad, you catch the resulting false negatives, you tighten. The thing that makes this a credibility move rather than a credibility cost is doing all of it on the public surface, where readers can audit the shape of the correction loop rather than trust that we always told them the truth.

What's reproducible

The mitigator commits are public. The 5-package sample is version-pinned in scripts/verify-mitigators.cjs so the precision claim can be reproduced. The pattern tracker is at scripts/track-command-injection-pattern.cjs. The corrected scanner is at SCANNER_VERSION = 2.2 in src/lib/kya/scanner.js, with the May 18 file-gate fix in the same file. The list of 7 affected packages and their corrected scores is in the /scanner/precision changelog entry dated 2026-05-18.

The 31 historic advisories are still at /security/advisories with the correction banner pointing at the changelog.

What the tracker count actually stabilised at

Three days after the May 16 mitigator pass, the running count in the browser/CLI command_injection class dropped from 31 to 14 in 48 hours. We expected it to keep dropping toward zero as the v2.2 scanner propagated through the corpus.

It did not. The count moved back up to around 20 and stayed there.

The naive read of that is "the fix did not work." The honest read is different. The tracker counts packages with HIGH command_injection findings the scanner did NOT downgrade. If the v2.2 + file-gate mitigators are working, FPs disappear from the count and only real-pattern hits remain. The count stabilising at roughly 20 means the underlying rate at which real template-literal shell-exec patterns appear in new browser/CLI MCP publishes is about 20 packages per rolling 7-day window. That is the ecosystem's actual signal, not our scanner's failure.

To verify, we sampled 5 packages from the post-fix corpus: beecork, memex-mvp, @piyushdua/engram-dev, agentic-flow, @kevinrabun/judges. Manual inspection of each:

beecork wraps a user-config-derived bin name into execSync(\${whichCmd} ${bin}) in dist/cli/doctor.js. Real static-analysis hit. The threat model is single-user CLI (the user is configuring their own tool), so the practical risk is low, but the scanner correctly cannot infer that.
memex-mvp does execSync(\launchctl unload ${JSON.stringify(PLIST_PATH)}). JSON.stringify wraps the value in escaped double quotes, which is a shell-safe quoting technique. False positive that the scanner did not yet recognise as a sanitiser.
@piyushdua/engram-dev does execSync(\git worktree remove ${shellQuote(record.path)}). The maintainer is explicitly wrapping input in shellQuote(). False positive that the scanner did not yet recognise as a sanitiser.
agentic-flow does execSync(\gh ${args.join(' ')}) in .claude/helpers/github-safe.js. args is process.argv. Real static-analysis hit in a CLI threat model.
@kevinrabun/judges is a code-judging benchmark tool. The dangerous-looking code is embedded as STRING LITERALS in a fixture array (expectedRuleIds: ["AUTH-001", ...]), specifically as test corpus for the tool to detect. False positive that the scanner did not yet recognise as a fixture marker pattern.

3 of 5 are false positives the scanner could downgrade with additional mitigator patterns. 2 of 5 are real interpolation-into-shell patterns the scanner correctly keeps flagged at HIGH.

The third precision pass shipped today, 2026-05-19, adds the missing mitigators:

shellQuote(), shell_quote, shq.quote(, require('shell-quote') as sanitiser patterns
${JSON.stringify(...)} directly inside the interpolation slot as a sanitiser pattern
expectedRuleIds:, dangerousPatterns:, benchmarkCases: as test-fixture markers
File-path heuristics for benchmark*.js, rules*.js, judges*.js that contain detection corpora
A meta-template marker: source containing both backslash-escaped backticks and backslash-escaped ${ interpolation markers in close proximity. That combination means the surrounding string is a template literal embedded as string data, e.g. a code-judging tool's test fixture where the dangerous-looking code is corpus to be detected rather than executable code.

After this third pass, the 5-package post-fix sample suppression rate is 60 percent. Two stay at HIGH because they really are real-pattern hits in single-user CLI threat models. The remaining count in the tracker now reflects something closer to the genuine rate of real template-literal shell exec in new browser/CLI MCP publishes, not measurement noise.

What the iteration loop actually looks like

Four rounds of precision work in 96 hours:

Round	Date	What it corrected
1	2026-05-16	Initial mitigator set: this.exec, path.join, ALL_CAPS, numeric coercion, codesign, npm auto-update, plus a `documentation_context` category for markdown anti-pattern examples.
2	2026-05-16	Per-file iteration (mitigators only see same-file context), all-matches-per-file (an early benign call cannot mask a later real one), GNU/pax tar parsing, version-pinned verification.
3	2026-05-18	`documentation_context` only fires on `.md`, `.mdx`, `.rst`, `.txt` files. The previous loose form was matching YAML `#` comments as if they were markdown headings, which silently downgraded `fa-mcp-sdk`'s CRITICAL credential finding to MEDIUM. False-negative correction, 7 packages re-scanned, public correction record kept.
4	2026-05-19	Sanitiser additions for `shellQuote()`, `${JSON.stringify(...)}`, and benchmark fixture markers. False-positive correction on the post-fix sample.

Each round was prompted by either a fresh sample audit or a peer review noticing a structural issue with the previous round. None of the rounds were silent. Each one shipped a /scanner/precision changelog entry naming what was wrong and what changed.

The point is not that AgentScore got everything right. The point is that the iteration is visible. A reader who finds an old advisory on a package and a corrected scan on the live report page can see the gap and the correction note explaining it. They do not have to trust the system. They can read both versions and decide.

For anyone running continuous scanning at scale on a public surface, the lesson is: the loud direction (false positives) is easier to catch than the quiet direction (false negatives), the FN risk gets harder once you start tightening, and the only thing that compounds credibility through all of it is doing the corrections in public.

AgentScore continuously scans MCP packages on npm and publishes a public security record. Live data, advisories, and the full mitigator changelog are at agentscores.xyz.

AGENTSCORE-2026-0022: `entroly-wasm` risk change detected

Michael Kayode Onyekwere — Mon, 04 May 2026 08:20:15 +0000

entroly-wasm updated from 0.11.0 to 0.12.0. Score changed 95/100 to 80/100 (-15). Risk: LOW to MODERATE. 3 findings.

Package

Name: entroly-wasm
Version: 0.11.0 to 0.12.0
Score: 95/100 to 80/100
Risk: LOW to MODERATE

Findings

[MEDIUM] no_repository: Package has no repository link — source code is not verifiable
[LOW] no_license: Package has no licence specified
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: adalako

Full advisory: AGENTSCORE-2026-0022

Verdict API: curl https://agentscores.xyz/api/verdict?npm=entroly-wasm

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0021: `javaperf` risk change detected

Michael Kayode Onyekwere — Sat, 02 May 2026 19:28:09 +0000

javaperf updated from 1.2.2 to 1.3.0. Score changed 95/100 to 80/100 (-15). Risk: LOW to MODERATE. 1 finding.

Package

Name: javaperf
Version: 1.2.2 to 1.3.0
Score: 95/100 to 80/100
Risk: LOW to MODERATE

Findings

[HIGH] command_injection: Potential command injection: shell execution with template literal input

Full advisory: AGENTSCORE-2026-0021

Verdict API: curl https://agentscores.xyz/api/verdict?npm=javaperf

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0020: `@staticn0va/wigolo` risk change detected

Michael Kayode Onyekwere — Fri, 01 May 2026 13:28:21 +0000

@staticn0va/wigolo updated from 0.6.6 to 1.0.0. Score changed 80/100 to 70/100 (-10). Risk: MODERATE to MODERATE. 2 findings.

Package

Name: @staticn0va/wigolo
Version: 0.6.6 to 1.0.0
Score: 80/100 to 70/100
Risk: MODERATE to MODERATE

Findings

[MEDIUM] excessive_dependencies: Package has 26 runtime dependencies (high attack surface)
[HIGH] command_injection: Potential command injection: shell execution with template literal input

Full advisory: AGENTSCORE-2026-0020

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40staticn0va%2Fwigolo

Auto-published by AgentScore MCP security monitoring.

Four MCP packages, four ways the supply chain shifted in two weeks of npm monitoring

Michael Kayode Onyekwere — Fri, 01 May 2026 01:11:38 +0000

Four MCP packages, four ways the supply chain shifted in two weeks of npm monitoring

By Michael K Onyekwere

I monitor nearly a thousand published MCP packages on npm in real time. The pipeline polls the npm changes feed every two minutes, scans every newly-published version, and writes the result against the previous baseline. When a real package update drops the score below the confidence threshold, a public advisory is generated and the RSS feed updates.

This post collects four worked examples from the last two weeks. The named packages are not malicious. The point is to make visible the kinds of routine changes a consumer would never see at install time, because the install path is npx -y <package> or an equivalent unpinned npm install that always pulls whatever version is current on the registry.

1. prism-mcp-server: four capabilities added in one major version bump

This is the strongest single drift event of the period.

On 2026-04-27 the watch feed had prism-mcp-server at version 11.6.0 with score 85 / 100, risk LOW, no findings beyond a missing-provenance note.

On 2026-04-28 11:44 UTC the same package republished as version 12.5.0. The watch detect logged the diff under two seconds later. The rescan produced:

Score 85 to 65, risk LOW to ELEVATED
New HIGH command_injection finding: shell execution with template-literal input
New MEDIUM excessive_dependencies finding: 23 runtime dependencies (was lower in v11)
Capability surface gained four categories that did not exist in the prior major version:
- browser_automation
- email_messaging
- filesystem_read
- shell_exec

Consider the consumer position. Anyone with prism-mcp-server installed via the typical agent-config form (npx -y prism-mcp-server in claude_desktop_config.json or equivalent) had their agent silently inherit four new capability categories the moment 12.5.0 hit npm. No review trigger. No opt-in. No diff against what was previously authorised.

This is not a story about prism-mcp-server's publisher doing something wrong. Major version bumps are exactly when a maintainer is allowed to reshape the surface area. The point is that the consumer has no mechanism in place to notice it.

The advisory AGENTSCORE-2026-0017 covers this case. RSS feed picked it up the same minute.

2. agent-planner-mcp: four versions in nine hours

A different shape of the same problem.

On 2026-04-25 agent-planner-mcp published four times in a single day:

13:44 UTC: v0.8.1
18:10 UTC: v0.9.0
19:14 UTC: v0.9.1
22:44 UTC: v1.0.0

The score held at 75 / MODERATE across all four publishes. No major findings change. But each release shifted what tools the package exposed.

If you reviewed v0.8.1 in the morning and were happy with what it had, by the end of the day there had been three additional surface changes you never saw, and the package had crossed a major-version boundary (v1.0.0). A npx -y install on a tool that depends on agent-planner-mcp would land on whichever version was current at install time, with no way to relate that version to the one that was reviewed.

This is the same pattern observed earlier in the period with @planu/cli, which on 2026-04-22 shipped v1.84.0 with four new capabilities (database_access, filesystem_read, search_index, unknown) and a HIGH command_injection finding, then walked the change back in v1.85.0 forty-six minutes later by removing all four capabilities. A consumer running npx -y @planu/cli during that forty-six-minute window would have got the expanded surface; one running it forty-seven minutes later would have got the walked-back version. Neither knew.

Two instances in two weeks rules out coincidence. Maintainers iterating in real time is normal and healthy. Consumers having no view of the iteration is the gap.

3. sverklo: a quiet package, then a backlog-dump release that opens a new HIGH

sverklo had been at v0.12.5 with score 80 / MODERATE since 2026-04-19, carrying one HIGH command_injection finding for nearly a week.

On 2026-04-25 at 20:56 UTC the package published v0.16.0. Four minor versions in one go, the kind of release that signals a maintainer clearing a backlog. The diff:

Score 80 to 60 (MODERATE to ELEVATED)
The existing HIGH command_injection is still present
A new HIGH unsafe_eval finding has appeared

Two HIGH findings now, where there was one before, on the same package, after a single release.

This inverts a common assumption. Maintainer activity is generally treated as a positive signal in npm review heuristics: actively maintained beats abandoned. In MCP specifically, a long backlog released as one big version-skip publish expands the surface a consumer was reviewing against. The longer the gap, the wider the change in the catch-up release.

If your review of sverklo was based on v0.12.5, your review is now stale by two HIGH findings.

4. nodebench-mcp: the case where the maintainer pushed back, and the scanner got better

A different shape from the three above. This one shows what the feedback loop looks like when it works.

The scanner flagged nodebench-mcp v3.2.0 with two HIGH findings: command_injection and unsafe_eval. I filed a public issue on the maintainer's repo.

The maintainer (HomenShum) reviewed both findings against source on 2026-04-26 and posted a detailed response. They:

Confirmed three real command_injection sites at specific file:line references and refactored each one to argv-based spawn with shell: false. Released as v3.2.1.
Identified the unsafe_eval finding as a false positive with specific evidence: the regex matched db.exec(\SQL ${var}) which is better-sqlite3's tagged-template SQL, not JavaScript eval.

The maintainer was right on both counts. The first three sites were genuinely exploitable in the agent-controllable input model and got fixed properly. The fourth was a scanner precision gap that we should not have been flagging.

Same day, two scanner mitigators shipped (commit 4ee2659):

Database-shaped variable names calling .exec() (db, database, conn, client, pool, prepared, stmt, sql, query, knex, prisma) now downgrade command_injection to LOW
Files whose names contain the substring Eval followed by an uppercase letter (selfEvalTools.js, llmJudgeEval.js) now downgrade unsafe_eval to LOW because in those files the literal word eval appears inside English-language strings describing the evaluation flow, not in actual JavaScript eval() calls

After the maintainer's PR landed and the mitigators shipped, nodebench-mcp@3.2.1 rescanned at 85 / LOW, up from 55 / ELEVATED. The full mitigator changelog is at agentscores.xyz/scanner/precision.

That is the feedback loop you want from a security tool. Public review goes both ways. Real findings get fixed. Scanner mistakes get challenged with evidence. The scanner improves.

What this looks like to a consumer

If you are running npx -y against any MCP package in a Claude Desktop, Cursor, Continue, OpenAI agents, or custom MCP client config:

Your agent's capability surface is whatever the latest version of every transitive package decided to expose at install time. You did not approve it. It came along for the ride.
A major-version bump is allowed to reshape that surface entirely. v11 to v12 in a published package can mean +4 capabilities, a new HIGH finding, or nothing at all. There is no way to tell from the install command which it will be.
Multiple publishes in one day are normal during active development of an MCP package, and each one can add or remove tools. Pinning to a version reviewed in the morning does not protect you from the version reshape that landed at 22:44.
A long quiet period followed by a multi-version-skip release is one of the riskier patterns, because the catch-up release folds in surface changes that would have been flagged separately across the missing reviews.

What helps

The cheapest defence is to pin every MCP package to a specific version in your agent config. Never npx -y package, always npx -y package@x.y.z. Treat the pin like a lockfile entry. This is what the team at redis/RedisInsight did across every MCP dependency in their config after our scan flagged the unpinned installs (agentscores.xyz/case-study/redis).

Beyond that, the public RSS feed at agentscores.xyz/security/advisories carries every advisory as it lands, with score before, score after, version diff, and findings. If a package you depend on appears, you have minutes to evaluate the change before it hits your next install.

For teams that want enforcement rather than awareness, the policy gate at agentscores.xyz/policy-gate is a free GitHub Action that fails the build when an MCP dependency drops below the configured threshold. Repo-scoped exceptions land in the audit trail when you decide to accept a finding, rather than landing nowhere.

What the dataset shows

Across nearly a thousand monitored MCP packages, the npm changes feed is processed every two minutes around the clock. The watch cron sees roughly 1,000 to 2,000 monitored-package publish events per day. Most are version bumps with no meaningful score change. About 1 to 3 per day clear the confidence threshold and become public advisories. A few of those each week involve a new HIGH or CRITICAL finding.

Several per week worth knowing about. None of them malicious. All of them shape what an agent built on these packages can do, without notifying anyone downstream.

If you maintain or consume MCP packages and want to talk about any of this, the contact form at agentscores.xyz/contact reaches me directly.

By Michael K Onyekwere. AgentScore is a continuously-updated trust layer for the MCP ecosystem. The dataset, scanner, advisory feed, and policy gate are at agentscores.xyz. The full ruleset history and the public report that motivated each precision change is at agentscores.xyz/scanner/precision.

AGENTSCORE-2026-0019: `@cg3/prior-mcp` risk change detected

Michael Kayode Onyekwere — Fri, 01 May 2026 00:48:35 +0000

@cg3/prior-mcp updated from 0.6.4 to 0.7.0. Score changed 100/100 to 75/100 (-25). Risk: LOW to MODERATE. 2 findings.

Package

Name: @cg3/prior-mcp
Version: 0.6.4 to 0.7.0
Score: 100/100 to 75/100
Risk: LOW to MODERATE

Findings

[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: cg3llc

Full advisory: AGENTSCORE-2026-0019

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40cg3%2Fprior-mcp

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0018: `@planu/cli` risk change detected

Michael Kayode Onyekwere — Thu, 30 Apr 2026 22:18:10 +0000

@planu/cli updated from 2.12.0 to 2.12.1. Score changed 85/100 to 65/100 (-20). Risk: LOW to ELEVATED. 3 findings.

Package

Name: @planu/cli
Version: 2.12.0 to 2.12.1
Score: 85/100 to 65/100
Risk: LOW to ELEVATED

Findings

[MEDIUM] no_repository: Package has no repository link — source code is not verifiable
[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: planudev

Full advisory: AGENTSCORE-2026-0018

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40planu%2Fcli

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0017: `prism-mcp-server` risk change detected

Michael Kayode Onyekwere — Tue, 28 Apr 2026 11:44:15 +0000

prism-mcp-server updated from 11.6.0 to 12.5.0. Score changed 85/100 to 65/100 (-20). Risk: LOW to ELEVATED. 3 findings.

Package

Name: prism-mcp-server
Version: 11.6.0 to 12.5.0
Score: 85/100 to 65/100
Risk: LOW to ELEVATED

Findings

[MEDIUM] excessive_dependencies: Package has 23 runtime dependencies (high attack surface)
[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: dmitricostenco

Full advisory: AGENTSCORE-2026-0017

Verdict API: curl https://agentscores.xyz/api/verdict?npm=prism-mcp-server

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0016: `@jtalk22/slack-mcp` risk change detected

Michael Kayode Onyekwere — Sun, 26 Apr 2026 15:46:09 +0000

@jtalk22/slack-mcp updated from 4.1.2 to 4.2.0. Score changed 90/100 to 80/100 (-10). Risk: LOW to MODERATE. 1 finding.

Package

Name: @jtalk22/slack-mcp
Version: 4.1.2 to 4.2.0
Score: 90/100 to 80/100
Risk: LOW to MODERATE

Findings

[HIGH] command_injection: Potential command injection: shell execution with template literal input

Full advisory: AGENTSCORE-2026-0016

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40jtalk22%2Fslack-mcp

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0015: `sverklo` risk change detected

Michael Kayode Onyekwere — Sat, 25 Apr 2026 19:56:12 +0000

sverklo updated from 0.12.5 to 0.16.0. Score changed 80/100 to 60/100 (-20). Risk: MODERATE to ELEVATED. 2 findings.

Package

Name: sverklo
Version: 0.12.5 to 0.16.0
Score: 80/100 to 60/100
Risk: MODERATE to ELEVATED

Findings

[HIGH] command_injection: Potential command injection: shell execution with template literal input
[HIGH] unsafe_eval: Uses eval() with dynamic input

Full advisory: AGENTSCORE-2026-0015

Verdict API: curl https://agentscores.xyz/api/verdict?npm=sverklo

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0014: `aidex-mcp` risk change detected

Michael Kayode Onyekwere — Sat, 25 Apr 2026 15:04:13 +0000

aidex-mcp updated from 1.17.1 to 1.18.0. Score changed 70/100 to 60/100 (-10). Risk: MODERATE to ELEVATED. 4 findings.

Package

Name: aidex-mcp
Version: 1.17.1 to 1.18.0
Score: 70/100 to 60/100
Risk: MODERATE to ELEVATED

Findings

[LOW] install_script: Package has 'postinstall' script: node scripts/postinstall.mjs
[MEDIUM] excessive_dependencies: Package has 21 runtime dependencies (high attack surface)
[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: uchalas

Full advisory: AGENTSCORE-2026-0014

Verdict API: curl https://agentscores.xyz/api/verdict?npm=aidex-mcp

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0013: `vaultpilot-mcp` risk change detected

Michael Kayode Onyekwere — Sat, 25 Apr 2026 14:32:10 +0000

vaultpilot-mcp updated from 0.7.0 to 0.8.0. Score changed 95/100 to 85/100 (-10). Risk: LOW to LOW. 2 findings.

Package

Name: vaultpilot-mcp
Version: 0.7.0 to 0.8.0
Score: 95/100 to 85/100
Risk: LOW to LOW

Findings

[LOW] install_script: Package has 'postinstall' script: patch-package
[MEDIUM] excessive_dependencies: Package has 21 runtime dependencies (high attack surface)

Full advisory: AGENTSCORE-2026-0013

Verdict API: curl https://agentscores.xyz/api/verdict?npm=vaultpilot-mcp

Auto-published by AgentScore MCP security monitoring.