DEV Community: Michael Kayode Onyekwere

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.

Continuous monitoring caught a credential leak in a published MCP package. Six republishes later, it is still there.

Michael Kayode Onyekwere — Sat, 25 Apr 2026 07:13:32 +0000

Continuous monitoring caught a credential leak in a published MCP package. Six republishes later, it is still there.

This is a disclosure writeup. It describes the case at the class level only. No credential values are quoted anywhere in this post.

What was found

The package is fa-mcp-sdk on npm. It is distributed as a Model Context Protocol SDK, which means it is installed by agent-framework tooling (Claude, Cursor, OpenAI agents, custom MCP clients) typically via npm install fa-mcp-sdk or npx -y fa-mcp-sdk. Because that install path runs without manual review in most agent setups, anything inside the published tarball reaches consumers immediately on first install.

On 2026-04-19 a continuous scanner I run flagged the package on a fresh publish. The score dropped sharply, and the finding type was hardcoded_secret at critical severity. On manual review I found a file at package/config/local.yaml containing real production credentials. The classes:

An OpenAI / LiteLLM API key tied to a named user at an internal LLM gateway
An Active Directory service-account username and password covering four LDAP controllers across two production domains in a financial-services estate
Consul ACL tokens for both dev and prod data centres
A Postgres superuser password
A JWT encryption key
A basic-auth password

The combination is what makes this severe, not any single credential. The LDAP service account alone gives an attacker bind access to enumerate the entire Active Directory of the affected organisation. The Consul prod token likely exposes further secrets in their KV store. The Postgres superuser password is direct database access on a financial-services platform. Anyone who installed the package and read it had everything needed to map the network, escalate privileges, and exfiltrate data.

Why MCP supply chain is structurally different

Regular npm supply chain has a 20-year body of guidance, lockfiles, audit tooling, and review culture around it. MCP is new, and four properties of how MCP packages are typically used make the threat model materially worse:

No lockfiles in most MCP client configs. Claude Desktop, Cursor, and similar agent frontends launch MCP servers from a config file that uses npx -y with no version pin. Every restart pulls latest. The npm ecosystem solved this with package-lock.json years ago; MCP has not yet picked it up.
Install paths bypass review. When an agent framework starts an MCP server, no human looks at what was installed. The pattern is closer to running a remote shell command than installing a dependency. Any code in the published tarball runs on the consumer's machine the first time the agent boots.
The capability surface is opaque. A typical npm dependency exposes functions a developer chooses to import. An MCP package declares a set of tools that the agent can autonomously decide to call. Adding email_messaging or shell_exec between minor versions is a meaningful scope change that consumers rarely notice.
Publisher posture is patchy. Many MCP packages have no provenance attestations, no repository link, no published security contact, no release pipeline that excludes config files. Across 880 currently-monitored MCP packages, missing-provenance is by far the most common finding type, accounting for 64% of all flagged issues.

Put together, an unpinned npx -y install of an MCP package gives the publisher more authority over the consumer's runtime than a typical npm dependency does, with less review and less visibility.

The disclosure timeline

I held the public disclosure for six days while attempting private remediation through several channels. None worked.

Date (UTC)	Action
2026-04-19	First private email to the maintainer's published npm contact address with the full credential list and recommended remediation (unpublish, rotate, add `.npmignore`). No reply.
2026-04-19 / 20	Maintainer published 0.4.58 and 0.4.59. `local.yaml` unchanged.
2026-04-20	Second private email to the maintainer's GitHub-listed email address, citing the file path explicitly. No reply.
2026-04-20	Third (urgent) private email listing four of the six credential values verbatim, in case the previous emails had not been read carefully. No reply.
2026-04-22	Maintainer published 0.4.69. A sanitised template was added at `_local.yaml`, but the original `local.yaml` was left in place. So the maintainer touched the same directory and still left the file.
2026-04-22	Escalation email to `security@npmjs.com` requesting a force-unpublish of the affected versions or a registry-level advisory. No (visible) action.
2026-04-23	Maintainer published 0.4.70 and 0.4.71. File still present.
2026-04-25	Public class-level GitHub issue filed on the affected repository. AgentScore advisory `AGENTSCORE-2026-0012` published. CVE request submitted to GitHub Security Lab.

I extracted the latest published tarball (0.4.71) on 2026-04-25 to verify before going public. Ten of the original credential pattern matches were still present in package/config/local.yaml. Same file, same values, six republishes since the first private disclosure.

What I think happened internally

This is speculation, but it fits the visible pattern. Someone at the maintainer organisation added _local.yaml (the underscore-prefixed sanitised template) to the config/ directory, probably in response to one of my emails or an internal review. That same person, or a different person, did not notice or did not act on the original local.yaml sitting next to it. The publish pipeline ships the entire config/ directory unconditionally, so every subsequent release continues to leak the credentials regardless of any other code changes shipped alongside.

