gate-mcp-installer

SUSPICIOUS: Most behavior matches an installer skill, but trust boundaries are inconsistent. Gate-owned MCP endpoints are coherent, yet the optional merchant-discovery server uses an unrelated plaintext third-party domain, and the skill expands scope by installing/cloning additional tooling and skills. Not confirmed malware, but medium-high security risk due to third-party supply-chain and data-flow concerns.

The fragment primarily performs legitimate MCP installation and configuration, but presents moderate supply-chain and credential-handling risk. The most notable concerns are the hardcoded DEX API-key-like value, plaintext persistence and command-line handling of API credentials, execution of packages through npx, global npm installation, and recursive installation of unpinned remote skills without integrity verification. No clear malware, exfiltration, reverse shell, or system-damage behavior is visible in this portion. The hardcoded key should be verified and rotated if it is a real credential, and remote repositories/packages should be pinned and integrity-checked.

No direct malicious behavior is demonstrated in the supplied configuration. The primary risks are automatic execution of an unpinned npm package via npx and exposure of wallet credentials to that package. Use a verified, pinned package version with integrity controls and avoid supplying real private keys unless the package is trusted and isolated.

No direct malicious behavior is evidenced in the supplied configuration. However, it automatically executes an npm package via `npx -y` and exposes wallet credentials, creating a meaningful supply-chain and credential-compromise risk if the package or its dependencies are malicious or compromised.

The fragment is a remote MCP service configuration. It contains a hardcoded credential-like API key and forwards an environment-sourced bearer token to a third-party endpoint. This is a credential-management and external-data-sharing concern, but the fragment alone does not demonstrate malware or intentional sabotage. The hardcoded key should be revoked or rotated and replaced with secure secret management; the endpoint and required data access should be independently verified.

The configuration does not itself contain malware, but it directs an MCP client to an external endpoint over plain HTTP. Use of HTTPS and verification of the domain and server authorization are recommended before deployment.

The fragment contains no demonstrable malware, but it introduces an external MCP dependency over unencrypted HTTP. Use of this endpoint should be reviewed, authenticated as appropriate, and migrated to a trusted HTTPS endpoint before deployment. The remote server implementation and MCP permissions are required for a complete assessment.