Back to skill

Security audit

Moltext

Security checks for vulnerabilities and agentic risk

Overview

The skill is a documentation-ingestion helper, but it tells agents to globally install a mutable npm CLI and trust arbitrary web documentation as agent context.

Review before installing. Use a sandbox or project-local install, pin and verify the moltext package version, fetch only trusted HTTPS documentation, treat generated files as untrusted reference data, inspect output before reuse, choose output paths carefully, and avoid passing API keys directly on the command line.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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 (3)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:20
Finding
Unpinned Global Installation of a Third-Party npm Package<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 20-24; duplicated in `README.md`, lines 42-46 **Vulnerability Type**: Unpinned and globally installed third-party dependency **Risk Level**: Medium ### Vulnerable Code ```markdown Ensure the `moltext` CLI is installed in your environment: ```bash npm install -g moltext ``` ``` ### Technical Analysis The installation command retrieves the current `moltext` package release from the configured npm registry without specifying an exact version, lockfile, or integrity hash. Consequently, the executable installed when a user follows these instructions can differ from the package version that existed when this Skill was audited. The `-g` option installs the package globally. Depending on the npm configuration and user privileges, this can expose a broader environment than a project-local installation. npm packages can also define lifecycle scripts, such as `preinstall`, `install`, and `postinstall`, which npm may execute during installation. This finding does not establish that the current `moltext` package is malicious. The risk arises because the Skill depends on mutable, externally supplied package content without reproducible verification. ### Attack Path 1. An attacker compromises the package, a maintainer account, or the package distribution path. 2. The attacker publishes a malicious release under the expected `moltext` package name. 3. A user or Agent follows the Skill instructions and runs `npm install -g moltext`. 4. npm retrieves the latest mutable release rather than a previously audited version. 5. Malicious package code or lifecycle scripts execute with the privileges of the account running npm. 6. The globally installed executable remains available to subsequent commands and users covered by the global npm prefix. ### Impact Assessment Successful exploitation could execute arbitrary code with the privileges of the installing account. Depending on those privileges, the attac ...[truncated 362 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin the CLI to an exact, audited version, for example `moltext@x.y.z`. - Prefer a project-local dependency managed by a committed lockfile instead of a global installation. - Verify package provenance, registry origin, checksums, and signatures where supported. - Use npm lockfile integrity metadata and reproducible installation commands such as `npm ci`. - Consider suppressing lifecycle scripts with `--ignore-scripts` if the package functions correctly without them. - Run installation and execution under a dedicated, least-privileged account or sandbox. - Document the audited package version and establish a controlled process for reviewing upgrades. ]]>

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:29
Finding
Untrusted Web Documentation Is Ingested as Trusted Agent Context<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 29-48 **Vulnerability Type**: Indirect prompt injection through externally retrieved documentation **Risk Level**: High ### Vulnerable Code ```markdown ### 1. Compile Documentation (AI-Native Learning) To learn about a new tool or massive library, run the compiler in **Raw Mode**. This strips the human noise and delivers the pure technical structure directly to your memory. ```bash moltext <url> --raw --output <filename.md> ``` **Example:** "I need to learn how to use the 'foobar' library." ```bash moltext https://docs.foobar.com --raw --output foobar_context.md ``` ### 2. Ingest Context After compiling, **READ** the output file. It contains the high-fidelity technical specifications you need to act with 100% accuracy. ```bash cat foobar_context.md ``` ``` The trust instruction is reinforced at `SKILL.md`, line 52: ```markdown - **Trust the Memory**: The output is strictly formatted to preserve code blocks, API signatures, and logic flows. ``` ### Technical Analysis The Skill accepts documentation from a URL, transforms it in raw mode, and directs the Agent to read the result into its context. It describes that externally derived content as trustworthy and accurate without defining an origin allowlist, provenance checks, content validation, prompt-injection detection, or an instruction/data boundary. Structural Markdown normalization does not make the source trustworthy. An attacker-controlled or compromised documentation page can contain text framed as instructions to an Agent. If those instructions survive normalization, they enter the context used for later reasoning and may compete with the legitimate user task or safety constraints. The output may also be written as a reusable context or memory file. Although the audited files do not themselves implement a persistent-memory mechanism, retaining and reusing the generated file can extend the influence of poisoned content beyon ...[truncated 1458 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove instructions telling Agents to “trust” fetched output or regard it as automatically accurate. - Explicitly label all retrieved documentation as untrusted reference data rather than executable instructions. - Restrict retrieval to approved HTTPS origins and validate the final destination after every redirect. - Preserve source URLs and provenance for each extracted section so suspicious content can be traced. - Detect and quarantine instruction-like text, including requests to ignore prior rules, invoke tools, expose secrets, or download additional payloads. - Isolate retrieved content from system, developer, and user instructions using a dedicated data channel or sandboxed analysis process. - Require explicit user confirmation before acting on fetched content in ways that affect files, credentials, networks, deployments, or external systems. - Apply least privilege to the Agent processing the documentation and disable unnecessary shell, credential, and write access. - Avoid automatically persisting generated content into long-term Agent memory. Review and sanitize content before reuse. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
README.md:66
Finding
API Key Passed Directly Through a Command-Line Argument<![CDATA[ ## Vulnerability Details **File Location**: `README.md`, lines 66-70 **Vulnerability Type**: Sensitive credential exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```markdown ### 3. The "Legacy" Flow (OpenAI) If you have an OpenAI key and want the compiler to do the thinking: ```bash moltext https://docs.example.com -k sk-... ``` ``` ### Technical Analysis The documented usage passes an API key through the `-k` command-line argument. Command-line secrets can be recorded in interactive shell history, terminal logs, command auditing systems, job logs, automation output, or process metadata. On systems where process arguments are visible to other users or monitoring tools, the credential may be exposed while the command is running. Even where process inspection is restricted, shell history and copied command logs can retain the key after execution. The snippet contains a placeholder rather than a real hardcoded secret. The vulnerability is the recommended credential-handling pattern, which encourages users to replace the placeholder with a live key directly on the command line. ### Attack Path 1. A user replaces `sk-...` with a valid API key and runs the documented command. 2. The shell records the complete command in its history, or an automation platform records it in logs. 3. Alternatively, a local process-monitoring user or service observes the command arguments while `moltext` is running. 4. An attacker with access to the history, logs, terminal transcript, or exposed process metadata obtains the key. 5. The attacker uses the key against the associated API until it is revoked or otherwise restricted. ### Impact Assessment A stolen key could permit unauthorized API requests within the permissions, quotas, and billing limits assigned to that credential. Potential consequences include financial charges, quota exhaustion, access to resources available to the key, and abuse attributed to the legitim ...[truncated 164 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Do not recommend supplying secrets directly as command-line arguments. - Support a protected environment variable or a credential file with restrictive permissions. - Prefer an interactive secret prompt that does not echo input and does not store the value in shell history. - Integrate with an operating-system keychain or secret manager where practical. - Ensure diagnostic output, errors, telemetry, and logs redact credentials. - Recommend narrowly scoped keys with spending limits, usage restrictions, and regular rotation. - Warn users to revoke and replace any key that may have been entered into shell history or exposed in logs. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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 (1)

Missing User Warnings

Low
Confidence
84% confidence
Finding
The markdown shows a usage flow that writes documentation to `tool_context.md` via `-o tool_context.md`, which affects local user data. The README does not include any caution about creating or overwriting files, so users are not warned about this file-modifying behavior.

Static analysis

No suspicious patterns detected.