Back to skill

Security audit

origin-office

Security checks for vulnerabilities and agentic risk

Overview

The skill’s document-conversion purpose is coherent, but it tells users to run unpinned code from a mutable external GitHub repository.

Install only if you are willing to trust the external 2origin repository at the time you run it. Prefer pinning to a reviewed commit and running the npm command in a disposable, least-privileged sandbox without sensitive files or credentials mounted.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (1)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:30
Finding
Execution of Unpinned Code Retrieved from a Mutable Remote Repository## Vulnerability Details **File Location**: `SKILL.md:30-35`; `SKILL.en.md:33-38` **Vulnerability Type**: T03: Remote Payload Retrieval and Execution **Risk Level**: High ### Vulnerable Code `SKILL.md:30-35` ```bash # 本象协议仓库 git clone https://github.com/dongsheng123132/2origin.git cd 2origin # 验证 npm run test:office # 20 项断言(docx + pptx 合成夹具 + 统一 CLI 建包/验证/篡改检出) ``` `SKILL.en.md:33-38` ```bash # The Benxiang protocol repo git clone https://github.com/dongsheng123132/2origin.git cd 2origin # Verify npm run test:office # 20 assertions (docx + pptx synthetic fixtures + unified CLI: build/verify/tamper detection) ``` ### Technical Analysis The installation instructions clone the mutable default branch of an external GitHub repository and subsequently execute an npm script from that repository. No immutable commit, verified release, checksum, or cryptographic signature is specified. Because the effective contents of `test:office` and any scripts it invokes are controlled by the current state of the remote repository, the code executed by users can change after this Skill has been reviewed. The implementation is not included in the audited project, so its behavior and dependency lifecycle cannot be validated from the supplied files. This finding does not establish that the current remote repository is malicious. The vulnerability is the trust model: control of the repository, its default branch, or a relevant dependency can be converted into local code execution when a user follows the documented commands. ### Attack Path 1. An attacker compromises the remote repository owner, a maintainer account, or another mechanism capable of changing the default branch. 2. The attacker modifies the `test:office` npm script, a script it calls, or package lifecycle behavior to execute an arbitrary payload. 3. A user follows the Skill installation instructions and runs: ```bash git clone https://git ...[truncated 1168 chars]
Remediation
## Remediation Suggestions 1. Pin the repository to a specific, reviewed commit rather than relying on its mutable default branch: ```bash git clone https://github.com/dongsheng123132/2origin.git cd 2origin git checkout --detach <reviewed-full-commit-sha> ``` 2. Publish the expected full commit identifier in both Skill files and update it only after security review. 3. Prefer a signed release and verify its signature against a documented, trusted maintainer key before executing any code. 4. If distributing an archive, publish and verify a SHA-256 digest before extraction or execution. 5. Vendor the required implementation into the audited Skill package where feasible, allowing the executed code to be reviewed together with the instructions. 6. Review `package.json`, the exact `test:office` command, npm lifecycle hooks, transitive dependencies, and all scripts reachable from the command before execution. 7. Use lockfiles with integrity metadata and immutable dependency versions. Install dependencies with a reproducible command such as `npm ci`, after reviewing the lockfile. 8. Run verification commands in a disposable, least-privileged container or sandbox without host credentials, sensitive mounts, or unnecessary network access. 9. Keep the Chinese and English instructions synchronized so both versions enforce the same pinned and verified installation process.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.