Expanso json-to-yaml

• Outcome: Review
• Latest audit: Sep 10, 2026 · 4:54 PM UTC
• Version: 1.0.0

Overview

The skill appears to be a simple JSON-to-YAML converter, but its server and cloud deployment instructions expose more risk than the local conversion task needs.

Use the local CLI pipeline when possible. If you run the MCP server, bind it to localhost or protect it with network controls, and avoid deploying from the remote URL unless you can verify the exact pipeline content or digest.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (3)

T09 · Insecure Skill Coding Practices

Warning

• Location: pipeline-mcp.yaml:5
• Finding: Unauthenticated HTTP Service Exposed on All Network Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `pipeline-mcp.yaml:5-12` **Vulnerability Type**: Unauthenticated network exposure and insufficient resource controls **Risk Level**: Medium ### Vulnerable Code ```yaml http: enabled: true address: "0.0.0.0:${PORT:-8080}" input: http_server: path: /convert allowed_verbs: [POST] timeout: 30s ``` ### Technical Analysis The MCP pipeline binds its HTTP listener to `0.0.0.0`, making the service available through every network interface permitted by the host firewall or container networking configuration. No authentication, authorization, or source-address restriction is declared. The endpoint accepts POST requests and parses supplied JSON before formatting it as YAML. Unlike the CLI pipeline, which explicitly sets `max_buffer: 1048576`, the MCP configuration does not declare a request-body limit. Runtime defaults may provide an implicit limit, but no protection is established by the reviewed configuration. This design unnecessarily broadens the attack surface of a conversion utility. Network exposure should be explicitly enabled by an operator rather than being the default behavior. ### Attack Path 1. An operator starts the MCP pipeline using the documented command. 2. The service listens on every available interface on the configured port, defaulting to port 8080. 3. An attacker with network access locates the exposed service. 4. The attacker repeatedly submits POST requests to `/convert`, potentially using large or computationally expensive JSON documents. 5. The service repeatedly parses and formats the input, consuming application memory and CPU until requests are rejected, time out, or service availability degrades. ### Impact Assessment An attacker can invoke the conversion endpoint without credentials and consume the resources allocated to the pipeline. The demonstrated impact is limited to unauthorized use of this application endpoint and potential denial of se ...[truncated 159 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Bind the listener to `127.0.0.1` by default. - Require an explicit configuration change before exposing the service to external networks. - Add authentication and authorization when remote access is necessary. - Configure a strict request-body size limit comparable to the CLI pipeline's one-megabyte limit. - Apply rate limiting, concurrency limits, and bounded processing time. - Restrict ingress using host firewall, container networking, or reverse-proxy access-control rules. - Return a suitable HTTP error before parsing requests that exceed the permitted size. - Add tests verifying that unauthenticated external requests are rejected in remotely accessible deployments. ]]>

T03 · Remote Payload Retrieval and Execution

Warning

• Location: SKILL.md:24
• Finding: Deployment Command Retrieves a Mutable Remote Pipeline<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:24-26` **Vulnerability Type**: Remote payload retrieval through mutable deployment input **Risk Level**: Medium ### Vulnerable Code ```markdown ### Deploy to Expanso Cloud ```bash expanso-cli job deploy https://skills.expanso.io/json-to-yaml/pipeline-cli.yaml ``` ``` ### Technical Analysis The documented deployment command instructs users to deploy a pipeline directly from an external HTTPS URL instead of deploying the reviewed local `pipeline-cli.yaml`. The URL does not contain an immutable version or content digest. Consequently, the effective pipeline deployed by a user can differ from the pipeline present in this audited package. HTTPS protects transport integrity when correctly validated, but it does not ensure that the server continues to return the same reviewed content. A compromised hosting account, server, publication process, or upstream resource could replace the pipeline after this audit. ### Attack Path 1. An attacker gains control of, or the ability to modify, the pipeline served at the documented URL. 2. The attacker replaces the expected conversion pipeline with altered configuration. 3. A user follows the documentation and runs the remote deployment command. 4. `expanso-cli` retrieves the current remote resource rather than the locally reviewed file. 5. The altered pipeline is deployed with whatever capabilities and credentials the user's deployment environment grants to the job. Exploitation requires compromise or unauthorized modification of the external hosting or publication path; the reviewed project contains no evidence that such a compromise has already occurred. ### Impact Assessment The impact depends on the permissions and features available to remotely deployed pipelines. At minimum, an attacker controlling the hosted resource could change conversion behavior or disrupt the deployed service. If the deployment platform grants pipelines access to connectors, se ...[truncated 256 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Deploy the bundled, reviewed file by default: ```bash expanso-cli job deploy pipeline-cli.yaml ``` - If remote deployment is required, reference an immutable release identifier or content-addressed URL. - Publish and verify a cryptographic checksum or signature before deployment. - Ensure the deployment client refuses content whose digest does not match the reviewed artifact. - Protect the remote publication process with restricted access, multi-factor authentication, audit logs, and release approval controls. - Document the exact expected digest and provide a reproducible method for comparing the remote resource with the local pipeline. ]]>

T08 · Insecure Dependencies

Note

• Location: SKILL.md:5
• Finding: External Runtime Installation Is Not Version-Pinned or Integrity-Verified<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:5-8` **Vulnerability Type**: Unpinned third-party runtime dependency **Risk Level**: Low ### Vulnerable Code ```markdown ## Requirements - Expanso Edge installed (`expanso-edge` binary in PATH) - Install via: `clawhub install expanso-edge` ``` ### Technical Analysis The installation instruction resolves `expanso-edge` by name without specifying a version, immutable digest, signature, or expected publisher identity. A user following the instructions may therefore install a different runtime release from the one against which the skill was reviewed or tested. This creates a supply-chain risk if the package source, publisher account, package resolution mechanism, or a future release is compromised. The project does not itself include a malicious dependency, and the audit evidence does not show that the named runtime is currently compromised. The issue is the absence of controls that make dependency resolution reproducible and verifiable. ### Attack Path 1. An attacker compromises the package publication account, registry entry, or distribution path for `expanso-edge`. 2. The attacker publishes or substitutes an altered package under the expected dependency name. 3. A user follows the unpinned installation instruction. 4. The package manager resolves and installs the attacker-controlled or otherwise unreviewed version. 5. The installed runtime executes under the privileges of the user or installation process when the pipeline is started. ### Impact Assessment A compromised runtime could affect every pipeline processed through that installation and act with the operating-system privileges granted to the runtime process. Depending on installation and execution context, this could include access to the user's files, environment variables, network connections, and pipeline data. No evidence in the reviewed files demonstrates an existing malicious runtime or actual privilege escalation. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin `expanso-edge` to a specific reviewed version. - Where supported, pin the artifact by cryptographic digest in addition to its semantic version. - Document the trusted registry and expected publisher identity. - Verify package signatures or checksums before installation. - Use a lockfile, signed release manifest, or equivalent reproducible dependency mechanism. - Establish an update process that reviews and tests new runtime versions before changing the documented pin. - Avoid executing the runtime with administrative privileges unless installation requirements make that strictly necessary. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.