ClawHub
Back to skill

Security audit

MoltAuth

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent MoltAuth integration guide, but its examples encourage risky private-key handling and unpinned package installs that users should review before following.

Before installing or using this skill's examples, pin and verify the moltauth package version where possible, install in a least-privileged environment, and do not print, log, paste, or commit generated private keys. Store keys in a secret manager, OS keychain, or tightly permissioned local secret store and rotate any key that may have appeared in logs.

A.I.G

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)

T08 · Insecure Dependencies

Warning
Location
skill.md:11
Finding

Unpinned Third-Party Authentication Packages

Content
View full analysis

Vulnerability Details

File Location: skill.md, lines 11-20
Vulnerability Type: Unpinned third-party dependencies
Risk Level: Medium

Vulnerable Code

markdown
**Python:** [PyPI](https://pypi.org/project/moltauth/)
```bash
pip install moltauth

Node.js: npm

bash
npm install moltauth
text

### Technical Analysis

The installation instructions retrieve the latest available `moltauth` package from PyPI or npm without specifying a reviewed version, cryptographic hash, lockfile, or integrity constraint. The project contains only documentation and does not include the package source, so the behavior of the dependency installed by these commands cannot be verified from the audited artifact.

Package installation and runtime code execute with the permissions of the user or environment running the commands. Consequently, a compromised maintainer account, malicious future release, registry compromise, or compromised transitive dependency could introduce arbitrary behavior after this Skill has been reviewed.

The use of established registries reduces some risk, and the audited file does not prove that the current packages are malicious. The vulnerability is the absence of controls ensuring that users receive the same reviewed dependency version.

### Attack Path

1. An attacker compromises the package maintainer, package registry entry, release process, or a transitive dependency.
2. The attacker publishes a malicious package version under the expected package name.
3. A user follows the documented unpinned `pip install moltauth` or `npm install moltauth` command.
4. The package manager resolves the attacker-controlled release.
5. Malicious installation or runtime code executes with the user's privileges.
6. Depending on the execution environment, that code could access local files, environment variables, authentication keys, network resources, or application data available to the process.

### 
...[truncated 710 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin both dependencies to specific, reviewed versions rather than resolving the latest release.
  2. For Python, use a requirements or lock file containing cryptographic hashes, such as hashes generated with pip-compile.
  3. For Node.js, provide and enforce a reviewed lockfile and use reproducible installation commands such as npm ci.
  4. Verify that published artifacts correspond to the referenced source repository and document the release verification process.
  5. Audit direct and transitive dependencies before updating pinned versions.
  6. Recommend installation in an isolated virtual environment, container, or otherwise least-privileged execution context.
  7. Add automated dependency scanning and integrity verification to the release workflow.

T09 · Insecure Skill Coding Practices

Warning
Location
skill.md:99
Finding

Agent Private Keys Written to Standard Output

Content
View full analysis

Vulnerability Details

File Location: skill.md, lines 99-100 and 116-117
Vulnerability Type: Sensitive authentication material exposed through logging
Risk Level: Medium

Vulnerable Code

Python example:

python
# SAVE the private key securely!
print(result.private_key)

Node.js example:

typescript
// SAVE the private key securely!
console.log(result.privateKey);

Technical Analysis

The registration examples print newly generated Ed25519 private keys to standard output. This contradicts the adjacent instruction to save the key securely.

Standard output is not a secure secret-storage channel. It may be captured by terminal scrollback, CI/CD logs, shell-session recordings, AI-agent transcripts, notebook output, container logs, centralized observability platforms, or shared automation records. Access controls and retention policies for these systems are frequently broader than those intended for authentication secrets.

The surrounding documentation indicates that these private keys sign authenticated requests for an agent identity. Possession of a private key would therefore allow another party to create signatures that appear to originate from that agent. Although the document shows signed network requests, it does not show the private key itself being transmitted to MoltTribe; the confirmed issue is local disclosure through standard output rather than demonstrated network exfiltration.

Attack Path

  1. A user copies and runs the documented registration example.
  2. Registration generates a private key for the new agent.
  3. The example prints the complete private key to standard output.
  4. The output is retained in a terminal record, CI log, transcript, notebook, container log, or centralized logging system.
  5. An attacker or unauthorized operator with access to that output obtains the key.
  6. The attacker configures a MoltAuth client with the stolen username and private key.
  7. The attacker signs requests that verify a ...[truncated 650 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove both print and console.log statements for private keys.
  2. Store generated keys directly in an operating-system keychain, dedicated secret manager, hardware-backed keystore, or permission-restricted local file.
  3. If a local file is supported, create it with restrictive permissions and prevent accidental source-control inclusion.
  4. Ensure logging and telemetry systems redact private keys and other authentication material.
  5. Document key rotation, revocation, backup, and recovery procedures.
  6. Warn users not to place private keys in command-line arguments, source files, notebooks, chat transcripts, or environment dumps.
  7. Return only a non-sensitive confirmation or key identifier in example output.

SkillSpector

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

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The documentation explicitly prints the newly generated private key to stdout immediately after registration. Console output is commonly captured by terminals, shell history tools, CI logs, notebook outputs, observability systems, or screen recordings, so this teaches a credential-handling pattern that can leak long-lived signing keys and enable impersonation of the agent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

The Node.js example logs result.privateKey to the console, which can expose the agent's signing credential to logs and downstream monitoring systems. Because the system uses private-key signatures for authentication, disclosure of this key allows attackers to forge authenticated requests as that agent until the key is rotated or revoked.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.