farion1231/cc-switch

Why it got this result

Extensively reviewed every std::process::Command call site in src-tauri/src (terminal launch, tool install/update lifecycle, WSL execution, mcode/codex installers). The two highest-risk candidates are hardened: (1) run_tool_lifecycle_silently/build_tool_lifecycle_command executes installer commands, but tool/action are validated against a fixed VALID_TOOLS allowlist (normalize_requested_tools) before any command string is built, and install/update command strings are built entirely from hardcoded consts (CLAUDE_INSTALL_UNIX, etc.) -- no caller-supplied string is spliced into the shell command. (2) WSL distro/shell/shell-flag inputs (which DO come from frontend WslShellPreferenceInput) are validated by is_valid_wsl_distro_name/is_valid_shell/is_valid_shell_flag allowlists before being placed into a wsl.exe -d <distro> -- <shell> <flag> <command> argv (not a shell string), rejecting anything with shell metacharacters. The one unescaped-shell-interpolation path found (launch_custom/'{command}' template substitution in terminal/mod.rs) is explicitly documented as UNREACHABLE dead code (no UI wires a 'custom' terminal target or customConfig), confirmed by grep showing launch_session_terminal never passes 'custom'/'Some(custom_config)' from the frontend.

Why it matters

Unsanitized command construction in shipped runtime code can give a remote attacker arbitrary code execution with the application's privileges.

Evidence

const VALID_TOOLS: [&str; 9] = [
    "claude", "codex", "gemini", "grok", "opencode", "openclaw", "hermes", "pi", "mcode",
];

fn normalize_requested_tools(tools: &[String]) -> Vec<&'static str> {
    let set: std::collections::HashSet<&str> = tools.iter().map(|s| s.as_str()).collect();
    VALID_TOOLS
        .iter()
        .copied()
        .filter(|tool| set.contains(tool))
        .collect()
}

fn build_wsl_tool_action_line(distro: &str, command: &str, force_shell: Option<&str>, force_shell_flag: Option<&str>) -> Result<String, String> {
    if !is_valid_wsl_distro_name(distro) { return Err(...); }
    let shell = force_shell.map(...).unwrap_or("sh");
    if !is_valid_shell(shell) { return Err(...); }
    ...
    Ok(format!("wsl.exe -d {distro} -- {shell} {flag} {}", windows_cmd_double_quote_arg(command)))
}

+1 more location in the finding JSON

Why it got this result

cc-switch's declared and actual purpose (per README.md, package.json, and the entire codebase) is a legitimate developer productivity tool: switching between AI coding CLI provider configurations (Claude Code, Codex, Gemini CLI, etc.), managing MCP server/skill/prompt configs, and local proxying of API traffic between a developer's own tools and their own configured providers. No component advertises, implements, or instructs generation of malware, exploits, credential-harvesting, mass-abuse, or any offensive capability. The single YARA hit (Zeus_Agent_Remote_Bootstrap_Execution_WideSpan, confidence 25, described by the scanner itself as 'likely coincidental co-occurrence, not a pipeline') was manually reviewed in misc.rs lines 373-608: the flagged 'download'/'pipe_shell'/'quiet' identifiers are legitimate, user-initiated CLI tool installer plumbing (e.g. running the official claude/codex/hermes CLI install scripts via curl-to-tempfile-then-bash, explicitly NOT curl | bash per in-code comments, gated behind the VALID_TOOLS allowlist and an explicit user-triggered 'install/update' action) -- not a remote-bootstrap attack primitive serving an attacker.

Why it matters

An artifact whose purpose is to weaponize the agent -- to produce malware, steal credentials, evade defenses, or run attacks at scale -- is dangerous regardless of how securely it is built; posture controls (auth, input validation, least privilege) cannot make a weapon safe, which is why a confirmed weaponization finding caps the trust verdict to `blocked` rather than being averaged against a good posture score. Catching malicious PURPOSE is a distinct safety control, and it must be conservative because offensive capability is dual-use: legitimate pentest, CTF, defensive, and research work must abstain (UNKNOWN), never block -- unless the artifact itself hides from the people who install, run or audit it.

Evidence

