Back to skill

Security audit

Merktop Wallet

Security checks for vulnerabilities and agentic risk

Overview

This payment skill is coherent, but it exposes a spending credential in its default URL examples and also points users to an unpinned executable package.

Review before installing. Use a very small spend cap, prefer the x-merktop-key header form instead of putting MERKTOP_BUYER_KEY in URLs, rotate any key already used in URL examples, and avoid the unpinned npx integration unless you pin and verify a specific trusted version.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:37
Finding

Buyer Credential Exposed in Request URL

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:37, with the same insecure pattern repeated at README.md:25
Vulnerability Type: Credential exposure through URL-based authentication
Risk Level: High

Vulnerable Code

SKILL.md:37:

bash
curl -s "https://facilitator.merktop.com/buyer/$MERKTOP_BUYER_KEY/pay?url=https://seller.example/api/data"

README.md:25:

bash
curl -s "https://facilitator.merktop.com/buyer/$MERKTOP_BUYER_KEY/pay?url=https://seller.example/api/data"

The project acknowledges the safer alternative at SKILL.md:50:

text
Security: you can also send the key as the `x-merktop-key` header to `https://facilitator.merktop.com/api/buyer/pay?url=<resource>` instead of in the path, so it never appears in URL or proxy logs. Both forms work.

Technical Analysis

The primary usage examples interpolate MERKTOP_BUYER_KEY directly into the request URL path. Authentication credentials in URLs can be exposed through facilitator access logs, reverse-proxy logs, observability systems, shell history, command auditing, error reports, screenshots, and process inspection while curl is running.

The documentation explicitly recognizes that header-based authentication prevents the key from appearing in URL or proxy logs, but it continues to promote path-based authentication as the default example. A spend cap limits the maximum financial loss but does not prevent unauthorized use within that cap.

Attack Path

  1. A user or agent follows the documented command.
  2. The shell expands $MERKTOP_BUYER_KEY into the URL.
  3. The complete URL is observed or retained by a process monitor, command logger, facilitator, reverse proxy, telemetry platform, or another party with access to logs.
  4. An attacker extracts the mk_buyer_... credential.
  5. The attacker submits requests to the Merktop buyer payment endpoint using the exposed key.
  6. Unauthorized paid requests c ...[truncated 718 chars]
Remediation
View remediation

Remediation Suggestions

  • Remove path-based buyer-key authentication from all documentation and examples.

  • Require the buyer key to be supplied through the x-merktop-key request header:

    bash
    curl -s \
      -H "x-merktop-key: $MERKTOP_BUYER_KEY" \
      "https://facilitator.merktop.com/api/buyer/pay?url=https://seller.example/api/data"
    
  • Deprecate and ultimately disable the /buyer/<key>/pay endpoint form.

  • Configure servers, proxies, tracing systems, and error handlers to redact authentication headers and sensitive URL components.

  • Avoid enabling shell command tracing when commands contain credentials.

  • Rotate buyer keys that have previously been used in URLs and review access logs for unexpected usage.

  • Add short-lived or narrowly scoped credentials, rate limits, recipient restrictions, usage alerts, and immediate revocation support as defense-in-depth controls.

T08 · Insecure Dependencies

Warning
Location
README.md:34
Finding

Unpinned Third-Party Package Execution Through npx

Content
View full analysis

Vulnerability Details

File Location: README.md:34
Vulnerability Type: Unpinned and mutable third-party dependency execution
Risk Level: Medium

Vulnerable Code

text
- MCP (alternative integration): `npx @merktop/mcp`

Technical Analysis

The documented npx command does not specify an exact package version or integrity value. Depending on the local npm configuration and cache state, npx may retrieve a current package release from the configured registry and execute package lifecycle or runtime code locally.

Because the selected release can change after this Skill has been reviewed, the effective code executed by users is mutable and is not present in the audited project. The audit therefore cannot verify the behavior of the package selected at execution time. Registry-account compromise, malicious package publication, or a compromised future release could turn the documented command into an arbitrary local code-execution channel.

No evidence in the audited files demonstrates that @merktop/mcp is currently malicious. The finding concerns the unsafe, unpinned execution pattern.

Attack Path

  1. A user follows the alternative integration command from the README.
  2. npx resolves @merktop/mcp using the user's configured npm registry.
  3. If no trusted local copy is available, package content is downloaded.
  4. A compromised registry account, malicious release, registry redirection, or compromised dependency supplies attacker-controlled code.
  5. npx executes the package under the invoking user's account.
  6. The malicious code accesses resources available to that user, subject to operating-system and environment restrictions.

Impact Assessment

A compromised package could execute arbitrary commands with the privileges of the user running npx. Depending on that user's environment, this may expose environment variables such as MERKTOP_BUYER_KEY, local files, application crede ...[truncated 276 chars]

Remediation
View remediation

Remediation Suggestions

  • Pin the integration to a reviewed exact version rather than resolving the current release:

    bash
    npx --yes @merktop/mcp@<reviewed-exact-version>
    
  • Prefer installation through a committed lockfile with package integrity metadata.

  • Verify package provenance, registry source, publisher identity, signatures or attestations, and checksums before execution.

  • Disable unnecessary npm lifecycle scripts where compatible with the package.

  • Run the integration as an unprivileged user in a sandbox or container with minimal filesystem, network, and environment-variable access.

  • Do not expose MERKTOP_BUYER_KEY or unrelated credentials to the package unless they are strictly required.

  • Establish a dependency-review and update process so each new package version is audited before the documented pin is changed.

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (3)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The README shows the Merktop buyer key being placed directly in a URL path, which risks credential exposure through shell history, process listings, logs, browser history, proxies, analytics, and server access logs. Because the key authorizes payments, disclosure could let an attacker initiate spending within the configured cap, making this especially dangerous in an agent-payment context.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
88% confidence
Finding

The README instructs users to run an unpinned package via npx @merktop/mcp, which fetches and executes the latest published code at runtime. If the package is compromised, a malicious version is published, or a dependency is hijacked, users and agents could execute attacker-controlled code with their local privileges.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 12)May include surrounding context.

md
primaryEnv: MERKTOP_BUYER_KEY
    requires:
      anyBins:
        - curl
      env:
        - MERKTOP_BUYER_KEY
    envVars: