Back to skill

Security audit

云效项目协作工具

Security checks for vulnerabilities and agentic risk

Overview

The skill mostly matches its stated Yunxiao project-management purpose, but its documented npm install path includes an unsafe recursive install script that warrants review before use.

Review or remove the package.json install lifecycle script before running npm install. Use a least-privilege Yunxiao token, keep .env out of version control, clear .user-cache.json when no longer needed, and be aware that create, update, and relation commands will modify Yunxiao project data.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
package.json:14
Finding
Recursive npm Install Lifecycle Can Cause Resource Exhaustion## Vulnerability Details **File Location**: `package.json:14-16` **Vulnerability Type**: Recursive package-manager lifecycle execution **Risk Level**: Medium **Vulnerable Code**: ```json "scripts": { "install": "npm install" }, ``` ### Technical Analysis npm automatically executes the `install` lifecycle script during package installation. This project defines that lifecycle script as another invocation of `npm install`. Consequently, the initial installation can start a child npm process, which processes the same package and can invoke the same lifecycle script again. This creates an unbounded recursive installation chain rather than performing a finite setup operation. The behavior is especially hazardous in automated environments where installation is performed without interactive supervision and where process, memory, or execution-time limits are not tightly configured. ### Attack Path 1. A user or CI job follows the documented installation process and runs `npm install`. 2. npm resolves the dependencies and reaches the package's `install` lifecycle stage. 3. The lifecycle script launches another `npm install` process. 4. The child npm process processes the same lifecycle configuration. 5. Additional npm processes may continue to be created until the installation fails or the operating system, container, or CI runner exhausts a resource limit. No external attacker input is required. Triggering the documented installation operation is sufficient. ### Impact Assessment This issue does not grant additional privileges. Every child process runs with the same operating-system privileges as the user or service account that initiated npm. Potential consequences include: - CPU, memory, process-table, or disk exhaustion. - Denial of service on developer workstations or shared CI runners. - Installation timeouts and failed deployments. - Creation of orphaned or lingering npm processes. - Consumption ...[truncated 142 chars]
Remediation
## Remediation Suggestions 1. Remove the recursive lifecycle script entirely: ```json "scripts": {} ``` 2. If explicit setup is required, implement it as a finite script under a non-lifecycle command: ```json "scripts": { "setup": "node scripts/setup.js" } ``` 3. Ensure setup scripts perform only bounded, idempotent operations and never invoke `npm install` recursively. 4. Update `SKILL.md` to document the corrected installation process. 5. Add a CI installation test with process and execution-time limits to detect recursive lifecycle behavior.

T08 · Insecure Dependencies

Note
Location
package.json:19
Finding
Unused Dependencies Expand the Package Installation Attack Surface## Vulnerability Details **File Location**: `package.json:19-22`; related transitive package metadata at `package-lock.json:176-189` **Vulnerability Type**: Unnecessary supply-chain and lifecycle-script exposure **Risk Level**: Low **Declared Dependencies**: ```json "dependencies": { "@alicloud/devops20210625": "^5.0.3", "@alicloud/openapi-client": "^0.4.15" } ``` **Relevant Transitive Package Metadata**: ```json "node_modules/@alicloud/openapi-core": { "version": "1.0.7", "resolved": "https://registry.npmjs.org/@alicloud/openapi-core/-/openapi-core-1.0.7.tgz", "integrity": "sha512-I80PQVfmlzRiXGHwutMp2zTpiqUVv8ts30nWAfksfHUSTIapk3nj9IXaPbULMPGNV6xqEyshO2bj2a+pmwc2tQ==", "hasInstallScript": true, "license": "ISC", "dependencies": { "@alicloud/credentials": "^2.4.2", "@alicloud/gateway-pop": "0.0.6", "@alicloud/gateway-spi": "^0.0.8", "@darabonba/typescript": "^1.0.2" } }, ``` ### Technical Analysis The executable implementation imports only the Node.js built-in `https`, `fs`, and `path` modules. The two Alibaba Cloud SDK dependencies declared in `package.json` are not imported or otherwise used by `yunxiao-projex.js`. Installing the project nevertheless downloads and processes the complete transitive dependency graph. That graph includes `@alicloud/openapi-core`, which is marked with `hasInstallScript: true`. Package installation scripts execute with the privileges of the account running npm and therefore represent a higher-risk supply-chain capability. The lockfile uses the official npm registry, includes integrity hashes, and contains no evidence that the currently locked packages are malicious. The finding is that the unused dependency chain creates avoidable exposure: compromise of an unnecessary package or its installation path could affect users even though the application does not require that package at runtime. ### Attack Path A supply-chain explo ...[truncated 1499 chars]
Remediation
## Remediation Suggestions 1. Remove both unused SDK dependencies from `package.json`: ```json "dependencies": {} ``` 2. Regenerate `package-lock.json` after removing the dependencies: ```bash rm package-lock.json npm install --package-lock-only ``` 3. If the SDKs are intentionally retained, refactor the application to use them explicitly and document why each dependency is required. 4. Review every required package with lifecycle scripts and disable scripts during installation where operationally possible: ```bash npm ci --ignore-scripts ``` 5. Continue using lockfile integrity verification and prefer `npm ci` in automated builds. 6. Run dependency vulnerability and provenance checks in CI, and minimize credentials exposed during package installation.
Vulnerability Patterns
  • 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
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (10)

