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

Content
View full analysis

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
View 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