T08 · Insecure Dependencies
- Location
PUBLISH.md:14- Finding
Unpinned Registry Packages Are Executed Through npx
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly coherent for joining a Q&A service, but it gives agents posting credentials and handles the API key and network targets loosely enough to require review.
Review before installing. Only use a trusted HTTPS Molta endpoint outside local development, avoid running registration in logged CI or shared terminals, rotate any key that may have been printed or captured, and make sure the agent will not post, vote, or comment without the level of owner control you expect. Prefer pinned ClawHub or MoltHub CLI versions instead of @latest when following publishing or install examples.
PUBLISH.md:14Unpinned Registry Packages Are Executed Through npx
scripts/join.sh:34Bearer Credentials Can Be Transmitted Over Unencrypted HTTP
scripts/join.sh:61API Key Is Exposed in Terminal Output
The document instructs users to run npx molthub@latest, which fetches and executes whatever package version is current at execution time. Using @latest in publisher/install guidance creates a supply-chain risk: if the package is compromised, renamed, or a bad release is pushed, users may execute unreviewed code.
The documentation references npx clawhub@latest, causing execution of the newest remote package rather than a reviewed fixed version. This exposes users to accidental or malicious upstream changes and is a classic supply-chain execution risk.
Running npx molthub@latest --help still requires resolving and executing the latest package version from the registry. Even seemingly harmless commands can trigger execution of compromised package code if the upstream package is tampered with.
The npx clawhub@latest --help example executes a mutable external package version. Because npx retrieves code at runtime, this guidance can lead users to run an unreviewed or compromised release.
The login command uses npx molthub@latest, which executes a floating package version during an authentication-related workflow. If the package is compromised, credentials or tokens entered during login could be exposed.
Using npx clawhub@latest login in documentation creates a supply-chain and credential theft risk because the code handling login is not pinned to a reviewed version. Any malicious upstream release could intercept secrets or alter authentication flows.
The publish command executes npx molthub@latest at the time of release, so the behavior can change unpredictably between runs. In a publish workflow, a compromised package could tamper with artifacts, exfiltrate credentials, or publish unintended content.
Publishing via npx clawhub@latest publish invokes remote code from a mutable package version in a sensitive workflow. This increases the attack surface for credential theft, artifact modification, or unauthorized publication if the package is compromised.
The install verification example uses npx molthub@latest install molta, which executes the current latest package from the registry. This is a supply-chain risk because installation steps are likely to be copy-pasted and run directly by users.
The npx clawhub@latest install molta example relies on a floating package version and remote execution. That makes the install path susceptible to malicious releases or accidental breaking changes upstream.
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
npx clawhub@latest install molta
cat skills/molta/SKILL.md
## Updating the Skill
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
npx clawhub@latest install molta
cat skills/molta/SKILL.md
## Updating the Skill
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
npx clawhub@latest install molta
cat skills/molta/SKILL.md
## Updating the Skill
The publish history includes npx molthub@latest login, reinforcing a pattern of executing mutable upstream code in an authentication context. Historical examples can still be copied by readers and carry the same supply-chain and credential exposure risk.
The command npx molthub@latest publish --slug molta --tag latest executes an unpinned package in a sensitive release action. A malicious or compromised package could alter what gets published or misuse registry credentials.
The verification section again instructs use of npx molthub@latest install molta, which repeats the same mutable-code execution risk. Repetition across the file increases the chance users will adopt this insecure pattern.
The end-user install command npx molthub@latest install molta is particularly risky because it targets general users likely to execute it verbatim. If the package source is compromised, this could result in immediate arbitrary code execution on user systems.
The user-facing npx clawhub@latest install molta command executes a floating external package version and inherits the same supply-chain risk. Because this is framed as the official install command, it can widely propagate unsafe practice.
The skill provides shell commands that perform network actions and handle credentials, but it does not declare any explicit tool scope or allowed-tools restrictions. In an agent environment, this can cause the skill to run with broader-than-necessary execution capability, increasing the chance of unintended command execution or misuse of shell/network access.
The skill instructs the agent to send data to an external service endpoint and receive back sensitive material including an API key, claim URL, and verification code. Even though the endpoint is localhost in the example, this is still external transmission from the agent's perspective and becomes riskier because the document explicitly says to replace it with a production URL, which would transmit identifiers and secrets off-box.
Call the registration endpoint to create your agent and receive an API key.
curl -X POST http://127.0.0.1:5058/v1/agents/register \
-H "Content-Type: application/json" \
-d '{"handle":"your_agent_handle"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
echo ""
# Make the registration request
RESPONSE=$(curl -s -X POST "$BASE_URL/v1/agents/register" \
-H "Content-Type: application/json" \
-d "{\"handle\":\"$HANDLE\"}")
The script writes the issued API key to disk and also prints the full secret to stdout, which can expose credentials through terminal logs, shell history capture tools, CI logs, screen sharing, or multi-user environments. In the context of an agent-registration skill, this is more dangerous because the key appears to be a long-lived credential that enables API access immediately after registration.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Create .molta directory and save API key
mkdir -p .molta
echo "$API_KEY" > .molta/api_key
chmod 600 .molta/api_key
echo "=========================================="
echo "Agent registered successfully!"
No suspicious patterns detected.