/// 官方 shell installer 都不用 `curl | bash` 这种 pipe 形式(仍然用 curl 下载,
/// 只是先落到临时文件再交给 bash 执行)
const CLAUDE_INSTALL_UNIX: &str =
    "bash -c 'tmp=$(mktemp) && curl -fsSL https://claude.ai/install.sh -o $tmp && bash $tmp; status=$?; rm -f $tmp; exit $status'";

pub async fn run_tool_lifecycle_action(
    tools: Vec<String>,
    action: String,
    ...
) -> Result<(), String> {
    let requested = normalize_requested_tools(&tools);
    if requested.is_empty() { return Err("No supported tools selected".to_string()); }
    ...

Why it got this result

The one clearly attacker-influenced outbound-fetch surface (deep-link iconUrl, fully attacker-controlled via a ccswitch:// URL) is hardened against SSRF: https-only, no credentials/non-default port, DNS resolution restricted to public (non-RFC1918/loopback/link-local/CGNAT/multicast) addresses with address pinning across redirects, max 3 redirects each re-validated, 5s timeout, 256KB cap, no proxy, no cookies/referrer. Other outbound calls (model_fetch.rs, proxy/forwarder.rs) target user-configured provider base URLs that the local user explicitly typed into their own provider profile (an admin/owner input, not a remote attacker's), consistent with the app's threat model as a local desktop tool.

Why it matters

Enables internal pivoting and data exfiltration.

Evidence

/// 链接里的 `iconUrl` 形状是否可用：https、域名主机、默认端口、没有账号密码。
/// 解析阶段用它过滤，下载时每一跳重定向也再过一遍。
pub(crate) fn parse_icon_url(raw: &str) -> Option<Url> {
    let raw = raw.trim();
    ...
        return None;
    }
    let url = Url::parse(raw).ok()?;
    !(a == 0 || a == 10 || a == 127 || (a == 100 && (64..128).contains(&b)) ...)
        || !url.username().is_empty()

/// 解析域名，要求每个地址都是公网地址。有一个不是就整体拒绝，不挑着用。
    let addrs: Vec<SocketAddr> = tokio::net::lookup_host((domain.as_str(), 443)).await...;
    if let Some(addr) = addrs.iter().find(|addr| !is_public_ip(addr.ip())) { return Err(...); }
    ...
    };
    let domain = domain.to_string();
    ... .resolve_to_addrs(&domain, &addrs) ... .redirect(reqwest::redirect::Policy::none()) ...

Why it got this result

gitleaks (20 findings) and semgrep's google-oauth-token rule (21 findings) flagged only fixture/test values: unit-test constants in auth.rs/codex.rs/gemini.rs (e.g. 'ya29.access-token-12345', 'sk-test-key-12345678') used to test masking/parsing logic, and the deeplink.html generator which is a client-side form template whose placeholder example values (e.g. 'AIzaSy-test-key123') are for documentation/demo purposes in a static HTML generator page, not runtime secrets. No live API keys, private keys, or credentials were found committed to the repo.

Why it matters

Plaintext secrets are easily exfiltrated.

Evidence

#[test]
    fn test_auth_info_with_access_token() {
        let auth = AuthInfo::with_access_token(
            "refresh-token".to_string(),
            "ya29.access-token-12345".to_string(),
        );
        assert_eq!(auth.api_key, "refresh-token");
        assert_eq!(auth.strategy, AuthStrategy::GoogleOAuth);

GEMINI_API_KEY": "[REDACTED]"  <!-- example payload shown in a static HTML usage-script generator, not a real credential -->

+19 more locations in the finding JSON

Why it got this result

Reviewed the main attacker-reachable input boundaries: deep-link (ccswitch://) import parsing validates resource type, required fields, URL scheme (utils::validate_url restricts to http/https), and Base64 decoding with explicit error handling (deeplink/utils.rs, deeplink/provider.rs); workspace file commands use fixed filename allowlists (ALLOWED_FILES) and regex-validated daily-memory filenames; skill install paths sanitize path components rejecting '.', '..', and absolute/prefixed segments (sanitize_skill_source_path, sanitize_install_name). Tauri commands take typed/serde-deserialized structs which reject malformed JSON shapes at the IPC boundary. No evidence of raw/untyped user input reaching sensitive sinks without a validation step.

Why it matters

Frontline control to prevent multiple classes of vulns.

Evidence

pub fn validate_url(url_str: &str, field_name: &str) -> Result<(), AppError> {
    let url = Url::parse(url_str)...;
        .map_err(|e| AppError::InvalidInput(format!("Invalid URL for '{field_name}': {e}")))?;
    if scheme != "http" && scheme != "https" { return Err(...); }
    let scheme = url.scheme();
    if scheme != "http" && scheme != "https" {

const ALLOWED_FILES: &[&str] = &["AGENTS.md", "SOUL.md", ...];
fn validate_filename(filename: &str) -> Result<(), String> {
    if !ALLOWED_FILES.contains(&filename) { return Err(...); }
    Ok(())
}

Why it got this result

All deserialization observed uses serde_json (and serde-derived structs) for JSON parsing of deep-link payloads, provider/MCP configs, and proxy request/response bodies. Rust's serde_json is a memory-safe, schema-driven deserializer with no reflective/gadget-chain execution capability (unlike Python pickle, Java ObjectInputStream, or PHP unserialize), so even fully attacker-controlled JSON cannot achieve code execution via deserialization alone. No use of unsafe deserializers (bincode from untrusted sources, serde_yaml of untrusted remote content, eval-based parsing) was found reachable from attacker-controlled input.

Why it matters

Can lead to arbitrary code execution.

Evidence

// Parse JSON
    let config_json: Value = serde_json::from_str(&config_str)
        .map_err(|e| AppError::InvalidInput(format!("Invalid JSON in MCP config: {e}")))?;

Why it got this result

Enumerated the caller-supplied-path entry points: (1) skill install source paths -- sanitize_skill_source_path rejects '.', '..', absolute/root/prefix components, normalizing to only Normal path segments; (2) skill install names -- sanitize_install_name additionally rejects '/' and '\\' literal characters (to prevent Windows-vs-Unix separator semantic mismatches) and leading-dot names; (3) workspace file commands -- fixed ALLOWED_FILES allowlist / regex-anchored daily-memory filename pattern, no path join from raw caller input; (4) zip/archive extraction (skill repo download and local-zip import) -- uses enclosed_name() as a first gate AND an explicit second check rejecting any Component::ParentDir in the post-root-stripped relative path (the code comments show the developer specifically reasoned through and closed the 'repo-main/../evil' bypass that enclosed_name() alone would miss), plus symlink-target self-containment verification before resolving symlink entries. Each entry point is covered by either an allowlist or a structural traversal/symlink gate; the implementation explicitly documents and defends against partial-mitigation bypass patterns.

Why it matters

Traversal exposes arbitrary host files; can lead to code execution.

Evidence

fn sanitize_skill_source_path(raw: &str) -> Option<PathBuf> {
    ...
    for component in Path::new(trimmed).components() {
        match component {
            Component::Normal(name) => { ... }
            Component::CurDir | Component::ParentDir | Component::RootDir | Component::Prefix(_) => { return None; }
        }
    }

// GitHub 归档统一带一层 `<repo>-<branch>/` 根目录，需剚掉后再落盘。
 let Ok(relative_path) = safe_path.strip_prefix(&root_name) else { continue; };
 // 第二道：enclosed_name() 的保证是相对归档根的，且它不规范化路径
 if relative_path.components().any(|c| matches!(c, Component::ParentDir)) {
     log::warn!("跳过越界的压缩包条目: {}", file.name());
     continue;
 }

Why it got this result

Reviewed all .github/workflows/*.yml run: blocks for direct interpolation of attacker-controlled ${{ github.event.* }} expressions (the classic script-injection pattern). None of the run: steps embed untrusted event fields directly; the claude.yml workflow passes PR/issue author-association gated conditions only in the if: trigger expression (not a shell context) and forwards free-text comment bodies only as a system-prompt argument to the claude-code-action tool (not executed as shell), with explicit --disallowedTools Edit,Write,MultiEdit,NotebookEdit and 'Never modify files, push commits, or create PRs' to constrain the agent. Semgrep's 34 'mutable-action-tag' findings (pinning actions by tag rather than SHA) are a supply-chain hardening gap, not an injection vulnerability, and are lower severity than this rule's injection threat model.

Why it matters

CI/CD script injection can execute attacker-controlled commands with workflow tokens, repository secrets, trusted-runner access, artifact or cache authority, and release or deployment privileges.

Evidence

      ((github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude') &&
        (github.event.comment.author_association == 'OWNER' ||
        (github.event.comment.author_association == 'OWNER' ...)))
         github.event.comment.author_association == 'COLLABORATOR'))
       ||
       (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude') &&
        (github.event.comment.author_association == 'OWNER' ||
         github.event.comment.author_association == 'MEMBER' ||
         github.event.comment.author_association == 'COLLABORATOR'))

      - name: Run Claude (review only)
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          claude_args: >-
            --model claude-opus-4-7
            --disallowedTools Edit,Write,MultiEdit,NotebookEdit

Why it got this result

The codebase shows deliberate log-redaction engineering: icon_fetch.rs strips full URLs (which may carry CDN signature tokens) from reqwest errors before logging via describe_request_error()/url_for_log(), with an explicit unit test asserting a secret query-param token does not leak into the logged string. This reflects a project-wide pattern of treating request errors as a logging-injection surface and redacting it.

Why it matters

Prevents sensitive data leakage; enables forensics.

Evidence

/// reqwest 的错误文本自带完整 URL（含查询参数，可能是 CDN 签名或令牌），而重定向之后的
/// 地址也没经过 `url_for_log`。去掉 URL，只留错误类型和底层原因写进日志。
fn describe_request_error(error: reqwest::Error) -> String {
    let error = error.without_url();
    let mut text = error.to_string();

async fn request_errors_leave_the_url_out_of_the_log() {
        ... .get("http://127.0.0.1:9/logo.png?token=SECRET_TOKEN") ...
        assert!(error.to_string().contains("SECRET_TOKEN"));
        let described = describe_request_error(error);
        assert!(!described.contains("SECRET_TOKEN"), "{described}");

Why it got this result

The single dangerouslySetInnerHTML sink in the React frontend (ProviderIcon.tsx) renders SVG strings sourced exclusively from the app's own bundled icon registry (@/icons/extracted via getIcon()/hasIcon()), gated so that custom-icon and URL-based icons are routed to an <img src=...> element instead (which does not execute inline content) rather than dangerouslySetInnerHTML. No user-controlled or remote string is ever passed to dangerouslySetInnerHTML. React's default JSX text rendering elsewhere auto-escapes output.

Why it matters

Prevents UI-level injection and operator compromise.

Evidence

const iconSvg = useMemo(() => {
    if (icon && !isCustomIcon(icon) && !isUrlIcon(icon) && hasIcon(icon)) {
      return getIcon(icon);
    }
    return "";
  }, [icon]);

  if (iconSvg) {
    return (
      <span ... dangerouslySetInnerHTML={{ __html: iconSvg }} />
        className={cn(
          "inline-flex items-center justify-center flex-shrink-0",
          className,
        )}
      <img src={iconUrl} onError={...} alt={name} ... />
        style={{ ...sizeStyle, color: effectiveColor }}
        dangerouslySetInnerHTML={{ __html: iconSvg }}

Why it got this result

cc-switch is not an MCP server or agent framework that invokes tools and injects their return values into an LLM's system/developer prompt context. It is a transparent HTTP reverse-proxy/passthrough between a locally-running CLI (Claude Code, Codex, etc.) and the configured upstream provider API -- request/response bodies are forwarded (with format adaptation between provider API dialects) but cc-switch itself does not originate tool calls, execute tools, or construct LLM prompts/context. The rule's threat model (tool-output-to-prompt injection containment) does not have an applicable analog in this component's architecture.

Why it matters

Tool outputs are a primary prompt-injection vector. Third-party content (web pages, files, API responses) may contain text crafted to override instructions or impersonate system/tool messages. Without a host-enforced envelope, sanitization, and an explicit untrusted-return signal, the model can be coerced into executing attacker-controlled directives, leaking secrets, or chaining further tool calls on behalf of the adversary.

Why it got this result

This is a Tauri desktop application (macOS/Windows/Linux native installer: .dmg/.msi/.deb/flatpak) with no Dockerfile, docker-compose, Kubernetes manifests, or other container/IaC artifacts found in the repository. Trivy config scan (trivy-config.json) returned zero findings, confirming no IaC surface exists. The rule's container-hardening threat model (securityContext, capabilities, mounts, exposed ports in container orchestration) does not apply to a locally-installed desktop binary.

Why it matters

Reduces blast radius of exploits.