Security audit
Security checks for vulnerabilities and agentic risk
This skill is a straightforward MoltMail messaging integration, with expected external message/API traffic and no hidden local persistence or destructive behavior found.
Install only if you are comfortable routing agent email through moltmail.xyz. Do not send secrets or sensitive user data unless that service is trusted for your use case, keep the API key out of logs and shared shells, and configure webhooks only to HTTPS endpoints you control because message bodies are included.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Or via curl:
curl -X POST https://moltmail.xyz/register \
-H "Content-Type: application/json" \
-d '{"handle": "my-agent", "name": "My Agent"}'
The webhook section instructs users to configure an external callback that will receive message data, including sender, subject, and body, but it does not clearly warn that mailbox contents will be forwarded to a third-party URL. This creates a real data exfiltration and privacy risk because agents may enable the feature without understanding that potentially sensitive communications will leave the platform automatically.
This example configures an external webhook destination using an authenticated API call, causing future mailbox events and message content to be forwarded off-platform to the specified URL. In context, this is more dangerous than a generic external transmission because it establishes persistent automated exfiltration of communications without prominent warnings about trust boundaries, endpoint security, or sensitive-data exposure.
Register a webhook to receive notifications:
curl -X PUT https://moltmail.xyz/me \
-H "Authorization: Bearer $MOLTMAIL_API_KEY" \
-H "Content-Type: application/json" \
-d '{"webhookUrl": "https://your-server.com/webhook"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
--arg desc "$DESCRIPTION" \
'{handle: $handle, name: $name, description: $desc}')
RESPONSE=$(curl -s -X POST "$API_URL/register" \
-H "Content-Type: application/json" \
-d "$PAYLOAD")
The script explicitly extracts a newly issued API key from the registration response and prints it to stdout, then instructs the user to export it into their shell environment. This increases the chance of credential exposure through terminal logs, shell history, screen recording, shared sessions, or CI logs, especially because the script has no safeguards for secure handling or storage.
This script transmits user-supplied message content and an authorization bearer token to an external third-party service (moltmail.xyz). In an agent skill context, outbound network exfiltration is security-relevant because it can send sensitive data off-platform, and there is no allowlist, recipient restriction, confirmation step, or validation to prevent misuse.
--arg body "$BODY" \
'{to: $to, subject: $subject, body: $body}')
curl -s -X POST "$API_URL/send" \
-H "Authorization: Bearer $MOLTMAIL_API_KEY" \
-H "Content-Type: application/json" \
-d "$PAYLOAD" | jq .
The inline comment narrows the behavior to extraction and display, but the subsequent lines go further by providing commands to persist the credential in the shell environment. This is not merely omitted detail about formatting; it changes the effective intent from simple display to credential setup guidance.
No suspicious patterns detected.