If that read is right, the actual fix is one line in package.json:

"files": [
  "dist",
  "README.md"
]

Or one entry in .npmignore:

config/local.yaml

That one-line change has not landed across six versions and six days. Whatever process the maintainer organisation has for receiving and acting on security reports has not produced a remediation in this window.

Where this sits in the broader MCP ecosystem

Numbers are from the live AgentScore monitoring dataset on 2026-04-25, covering 880 MCP packages on npm and 9,129 scans on record:

Across the most recent 500 scans, 87% of MCP packages produce at least one finding. Most of those findings are not vulnerabilities; they are verifiability gaps (no_provenance, no_repository).
no_provenance accounts for 64% of all findings. The MCP ecosystem has not yet adopted npm provenance attestations at scale.
Source-code findings are rarer but present: command_injection patterns appear in 10% of findings, unsafe_eval in 2%, excessive_dependencies in 1%.
8.6% of 720 sampled packages publish at least one install-time script. Most are benign banners; the pattern is a known supply-chain vector either way.
hardcoded_secret is the rarest finding type the scanner produces, and after the April 22 v2.1 update added context-aware downgrade for test fixtures, it surfaces only on packages with genuine credential exposure. In a recent 500-scan sample with that downgrade applied, zero packages flagged for it. That is what makes the fa-mcp-sdk case unusual: real credentials in a published tarball, not a test fixture.

The risk distribution across the monitored set is healthy overall: 85% of packages score LOW, 12% MODERATE, 2% ELEVATED, 0.5% HIGH. The supply-chain attack surface for MCP is not concentrated in the average package; it is concentrated in the long tail. Continuous monitoring exists to surface that tail.

Lessons for MCP consumers

If you install MCP packages without pinning, this is the kind of thing that ends up on disk in your build environment. Four concrete moves:

Pin your MCP dependencies to exact versions. Do not use npx -y or open ranges. The Redis team did this for RedisInsight in April 2026 after a separate scan report flagged five unpinned MCP packages there. Two days from report to every MCP version pinned in their config. The full case is at agentscores.xyz/case-study/redis.
Treat install scripts on MCP packages as a manual-review gate. Most are benign banners, but the pattern is a classic supply-chain vector. The Policy Gate flags their presence so a human decides.
Re-evaluate capability changes between version bumps. A package that adds email_messaging, filesystem_write, or shell_exec between minor versions is a scope change, not a routine update. The Agions case at agentscores.xyz/case-study/agions shows what a four-day arc looks like when a maintainer engages: scan report, targeted patch in 48h, then a major-version structural cleanup that removed seven capabilities from the tool surface.
Watch a public advisory feed for the packages you have in your inventory. Score drops on packages already installed are the early-warning signal. RSS at agentscores.xyz/security/advisories/rss.xml.

The two case studies above bracket the full range of maintainer responses we have seen. Most maintainers, when their package is flagged, behave like Redis or Agions. The fa-mcp-sdk case is what continuous monitoring catches in the rare instance where they do not.

How this got caught

The scanner that flagged fa-mcp-sdk on its first publish runs continuously over the npm registry feed. It is not a manual research project, and it does not require the maintainer to opt in. When a new version of any monitored MCP package is published, the scanner has a result within minutes. That detection mechanism is what made the six-republishes-in-six-days timeline visible. Without continuous monitoring, the only way to find a credential leak in a tarball is for an individual consumer to manually inspect what they installed, which essentially never happens. Full advisory at agentscores.xyz/security/advisories.

What happens next

If fa-mcp-sdk@0.4.72 ships with local.yaml removed and the credentials rotated, the AgentScore monitor will detect the change and the advisory will move to a resolved state. If not, the GitHub Security Lab CVE request and the resulting GitHub Advisory Database entry will route the finding into Dependabot, Snyk, Socket, and the rest of the dependency-scanning ecosystem automatically. Either path closes the consumer exposure.

If you maintain an MCP package: please add config/local*.yaml, .env, and any local development config files to .npmignore or to the files array in package.json today. The pattern in this case is preventable with a one-line change, and the cost of getting it wrong scales with how many people install the package.

References:

AgentScore advisory AGENTSCORE-2026-0012: agentscores.xyz/security/advisories
AgentScore scan report: agentscores.xyz/report/fa-mcp-sdk
Public GitHub issue with the disclosure timeline: Bazilio-san/fa-mcp-sdk#3
Ecosystem statistics report (April 2026): agentscores.xyz/research/mcp-ecosystem-april-2026