T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.en.md:35
- Finding
- Mutable Remote Repository Is Retrieved and Executed Without Integrity Verification## Vulnerability Details **File Location**: `SKILL.en.md:35-40` and `SKILL.md:29-34` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High **Complete vulnerable code snippets:** `SKILL.en.md:35-40` ```bash # The Benxiang protocol repo (engine, world spec, self-tests): git clone https://github.com/dongsheng123132/2origin.git cd 2origin # Verify the engine: node adapters/story/selftest.mjs # 42 assertions ``` `SKILL.md:29-34` ```bash # 本象协议仓库（含引擎、世界规格、自测）： git clone https://github.com/dongsheng123132/2origin.git cd 2origin # 验证引擎可用： node adapters/story/selftest.mjs # 42 项自测 ``` The same external codebase is also executed through the demo command at `SKILL.en.md:108-109` and `SKILL.md:101-102`: ```bash node adapters/story/selftest.mjs node adapters/story/demo.mjs ``` ### Technical Analysis The installation workflow clones the mutable default branch of an external GitHub repository and then instructs the user or agent to execute JavaScript obtained from that repository. It does not pin an immutable commit, verify a cryptographic checksum or signature, or include the executable source within the audited project. Therefore, the effective executable payload can change after this Skill has been reviewed. The two audited Markdown files do not provide enough information to determine what the referenced Node.js entry points will do at execution time. A compromise of the upstream account, repository, default branch, or maintainer workflow could replace the expected scripts with arbitrary JavaScript. This is best classified as remote payload retrieval and execution rather than embedded malicious code: no malicious executable code was found inside the audited project, but its documented workflow retrieves and executes externally controlled code. ### Attack Path 1. An attacker compromises the upstream GitHub account, repository, maintainer credentials, or pu ...[truncated 1504 chars]
- Remediation
- ## Remediation Suggestions 1. Pin the repository to a reviewed, immutable full commit hash rather than executing the default branch: ```bash git clone https://github.com/dongsheng123132/2origin.git cd 2origin git checkout --detach <reviewed-full-commit-hash> ``` 2. Publish and verify a cryptographic checksum or signed release artifact before execution. Abort installation if verification fails. 3. Prefer vendoring the required executable files into the Skill package so they are included in the same security review. Include an inventory of vendored files and their provenance. 4. If remote installation remains necessary, use a signed release tag and verify the signature against a documented, trusted maintainer key. A tag alone is insufficient because tags can be moved or replaced. 5. Review the pinned entry points and their complete transitive dependency graph before execution. Lock all package dependencies with integrity metadata and avoid lifecycle scripts unless explicitly required and reviewed. 6. Execute verification and demo programs in a restricted environment with minimal filesystem access, no unnecessary credentials, and outbound networking disabled where feasible. 7. Update both language variants of the Skill so their secure installation instructions remain equivalent.