Is farion1231/cc-switch safe?
- Defense-evasion command idiom
- Node.js network egress
- Server bound to all network interfaces
cc-switch is an AI npm_package analyzed by SkillTotal's deterministic static scanner. The scan found no malicious indicators, though 4 risky constructs are reported for review. It can: delegated authentication and network egress — capabilities are what the code can do, not a verdict on intent. Risk score 30/100 (medium).
cc-switch 3.19.2
Automated static-analysis result. It can contain false positives and false negatives, and is not a claim about the intent of farion1231/cc-switch's authors. Report a false positive.
Behavioral traits
How this component maps to the CSA agentic threat model. Descriptive — it never affects the risk score.
Findings (4)
A command uses a known defense-evasion idiom: PowerShell execution-policy bypass / encoded command / hidden window, macOS code-signing bypass, or launching a payload from a world-writable temp directory. These are hallmarks of droppers and rarely appear in legitimate code. (3 occurrence(s) shown as evidence).
const HERMES_WINDOWS_INSTALL_COMMAND = `powershell -NoProfile -ExecutionPolicy Bypass -EncodedCommand ${powershellEncodedCommand(if (lower === "-encodedcommand" || lower === "-e" || lower === "-ec") {Fix: Verify why the component bypasses execution policy / code signing or runs from a temp directory; these patterns are characteristic of malware staging.
A server is bound to all network interfaces (0.0.0.0), not just your own machine.
addressTrimmed === "0.0.0.0" ||
bare === "0.0.0.0"
Why it matters: Without authentication, other hosts on the network can reach it.
Fix: Bind to 127.0.0.1 for local-only use, or require authentication and restrict access if remote exposure is intended.
The component makes outbound network requests.
const response = await fetch(MODELS_DEV_API_URL, {Why it matters: Usually legitimate, but confirm the destinations are expected and no sensitive data leaves.
Fix: Confirm the destination hosts are expected and that no sensitive data is sent off-host.
An OAuth 2.0 / OpenID Connect delegated-authentication flow was detected (authorization-code / refresh-token / token-exchange grant, an OIDC authorize/discovery endpoint or id_token, or a delegation library). Tools authenticate with the end user's delegated, scoped credentials rather than a long-lived embedded service credential. (4 occurrence(s) shown as evidence).
// 升级前登录的旧账号没有持久化 id_token，需重新登录补全
{/* 旧账号需重新登录提示（缺少 id_token） */}"为与浏览器登录行为保持一致，这些账号需要重新登录以补全所需的登录凭据（id_token）。重新登录后即可正常用于托管绑定。",
/** Codex-only: the account predates persisted id_token support. */
Fix: Delegated auth is a lower-blast-radius execution context than an embedded static credential. Confirm the requested scopes are minimal and that tokens are never logged or forwarded off-host.
Check your own component
Run the same evidence-backed scan on any MCP server, agent skill, or package.
Scan your own componentHow we determine this: deterministic static analysis (regex + AST), evidence-anchored, no code execution. Methodology →