Server depends on 'expresss' (triple s) with Levenshtein distance 1 from 'express'
1Open the manifest and confirm the dependency `chai@4` is present. The scanner's similarity pipeline matched this name against the curated target `chalk` via the levenshtein-near classifier. If this dependency is an intentional internal fork or re-export, add it to `legitimate-forks.ts` so the finding will no longer fire.npm:chai@4Expect: Dependency npm:chai@4 is declared; it is NOT in the legitimate-fork allowlist at scan time.
2Recompute the Damerau-Levenshtein distance and Jaro-Winkler similarity between `chai` and `chalk` using the same primitives as the scanner. Concretely, the rule expects Damerau-Levenshtein ≤ 2 and Jaro-Winkler ≥ 0.80 (except for advisory-registry matches which skip the floor). Observed values: distance 2, Jaro-Winkler 0.848.npm:chai@4Expect: Damerau-Levenshtein distance between "chai" and "chalk" is 2. Jaro-Winkler is 0.848. The numbers agree with what the rule recorded.
3Open the package manifest at this RFC 6901 pointer and read the line. Confirm the package name recorded in the manifest is literally `chai` (not a spelling the build tool fuzzed to) and that no post-resolution rewrite turns this entry into the legitimate `chalk`.package.json/dependencies/chaiExpect: The manifest entry at package.json/dependencies/chai resolves to chai@4 — the exact name the scanner flagged.
4Open the npm page for `chai` and compare against the legitimate `chalk`. Check: publisher identity, publish date, weekly download count, repository link, postinstall script presence. A typosquat typically presents as: recently published, low download count, no repository link, optionally carrying a postinstall hook that executes code at install time.npm:chai@4Expect: Either the candidate is a legitimate publisher-authored alternative (in which case add to `legitimate-forks.ts`) or its metadata confirms the typosquat hypothesis (recent, unknown publisher, low downloads, suspicious scripts).
sourceexternal-contentnpm:chai@4
Dependency npm:chai@4 is within Damerau-Levenshtein distance 2 of chalk (threshold 2).
Dependency names are external content resolved from public package registries. A near-miss to a popular canonical name is a supply-chain anomaly under ISO 27001 A.5.21 — the package manager installs whichever spelling is declared, with no built-in guard against lexically similar substitutions.
The manifest entry at /dependencies/chai directs the package manager to resolve and install chai@4. Resolution is purely string-matched against the registry — a typosquatted name installs whatever code the squatter published.
sinkcommand-executionnpm:chai@4
Malicious package `chai` executes attacker code in the build environment or at import time. Attack classifier: levenshtein-near. Target shadowed: `chalk`.
Lockfiles pin versions but do not pin the spelling of the dependency name. The static analyser cannot confirm whether a typosquat-aware package firewall (Socket.dev, Snyk Advisor) is in the CI chain; the auditor must verify.
impactremote-code-execution
server-host
A developer installs `chai` by typo, copy-paste, or autocomplete. The package's postinstall hook runs during installation with the developer's or CI runner's credentials, or the payload executes on first import when the MCP server starts. An MCP server compromised this way delegates full tool authority to attacker code on every downstream agent interaction.
MCP server accepts initialize handshake without any authentication token or API key
1Connect to the MCP server transport (streamable-http) without providing any credentials (no Authorization header, no API key query parameter, no mTLS certificate). Issue the `initialize` request followed by `tools/list`. If both succeed, authentication is genuinely absent.capability:toolsExpect: Server responds 200/OK to `initialize` and returns the tool list without a 401/403 or any WWW-Authenticate challenge.
2If the MCP server is fronted by a reverse proxy (nginx / envoy / Traefik / IAP), inspect the proxy configuration and confirm whether auth is terminated at that layer. If yes, document the proxy's auth strategy in an audit note; the finding can then be dismissed with provenance. If no, the server is the auth boundary and E1 stands.nginx.conf/server/locationExpect: Either the proxy enforces auth (dismiss with audit trail) or no proxy exists (E1 stands).
3Verify the server's bind address. A 127.0.0.1 bind is not a substitute for authentication — DNS rebinding (Jackson/Bortz/Boneh 2007) makes localhost reachable from any web page the user visits. Unauthenticated localhost MCP servers have been demonstrated-exploited in the wild.capability:toolsExpect: Bind address is 0.0.0.0 / a routable IP (direct network exposure) OR 127.0.0.1 (still exposed via DNS rebinding from a malicious web page).
sourceenvironmentcapability:tools
Live connection to the MCP server over streamable-http succeeded with no credentials. `initialize` + `tools/list` returned without any WWW-Authenticate challenge.
An MCP server that answers tool enumeration without authentication trusts the network. Under modern threat models (CCS 2007 DNS rebinding, open cloud networking) no network is trustworthy.
sinkprivilege-grantcapability:tools
Full tool authority exposed without identity verification. Any client that reaches the transport can enumerate and (on systems that expose invocation) call every tool.
mitigationauth-checkabsentcapability:tools
No authentication mechanism present at the MCP server layer. Reverse-proxy-terminated auth may exist at a layer the scanner cannot observe; reviewer must confirm via the deployment diagram.
impactprivilege-escalation
server-host
Any network-reachable client can connect and invoke tools with the server's delegated authority. For localhost-bound servers, a malicious web page can still reach the server via DNS rebinding (Jackson/Bortz/Boneh 2007), making localhost no better than 0.0.0.0.