Eppie Email CLI

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:50 AM UTC
• Version: 0.2.3

Overview

This skill is coherent for automating an email CLI, but it asks agents to trust an unverified downloaded executable and to run destructive mail/vault operations without enough user confirmation.

Review carefully before installing. Use only a trusted, verified eppie-console build, prefer a pinned release with an independently checked digest or signature, run it in an isolated working directory, and require explicit user approval before reset, delete-message, or any action that sends mail or supplies account credentials.

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 (2)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:80

Finding

Mutable, Unverified Remote Executable Retrieval and Execution

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:80-102; duplicated in eppie-cli-agent-skill.md:80-102
Vulnerability Type: Remote payload retrieval and execution without integrity verification
Risk Level: High

Vulnerable Code

markdown

## Reference: preferred installation

Prefer the executable published in GitHub Releases.
You can also build from source.

Latest release page:
- https://github.com/Eppie-io/Eppie-CLI/releases/latest

Direct download links:

### Linux
- https://github.com/Eppie-io/Eppie-CLI/releases/latest/download/Eppie.CLI-linux-x64.tar.gz
- https://github.com/Eppie-io/Eppie-CLI/releases/latest/download/Eppie.CLI-linux-arm64.tar.gz

### macOS
- https://github.com/Eppie-io/Eppie-CLI/releases/latest/download/Eppie.CLI-osx-x64.tar.gz
- https://github.com/Eppie-io/Eppie-CLI/releases/latest/download/Eppie.CLI-osx-arm64.tar.gz

### Windows
- https://github.com/Eppie-io/Eppie-CLI/releases/latest/download/Eppie.CLI-win-x64.zip
- https://github.com/Eppie-io/Eppie-CLI/releases/latest/download/Eppie.CLI-win-arm64.zip

After extracting the archive, use the `eppie-console` executable directly.

Technical Analysis

Both Skill documents direct the agent or user to retrieve and execute precompiled binaries through mutable GitHub releases/latest URLs. The effective executable can therefore change after the Skill has been reviewed. No version pin, expected cryptographic digest, signature, trusted signer identity, provenance attestation, or verification procedure is supplied.

GitHub is a recognized hosting service and the URLs are consistent with the declared Eppie repository. The files also do not use an immediate curl | sh pattern. These factors reduce, but do not eliminate, the supply-chain risk. Compromise of the repository, maintainer account, release workflow, or uploaded assets could replace the binary reached through latest.

The trust assigned to this executable is ...[truncated 2549 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace all releases/latest asset URLs with an explicitly pinned, reviewed release version.
2. Publish SHA-256 or stronger digests through a separately protected release channel.
3. Sign release artifacts and document the expected signer identity and exact signature-verification commands.
4. Require the agent to reject an artifact if its digest, signature, asset name, architecture, or pinned version does not match.
5. Prefer reproducible source builds where practical and document the reviewed source commit.
6. Do not automatically install a remote executable when an existing verified local installation is available.
7. Run the executable as an unprivileged user in a sandbox with access limited to the intended vault directory.
8. Restrict outbound network access to the mail providers and services required for the selected task where feasible.
9. Avoid exposing unrelated environment variables, files, credentials, or home-directory contents to the process.
10. Apply the same changes to both duplicated Skill documents to prevent inconsistent or insecure fallback instructions.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:52

Finding

Destructive Confirmation Bypass Enabled as a Normative Agent Default

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:52-61, SKILL.md:224-239, SKILL.md:247-261, and SKILL.md:476-478; duplicated in the corresponding ranges of eppie-cli-agent-skill.md
Vulnerability Type: Unsafe autonomous destructive-operation policy
Risk Level: Medium

Vulnerable Code

markdown

## Normative defaults for agents

When the task requires executing `eppie-console`, use these defaults unless the task explicitly requires otherwise:

1. use `--non-interactive=true`
2. use `--output=json` for agent automation unless text output is explicitly required
3. use `--unlock-password-stdin=true` for stateful commands that need an existing vault
4. use `--assume-yes=true` for destructive automation
5. provide `stdin` exactly in the required order
6. use one consistent working directory per vault

markdown

| Task | Canonical command |
| --- | --- |
| Initialize a vault | `--non-interactive=true --output=json -- init` |
| List accounts | `--non-interactive=true --unlock-password-stdin=true --output=json -- list-accounts` |
| List folders | `--non-interactive=true --unlock-password-stdin=true --output=json -- list-folders -a <account>` |
| Show all messages | `--non-interactive=true --unlock-password-stdin=true --output=json -- show-all-messages -s 10 -l 10` |
| Show one message | `--non-interactive=true --unlock-password-stdin=true --output=json -- show-message -a <account> -f <folder> -i <id> -k <pk>` |
| Delete one message | `--non-interactive=true --unlock-password-stdin=true --output=json -- delete-message -a <account> -f <folder> -i <id> -k <pk>` |
| List contacts | `--non-interactive=true --unlock-password-stdin=true --output=json -- list-contacts -s 10 -l 10` |
| Show contact messages | `--non-interactive=true --unlock-password-stdin=true --output=json -- show-contact-messages -c <contact> -s 10 -l 10` |
| Show fol
...[truncated 3962 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove --assume-yes=true from the normative defaults.
2. Require explicit user authorization for each reset or permanent deletion operation.
3. Resolve and display the absolute working directory, vault identity, account, folder, and message identifiers before destructive execution.
4. Require a separate confirmation step after target resolution rather than relying on authorization inferred from an earlier ambiguous request.
5. Refuse reset when the target directory has not been positively identified as disposable or explicitly approved.
6. Use isolated temporary working directories by default for tests and disposable workflows.
7. Add backup, export, or recovery-point guidance before resetting persistent vaults.
8. Detect when a message is already in Trash and require explicit confirmation before permanent deletion.
9. Keep read-only, sending, and synchronization workflows free of destructive permissions and flags.
10. Record destructive actions and resolved targets in an audit log without recording passwords or other secrets.
11. Apply the policy changes consistently to both duplicated Skill documents.

SkillSpector

Vulnerability Patterns

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

Findings (4)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 86% confidence

Finding

The skill documents delete-message as a normative agent command and later notes that repeated deletion can permanently remove messages from Trash, but it does not pair this with a strong safety requirement such as confirmation, scope checks, or a warning about irreversible deletion. In a semi-autonomous or autonomous email agent, this can lead to unintended message loss from mis-selection of id/pk, folder confusion, or overbroad workflows.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The skill explicitly recommends reset with --assume-yes=true for automation and labels it as destructive, but it does not require an explicit user confirmation gate or a stronger warning about irreversible local data loss before execution. In an autonomous-agent context, this increases the chance of accidental vault destruction or data wiping from routine task execution, especially because the normative guidance makes destructive execution a default pattern.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill explicitly recommends --assume-yes=true for destructive automation and later normalizes reset as a standard automated operation, but it does not pair that guidance with a prominent requirement to verify user intent, confirm scope, or warn about irreversible local data loss before execution. In an autonomous-agent context, that omission increases the chance that an agent will wipe a vault or other local mail state as part of routine task execution without adequate safeguards.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The skill includes a canonical delete-message workflow and only later notes that deletion may move a message to Trash or permanently remove it if already in Trash, but this behavior is not surfaced as a prominent warning in the main task guidance. In an agent-execution setting, understated deletion semantics can cause unintended data loss, especially when the agent is acting autonomously on message identifiers returned from prior commands.

Content

No source excerpt is available for this finding.