gdex-trading

No direct malware or obfuscated behavior can be proven from this lockfile-only fragment. The primary security concern is a trust-boundary and install-time execution risk: @gdexsdk/gdex-skill is pulled via a local "file:.." dependency and is marked as having an install script. This warrants inspecting the local package’s lifecycle scripts and source/bundled output (and then validating the mcp-server runtime entrypoint dist/index.js) for any network exfiltration, filesystem/process access, or credential handling. Until those are reviewed, treat this as moderate supply-chain risk rather than benign.

The shown code is a typical inter-service API call pattern, but it forwards highly sensitive fields from incoming request data (notably sessionPrivateKey and apiKey) into the outbound POST payload. This is not definitive proof of malware, but it is a significant security concern: unless the remote endpoint legitimately requires these secrets and transport/authorization are tightly controlled, the pattern resembles credential leakage/exfiltration risk. More surrounding context is needed to confirm protocol intent and whether these secrets are server-derived rather than client-supplied.

SUSPICIOUS. The skill's UI/dashboard examples are broadly aligned with its stated purpose and do not contain malware-like execution paths, but the documented raw-client workaround pushes `sessionKey` and `apiKey` into frontend code and relies on unverified SDK/API provenance. That creates a medium security risk from credential exposure and uncertain data-flow trust, even though the skill is not fundamentally malicious.

SUSPICIOUS: The skill is internally coherent for managed-custody HyperLiquid perp trading, but it carries medium-high security risk because it forwards highly sensitive trading credentials through a Gemach intermediary backend and enables real financial actions. The npm dependency appears plausibly official, so this is not confirmed malware, but the non-official skill distribution path and custody/intermediary data flow warrant caution.

SUSPICIOUS: The skill’s wallet/auth UI scope is broadly consistent with its stated purpose, but it normalizes client-side API-key use, includes a shared-key quick-connect path, and relies on an SDK/package that could not be independently verified from the provided evidence. No explicit malware, exfiltration service, or installer chain is present, but the combination of trading context, managed custody, and unverifiable SDK provenance makes the overall risk medium.

The skill’s stated purpose (cross-chain spot trading with automatic DEX routing and optional managed-custody payloads) is aligned with the described buy/sell flows and managed-trade paths. However, the implementation relies on external SDKs and backend services, uses API keys and session/private keys in examples, and involves encrypted payloads and custody workflows. These data flows and credential exposures are plausible for legitimate functionality but introduce meaningful security risks due to credential handling, external data sinks, and custody-related cryptographic data. The footprint is therefore SUSPICIOUS rather than clearly BENIGN, given the sensitivity of keys, the reliance on third-party components, and the potential for leakage or misuse if proper safeguards are not enforced.

Mostly coherent frontend setup guidance for a crypto trading SDK, with normal npm-based scaffolding and expected React provider patterns. Main concerns are the inclusion of realistic embedded API keys, partially unverifiable provenance for the GDEX package from the supplied evidence, and support for real trading actions without visible safety guardrails; this is suspicious rather than clearly malicious.

No active malware constructs found (no remote shell, no dynamic code execution, no process spawning). However, the code contains hardcoded sensitive information (API_KEY and a WIF-like private key) and transmits that sensitive data as query parameters and in Authorization headers to an external API (https://trade-api.gemach.io). This is a significant supply-chain / credential-leak risk: if the WIF is a private key it could lead to compromise of associated funds/accounts. Remove hardcoded secrets, use secure secret management, and avoid sending private keys as query parameters or printing them to logs.

This script does not contain typical malware constructs (no remote shell, no obfuscated payload, no code-injection primitives), but it includes hardcoded sensitive credentials (mnemonic and API key) and transmits signatures and auth tokens to an external API. That makes it a high confidentiality risk: exposing the mnemonic/API key can lead to wallet compromise and unauthorized transactions. Treat this code as insecure for production use and remove hardcoded secrets; store secrets in secure environment variables and avoid logging secrets. Review the remote API domain and CryptoUtils implementation before use.

This file itself is not malicious: it contains no obfuscated code, no dynamic code execution, no explicit credential exfiltration routines, and no suspicious domains. However, it performs high-impact financial actions using secrets (session private key and API key) and relies on an imported SDK ('../src') to perform all networked operations. Primary risks: (1) accidental execution causing real fund movement due to lack of confirmation safeguards, (2) credential leakage via logs or process memory, and (3) supply-chain risk if the GdexSkill implementation is compromised. Recommendation: review and audit the '../src' SDK implementation before running; avoid embedding production secrets in CI or developer environments; add interactive confirmations or dry-run flags for destructive operations; avoid logging sensitive values and consider ephemeral/rotating keys or hardware-backed signing for session_private_key.

The code embeds sensitive credentials and actively derives candidate keys to potentially reveal the private key for a targeted address, printing private keys upon match. This behavior is highly risky for production and undermines supply-chain security principles. Recommend removing hardcoded secrets, eliminating private-key printing, securing secret handling (environment variables, vaults), restricting external API interactions, and adding strict access controls and input validation.

The code is not performing malicious actions per se, but it contains high-risk credentials (mnemonic and API key) that could lead to asset compromise if exposed. The balance probing across multiple chains increases privacy exposure and surface area for misuse. Recommend removing hardcoded secrets, migrating to secure environment management (vaults, env vars), implementing proper error handling (logging and retry/backoff), and validating API responses to guard against malformed data.

SUSPICIOUS. The core capabilities match the stated social/watchlist purpose, and there is no direct evidence of malware or overt exfiltration to unrelated domains. However, the skill is higher risk than a normal read-only API wrapper because it forwards very sensitive auth material—including a session private key—into third-party SDK code and enables public write actions on the user’s behalf.

This script is an unauthenticated-looking (but bearer-authenticated) endpoint enumerator for a trading API that embeds a hardcoded API key and actively probes many endpoints including potential state-changing ones. Primary security issues: (1) hardcoded API key -> immediate secret leakage and potential unauthorized access if the key is valid; (2) automated POSTs to transactional endpoints could trigger unintended actions if the API accepts empty payloads; (3) lack of rate-limiting and lack of authorization checks makes the tool potentially abusive. There is no evidence of classical malware (reverse shell, persistence, obfuscation, or system damage) within this file, but the code is dangerous in the sense of credential leakage and active probing. Recommended actions: remove the hardcoded key, rotate the key immediately if it has been committed or published, restrict probe scope and use safe, read-only endpoints or dedicated test credentials, and add safeguards (confirmation steps, rate limiting, non-destructive test payloads).

SUSPICIOUS. The skill's behavior mostly matches its stated purpose and uses an apparently first-party API flow, but it forwards sensitive auth material, including a session private key, into an SDK whose public provenance and release verification are only partially established from the available evidence.

SUSPICIOUS: the skill's purpose is coherent, but it routes HyperLiquid referral actions and API credentials through a GDEX-managed SDK/backend rather than direct official Hyperliquid APIs, expanding trust requirements. This looks more like a managed intermediary integration than obvious malware, with moderate risk driven by credential forwarding and partially unverified package provenance.