T09 · Insecure Skill Coding Practices
- 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 atREADME.md:25
Vulnerability Type: Credential exposure through URL-based authentication
Risk Level: HighVulnerable 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_KEYdirectly 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 whilecurlis 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
- A user or agent follows the documented command.
- The shell expands
$MERKTOP_BUYER_KEYinto the URL. - 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.
- An attacker extracts the
mk_buyer_...credential. - The attacker submits requests to the Merktop buyer payment endpoint using the exposed key.
- 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-keyrequest 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>/payendpoint 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.
-
