Azion Deploy

• Outcome: Review
• Latest audit: Sep 11, 2026 · 12:28 AM UTC
• Version: 0.1.1

Overview

This Azion deployment skill is purpose-aligned, but its documentation and wrapper use risky installer and token-handling patterns that users should review before installing.

Install only if you are comfortable reviewing and hardening the Azion setup steps: avoid piping installers directly into a shell, do not source untrusted .env files, prefer secure secret injection or an authenticated CLI session over literal --token arguments, and use least-privileged Azion tokens for deployment.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/azion-cli.md:15
• Finding: Unverified Remote Installer Is Downloaded and Executed Directly<![CDATA[ ## Vulnerability Details **File Location**: `references/azion-cli.md:15` and `references/azion-cli.md:21` **Vulnerability Type**: Remote payload retrieval and immediate execution **Risk Level**: Critical ### Vulnerable Code ```bash curl -fsSL https://downloads.azion.com/cli/install.sh | sh ``` ```powershell irm https://downloads.azion.com/cli/install.ps1 | iex ``` ### Technical Analysis The installation instructions pipe mutable content retrieved over the network directly into a command interpreter. The downloaded scripts are not pinned to a specific version, saved for inspection, or verified using a cryptographic signature or published checksum. The domains appear consistent with the referenced vendor, but HTTPS alone does not establish that the downloaded content is the same content that was reviewed during this audit. Compromise of the vendor distribution infrastructure, DNS or TLS trust chain, hosting account, or upstream release process could change the effective payload without any modification to this Skill. Installing the required Azion CLI is relevant to the Skill's purpose, but executing an unverified network response directly is not the minimum-risk installation mechanism. ### Attack Path 1. A user follows the installation instructions because the required `azion` executable is unavailable. 2. An attacker compromises or gains control over the remote installer endpoint or its delivery path. 3. The endpoint returns an installer containing attacker-controlled shell or PowerShell commands. 4. `sh` or `iex` executes the response immediately, without an opportunity for integrity verification or review. 5. The malicious installer accesses or modifies resources available to the invoking account. ### Impact Assessment Successful exploitation provides arbitrary code execution with the privileges of the user running the installation command. Depending on those privileges and the local environment, the payload could: - Read user-accessible ...[truncated 357 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the direct `curl | sh` and `irm | iex` installation patterns. 2. Prefer a trusted operating-system package manager or a vendor-supported package repository. 3. Pin the Azion CLI to an explicitly reviewed version. 4. Download the installer or release artifact to a local file before execution. 5. Verify the artifact using a vendor-published cryptographic signature or SHA-256 checksum obtained through an independently trusted channel. 6. Inspect the downloaded installer before executing it. 7. Run installation with an unprivileged account unless elevated permissions are demonstrably required. 8. Document the expected download URL, version, checksum, and verification procedure. A safer conceptual Unix flow is: ```bash curl -fLo azion-installer.sh "https://downloads.azion.com/cli/install.sh" # Compare against a trusted, vendor-published checksum or verify a signature. sha256sum azion-installer.sh less azion-installer.sh sh azion-installer.sh ``` This flow must use a known, trusted checksum or signature; merely printing a checksum does not provide integrity verification. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/azion-cli.md:45
• Finding: Documentation Executes Project-Controlled .env Files as Shell Code<![CDATA[ ## Vulnerability Details **File Location**: `references/azion-cli.md:45-48` and `references/azion-cli.md:55-58` **Vulnerability Type**: Unsafe shell sourcing of a potentially untrusted configuration file **Risk Level**: High ### Vulnerable Code ```bash set -a source .env set +a azion whoami --token "$AZION_TOKEN" ``` The same unsafe loading pattern is repeated in the non-interactive deployment example: ```bash set -a source .env set +a azion deploy --yes --token "$AZION_TOKEN" ``` ### Technical Analysis The Bash `source` command does not parse `.env` as a passive key-value configuration format. It executes the file as shell code in the current shell process. A `.env` file can therefore contain command substitutions, function definitions, redirections, arbitrary commands, or other shell syntax. Deployment workflows frequently operate inside cloned, downloaded, or collaboratively maintained repositories. If an attacker can add or alter the project's `.env` file, following these documented commands executes attacker-controlled code under the operator's account. The `set -a` commands only control automatic exporting of variables and do not restrict what the sourced file may execute. Loading an authentication token is relevant to deployment, but executing the entire token file as shell code exceeds the privileges necessary to read a configuration value. ### Attack Path 1. An attacker supplies or modifies a repository containing a crafted `.env` file. 2. The file appears to contain ordinary deployment configuration but also includes malicious shell syntax. 3. A user follows the documented authentication or deployment procedure. 4. `source .env` executes the malicious statements in the user's current shell. 5. The malicious code steals credentials, alters the repository, or runs additional local commands. 6. The legitimate Azion command may still run afterward, concealing the preceding compromise. ### Impact Assessment Exploitation results in arb ...[truncated 571 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove instructions that use `source .env` or `. .env` on project-controlled files. 2. Prefer supplying `AZION_TOKEN` through a CI secret store, operating-system credential store, or an already established environment variable. 3. If dotenv loading is required, use a parser that treats the file strictly as data rather than shell code. 4. Restrict accepted variable names to an explicit allowlist such as `AZION_TOKEN`. 5. Reject command substitutions, shell operators, redirections, function declarations, and malformed records. 6. Ensure `.env` is excluded from version control and has restrictive filesystem permissions. 7. Warn users not to load environment files from untrusted repositories. A safer documented pattern is: ```bash AZION_TOKEN="value-provided-by-a-secret-manager" export AZION_TOKEN azion whoami --token "$AZION_TOKEN" ``` For CI, map the platform's protected secret directly to `AZION_TOKEN` instead of reading it by executing a repository file. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/azion-deploy.sh:32
• Finding: Azion Authentication Tokens Are Exposed Through Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/azion-deploy.sh:32-39`, `scripts/azion-deploy.sh:78-84`, and `scripts/azion-deploy.sh:99-115` **Vulnerability Type**: Sensitive credential exposure through command-line arguments **Risk Level**: Medium ### Vulnerable Code The authentication check forwards the token as an argument: ```bash run_whoami() { local token="${1:-${AZION_TOKEN:-}}" if [[ -n "$token" ]]; then azion whoami --token "$token" else azion whoami fi } ``` The quickstart flow repeatedly places the token in child-process argument vectors: ```bash cmd_preflight "$token" local common_args=() [[ -n "$token" ]] && common_args+=(--token "$token") azion link --auto --name "$name" --preset "$preset" "${common_args[@]}" azion build "${common_args[@]}" azion deploy --local --skip-build --auto "${common_args[@]}" ``` The local deployment flow does the same during build and deployment: ```bash cmd_preflight "$token" if [[ "$skip_build" != "true" ]]; then azion build ${token:+--token "$token"} else test -f .edge/manifest.json || { echo "[ERROR] .edge/manifest.json missing. Run build first or remove --skip-build"; exit 4; } fi local deploy_args=(--local) [[ "$auto" == "true" ]] && deploy_args+=(--auto) [[ "$skip_build" == "true" ]] && deploy_args+=(--skip-build) [[ -n "$token" ]] && deploy_args+=(--token "$token") azion deploy "${deploy_args[@]}" ``` ### Technical Analysis The wrapper accepts a token through `--token` or `AZION_TOKEN` and then forwards it to the Azion CLI using `--token TOKEN`. This places the secret in the child process's argument vector. Depending on the operating system and runtime environment, command arguments may be observable through process inspection interfaces, monitoring agents, CI telemetry, audit systems, crash reports, or debug logs. Supplying the wrapper's own `--token` option manually may additionally record the token in shell history. Authentication is necessary for deployment, b ...[truncated 1260 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Prefer the Azion CLI's secure credential store, authenticated session, or environment-based authentication mechanism if officially supported. 2. Avoid accepting secrets through the wrapper's `--token` command-line option. 3. Do not propagate tokens into child-process argument vectors. 4. If supported by the CLI, pass the token through a dedicated environment variable or standard input. 5. Ensure CI systems mask the token and disable command tracing around authentication and deployment commands. 6. Document that users should not invoke the wrapper with literal token values in interactive shell commands. 7. Use short-lived, narrowly scoped deployment tokens and rotate them regularly. 8. Revoke tokens immediately if process logs, shell history, or telemetry may have captured them. 9. Verify that debugging and error handling never print token values. If the Azion CLI natively recognizes `AZION_TOKEN`, retain it in the environment and invoke commands without the `--token` argument: ```bash export AZION_TOKEN azion whoami azion build azion deploy --local ``` This recommendation should only be adopted after confirming the CLI's documented environment-based authentication behavior. ]]>

SkillSpector

Vulnerability Patterns

• 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
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (7)

External Script Fetching

High

• Category: Supply Chain

Content

macOS / Linux:

```bash
curl -fsSL https://downloads.azion.com/cli/install.sh | sh
```

Windows (PowerShell):

• Confidence: 99% confidence
• Finding: Fetching and immediately executing an external install script is a classic supply-chain risk because it trusts remote content at execution time without verification. In this skill context, the danger is elevated because the file is operational guidance intended to be copied and run by users on developer workstations or CI runners.

Chaining Abuse

High

• Category: Tool Misuse

Content

macOS / Linux:

```bash
curl -fsSL https://downloads.azion.com/cli/install.sh | sh
```

Windows (PowerShell):

• Confidence: 97% confidence
• Finding: The command chains a network fetch directly into a shell using a pipe, removing any opportunity for review or integrity validation before execution. This chaining pattern magnifies the blast radius of any compromise of the download source and is especially risky in deployment-oriented docs where users may run commands with elevated privileges or in automated environments.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
set -a
source .env
set +a
azion whoami --token "$AZION_TOKEN"
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
set -a
source .env
set +a
azion whoami --token "$AZION_TOKEN"
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The documentation instructs users to install the CLI by piping a remotely fetched script directly into a shell/PowerShell interpreter, with no integrity verification, pinning, or warning. If the vendor host, CDN, DNS, TLS trust chain, or network path is compromised, arbitrary code would execute immediately on the user's machine.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The token-based authentication examples normalize loading a sensitive API token from a local .env file and passing it on the command line without any guidance on secrecy, shell history, CI log exposure, or file permissions. While the examples do not directly exfiltrate the token, they encourage handling patterns that can lead to accidental credential disclosure in shared terminals, scripts, or build logs.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Common Failure Patterns

- `open .edge/manifest.json` or `open .edge/worker.js`: run `azion build` first.
- `Missing default entry point .../handler.js`: create `handler.js` for `javascript` preset.
- `~/.npm/_npx/.../package.json` ENOENT during build: clear `~/.npm/_npx` and rerun.
- Remote deploy logs failing with `rclone` auth/API version errors: use local deploy (`--local --skip-build`).
- Deploy says `.edge/storage` is missing: no static files were uploaded.

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Static analysis

No suspicious patterns detected.