Seed

• Outcome: Review
• Latest audit: Sep 11, 2026 · 7:12 PM UTC
• Version: 0.1.2

Overview

This skill openly manages remote firmware, but its setup and connection instructions expose users to high-impact remote-code and credential risks.

Install only if you intentionally want an agent-managed remote firmware service. Review and pin the seed source before compiling, run it as an unprivileged user on an isolated host or private network, avoid exposing it over plaintext HTTP, treat the token as an admin credential, and require explicit approval before any firmware upload, build, or apply action.

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: SKILL.md:19
• Finding: Unpinned Remote Source Is Downloaded, Compiled, and Executed## Vulnerability Details **File Location**: `SKILL.md`, lines 19-22 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ```bash # On the target machine (Pi, VPS, any Linux box): curl -fsSL https://raw.githubusercontent.com/Awis13/seed/main/seeds/linux/seed.c -o seed.c gcc -O2 -o seed seed.c ./seed 8080 ``` ### Technical Analysis The deployment instructions retrieve C source from the mutable `main` branch of an external personal repository, compile it into a native executable, and run it without any source review, immutable version pinning, checksum validation, or signature verification. Because the effective source can change after this Skill has been reviewed, the audited package does not determine the code ultimately executed on the target. Compromise of the upstream repository, its maintainer account, the referenced branch, or the delivery infrastructure could substitute arbitrary native code. The supplied `curl` options validate HTTPS transport but do not establish that the retrieved source is an expected, reviewed version. This is principally remote payload retrieval and execution. It also creates a supply-chain risk through reliance on an unpinned and unverified external component. ### Attack Path 1. An attacker compromises the upstream repository or an account authorized to modify its `main` branch. 2. The attacker replaces `seeds/linux/seed.c` with malicious or backdoored C source. 3. A user or Agent follows the documented deployment instructions. 4. `curl` downloads the attacker-controlled source without verifying an immutable version or expected digest. 5. `gcc` compiles the source into a native executable. 6. `./seed 8080` executes the payload with the privileges of the user performing deployment. 7. The payload can access resources available to that account and may expose further remote-control functionality. ### Impact Assessment Successful exploitation provid ...[truncated 461 chars]
• Remediation: ## Remediation Suggestions - Vendor the reviewed source into the Skill package so the audited artifact contains the exact code that will execute. - If remote retrieval is necessary, reference an immutable commit rather than `main`. - Publish and verify a cryptographic SHA-256 or stronger digest before compilation. - Prefer a signed release artifact and verify its signature against a pinned, independently distributed public key. - Stop deployment immediately if verification fails; never fall back to executing an unverified payload. - Present the source or a verified diff for review before compilation. - Compile and initially execute the service in an isolated, unprivileged environment with minimal filesystem, device, and network access. - Document the expected commit, digest, signer, and update procedure in `SKILL.md`.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:30
• Finding: Documented Endpoint May Disclose the Administrative Bearer Token Without Authentication## Vulnerability Details **File Location**: `SKILL.md`, lines 30-38; related API entry at line 93 **Vulnerability Type**: Authentication-secret disclosure and unauthorized administrative access **Risk Level**: Critical ```bash ## Connecting The node prints its address and token on startup. If you don't know them: ```bash # The user will provide the address, or: curl http://<ip>:8080/health # no auth needed curl http://<ip>:8080/skill # full connection details + token ``` All requests except `/health` need: `Authorization: Bearer <token>` ``` The API reference additionally describes the endpoint as follows: ```text | GET | /skill | Generate this file with live connection details | ``` ### Technical Analysis The documented request to `/skill` contains no `Authorization` header, while the accompanying comment states that the response contains the token. This conflicts with the separate statement that every endpoint other than `/health` requires bearer authentication. If the service behaves according to the shown token-retrieval example, an unauthenticated network client can obtain the same bearer credential used to protect firmware source upload, compilation, application, configuration, and hardware-discovery operations. A bearer token grants access solely through possession, so disclosure immediately defeats the administrative authorization boundary. The project contains only documentation and no bundled implementation. Therefore, the actual endpoint behavior cannot be independently verified. Nevertheless, the Skill explicitly directs clients to attempt unauthenticated retrieval of live connection details and a secret, creating a dangerous and exploitable deployment contract if implemented as documented. ### Attack Path 1. An attacker identifies a network-reachable seed node on port 8080. 2. The attacker sends an unauthenticated `GET /skill` request as shown in the Skil ...[truncated 1259 chars]
• Remediation: ## Remediation Suggestions - Never include bearer tokens, passwords, private keys, or equivalent credentials in `/skill` responses. - Require valid authentication for `/skill` and every endpoint except a minimal health check. - Make `/health` return only non-sensitive liveness information. - Remove the unauthenticated token-retrieval example and document a separate secure provisioning process. - Generate the initial token locally and expose it only through the target machine's console or another authenticated out-of-band channel. - Store tokens securely, make them high entropy, support rotation and revocation, and avoid logging them. - Separate read-only discovery permissions from firmware upload, build, and apply permissions. - Bind the management service to loopback or a dedicated private interface by default. - Add automated authorization tests proving that unauthenticated `/skill`, firmware, configuration, and build requests receive `401` or `403` responses and never disclose credentials.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:32
• Finding: Bearer Credentials and Firmware-Control Operations Use Plaintext HTTP## Vulnerability Details **File Location**: `SKILL.md`, lines 32-66 **Vulnerability Type**: Plaintext transmission of administrative credentials and privileged control traffic **Risk Level**: High ```bash # The user will provide the address, or: curl http://<ip>:8080/health # no auth needed curl http://<ip>:8080/skill # full connection details + token ``` ```bash curl -H "Authorization: Bearer $TOKEN" http://$HOST/capabilities ``` ```bash curl -H "Authorization: Bearer $TOKEN" http://$HOST/firmware/source ``` ```bash curl -H "Authorization: Bearer $TOKEN" \ -X POST --data-binary @new_firmware.c \ http://$HOST/firmware/source ``` ```bash curl -H "Authorization: Bearer $TOKEN" -X POST http://$HOST/firmware/build ``` ```bash curl -H "Authorization: Bearer $TOKEN" -X POST http://$HOST/firmware/apply ``` ### Technical Analysis The documented management workflow uses `http://` for bearer authentication, source-code transfer, compilation, and firmware application. Plain HTTP provides neither confidentiality nor server authentication nor transport integrity. Any party capable of observing the relevant network path can read the `Authorization` header and replay the bearer token. An active network attacker can also redirect or modify responses and requests. Because the interface supports native-code compilation and application, compromise of the transport can escalate directly from network interception to execution of attacker-selected firmware. The watchdog rollback does not mitigate this issue. An attacker can upload firmware that continues to answer the health check while performing malicious actions, allowing it to pass a liveness-based watchdog. ### Attack Path 1. A legitimate administrator connects to the node over an untrusted or compromised network. 2. A network-positioned attacker captures an HTTP request containing `Authorization: Bearer $TOKEN`. 3. T ...[truncated 1187 chars]
• Remediation: ## Remediation Suggestions - Require HTTPS for every management endpoint and refuse privileged requests received over plaintext HTTP. - Use certificates issued by a trusted private or public CA and ensure clients perform hostname and certificate validation. - For device-oriented deployments, consider mutual TLS with unique per-device client certificates. - Alternatively, restrict the API to loopback and require access through an authenticated SSH or WireGuard tunnel. - Bind to a private management interface rather than all interfaces by default and enforce firewall allowlists. - Use short-lived, narrowly scoped credentials and rotate any token that may have traversed plaintext transport. - Separate firmware read, upload, build, and apply privileges and require stronger authorization for deployment. - Protect firmware updates with signed artifacts or signed source manifests so transport compromise alone cannot authorize arbitrary code. - Document secure certificate bootstrapping and fail closed when certificate validation or tunnel establishment fails.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• 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
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (3)

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# On the target machine (Pi, VPS, any Linux box):
curl -fsSL https://raw.githubusercontent.com/Awis13/seed/main/seeds/linux/seed.c -o seed.c
gcc -O2 -o seed seed.c
./seed 8080
# Token will be printed — give it to the agent

• Confidence: 89% confidence
• Finding: The skill tells users to fetch and compile remote code directly from GitHub using `curl | download` style instructions, then run it and share the resulting token with the agent. This is risky because it establishes trust in unaudited external code at execution time and bootstraps a service that exposes remote firmware-management capabilities, creating a supply-chain and remote-administration attack path if the source is tampered with or misunderstood.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The skill documents that `GET /skill` returns full connection details and the bearer token, and even suggests giving the token to the agent, but it does not include any credential-handling warning or minimization guidance. This is dangerous because the token grants access to firmware reading, writing, building, and applying, so exposing it through an endpoint or casually sharing it with an agent materially increases the chance of takeover of the node.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill instructs the agent to upload, compile, and apply new firmware to a remote device without an explicit warning that these actions modify system software and can disrupt, brick, or repurpose the target hardware. In this context, the omission is dangerous because the core workflow enables authenticated remote code deployment, so a user may not appreciate that the agent is being guided to perform highly privileged and potentially irreversible device changes.

Static analysis

No suspicious patterns detected.