Credential Access

High
Category
Privilege Escalation
Content
| `YUNXIAO_ACCESS_TOKEN` | 云效个人访问令牌 | `pt-xxxxx` |
| `YUNXIAO_ORGANIZATION_ID` | 云效组织ID | `YOUR_ORGANIZATION_ID_HERE` |

### 获取 Access Token

1. 登录云效:https://devops.aliyun.com
2. 点击头像 → 个人设置 → 个人访问令牌
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
## 配置

### 创建 .env 文件

在技能目录下创建 `.env` 文件:
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Known Vulnerable Dependency: lodash==4.17.23 — 2 advisory(ies): CVE-2025-13465 (lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and ); CVE-2021-23337 (lodash vulnerable to Code Injection via `_.template` imports key names)

High
Category
Supply Chain
Confidence
88% confidence
Finding
The lockfile pins lodash to 4.17.23, and the static finding identifies known advisories affecting this version, including prototype pollution and code injection risks in specific APIs such as _.unset and _.template. Even though package-lock.json is not executable code, it defines the exact dependency version that will be installed, so the vulnerable package is genuinely present in the supply chain; exploitability depends on whether the application or a transitive dependency invokes the affected lodash features with attacker-controlled input.

Credential Access

High
Category
Privilege Escalation
Content
# 云效项目协作工具快捷脚本

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
ENV_FILE="$SCRIPT_DIR/.env"

# 只加载明确的变量名,避免导出无关的 secrets
if [ -f "$ENV_FILE" ]; then
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Intent-Code Divergence

Medium
Confidence
93% confidence
Finding
The header usage text materially understates the tool's capabilities by documenting only read/search and create flows while the code also supports update-workitem, add-relation, current-user, and get-workitem-types. In an agent-skill context, misleading or incomplete disclosure is dangerous because a user or orchestrating agent may approve execution believing the tool is less powerful than it really is, enabling unintended state changes in a project-management system.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The script persistently stores user identity mappings in .user-cache.json without notice, consent, retention controls, or permission hardening. Even though the data is not highly secret by itself, local persistence of organization user identifiers can leak directory information to other local users, backups, or downstream tooling and is especially risky because it is automatic and silent.

Natural-Language Policy Violations

Low
Confidence
88% confidence
Finding
The package description is written only in Chinese ("云效项目协作工具 - 通过 API 管理需求、缺陷、任务等"), which can constitute a language/locale policy issue if the skill is presented to a broader audience without offering a language choice. There is no accompanying bilingual text or indication that the skill is region-specific or requires Chinese-only usage.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"author": "",
  "license": "ISC",
  "dependencies": {
    "@alicloud/devops20210625": "^5.0.3",
    "@alicloud/openapi-client": "^0.4.15"
  }
}
Confidence
83% confidence
Finding
Using a caret version range allows npm to install newer compatible releases automatically, which can introduce supply-chain risk if an upstream package ships a malicious or vulnerable update. In this package, the risk is limited because the file only declares two dependencies and does not itself contain suspicious install hooks beyond a standard npm install script, but dependency drift still weakens build reproducibility and trust.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"license": "ISC",
  "dependencies": {
    "@alicloud/devops20210625": "^5.0.3",
    "@alicloud/openapi-client": "^0.4.15"
  }
}
Confidence
83% confidence
Finding
Using a caret version range allows npm to resolve to later releases, increasing the chance of consuming a compromised or newly vulnerable dependency without explicit review. The context does not show overtly malicious behavior, but unpinned dependencies remain a legitimate supply-chain weakness.

Missing User Warnings

Low
Confidence
79% confidence
Finding
The script sends data to a remote Yunxiao API using HTTPS, including access-token-authenticated requests and request bodies for search, create, update, and relation operations. Although network access is inherent to the tool's purpose, the help text does not explicitly disclose that supplied work item content and identifiers are transmitted to a remote service.