T03 · Remote Payload Retrieval and Execution
- Location
skill.md:29- Finding
Unrestricted Retrieval and Execution of User-Supplied Remote Projects
- Content
View full analysis
Vulnerability Details
File Location:
skill.md, lines 29–38
Vulnerability Type: Remote payload retrieval and unsafe dependency execution
Risk Level: HighVulnerable Code Snippet:
markdown 1. **Fetch the Repository** (if applicable) - Clone or download the project - Read the README, documentation, and key configuration files - Identify the tech stack, dependencies, and architecture 2. **Get It Running** 🏃 - Install all necessary dependencies - Follow setup instructions (or figure them out if missing) - Run the project successfully - Test core functionality to verify it worksTechnical Analysis
The Skill instructs the Agent to clone or download an arbitrary project, install its dependencies, run it, and test its functionality. These operations are performed without requiring prior source review, dependency verification, command approval, isolation, or permission restrictions.
This behavior exceeds the minimum privilege necessary for architecture analysis and documentation. Static inspection can support much of the declared project-exploration functionality without executing untrusted repository code. When execution is necessary, it should occur only after explicit authorization and inside a constrained environment.
A remote repository is a mutable payload source: its contents can change after the Skill itself has been audited. Installing dependencies may execute package lifecycle hooks, build scripts, setup modules, or native compilation steps. Running the application, examples, or tests directly executes repository-controlled code. Consequently, a malicious repository or compromised dependency can obtain code execution with the permissions and environmental access available to the Agent.
Although the pre-scan reported a possible sensitive-information network pattern, the audited file does not explicitly direct the Agent to collect or transmit credentials, environm ...[truncated 2244 chars]
- Remediation
View remediation
Remediation Suggestions
-
Make static analysis the default
- Clone repositories without executing their contents.
- Inspect manifests, lockfiles, setup scripts, build definitions, test configuration, and executable entry points before installation.
- Generate architecture documentation from source inspection unless execution is explicitly necessary.
-
Require informed user approval
- Display every proposed installation and execution command before running it.
- Explain that repository code and dependency hooks may execute arbitrary commands.
- Obtain explicit approval separately for dependency installation, builds, tests, examples, and application startup.
-
Use an ephemeral sandbox
- Execute untrusted projects in a disposable container or virtual machine.
- Run as an unprivileged user with no administrative or host-level capabilities.
- Do not mount the user's home directory, SSH directory, cloud configuration, package-manager credentials, or unrelated workspaces.
- Use a fresh temporary workspace that can be destroyed after analysis.
-
Remove secrets and constrain access
- Clear inherited environment variables and provide only variables strictly required for the test.
- Do not expose API tokens, SSH agents, cloud metadata endpoints, credential stores, or host sockets.
- Deny outbound network access by default and allowlist only destinations demonstrably required for setup or testing.
- Prevent access to internal networks and local services unless explicitly approved.
-
Harden dependency installation
- Prefer committed lockfiles and pinned dependency versions.
- Review package sources and reject unexpected registries, Git-based dependencies, local path escapes, and unpinned remote references.
- Verify checksums or signatures where the ecosystem supports them.
- Disable lifecycle and post-install scripts by default, enabling individual ...[truncated 888 chars]
-