axios-supply-chain-attack-check

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:35 AM UTC
• Version: 1.0.0

Overview

This skill is meant for axios incident cleanup, but running it can automatically rewrite project dependencies and delete host files without confirmation.

Only run this in a disposable or backed-up project after reviewing the script. Expect it to change dependencies, remove lockfiles, reinstall packages, and possibly delete files outside the project; prefer a read-only audit or a manually controlled remediation workflow.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/check-axios-risk.sh:70
• Finding: Automatic Destructive Dependency Remediation Without User Confirmation<![CDATA[ ## Vulnerability Details **File Location**: `scripts/check-axios-risk.sh`, lines 70–80 **Vulnerability Type**: Destructive and nondeterministic dependency remediation **Risk Level**: High ### Vulnerable Code ```bash # 修复步骤1：卸载恶意包 echo -e "${YELLOW}→ 卸载恶意 axios & plain-crypto-js...${NC}" npm uninstall axios plain-crypto-js 2>/dev/null || true # 修复步骤2：清理缓存 + 重装官方稳定版 echo -e "${YELLOW}→ 安装官方安全版本 axios（最新稳定版）...${NC}" npm install axios@latest --save # 修复步骤3：清理 node_modules + 重新安装（彻底清除残留） echo -e "${YELLOW}→ 清理依赖并重新安装...${NC}" rm -rf node_modules package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null || true npm install 2>/dev/null || true ``` ### Technical Analysis Detection of any configured indicator immediately initiates destructive project modification without displaying a proposed plan or requesting confirmation. The script uninstalls dependencies, installs a mutable `latest` package version, deletes all supported lockfiles, removes the installed dependency tree, and resolves the project's dependencies again. Deleting lockfiles removes the integrity and version constraints that provide reproducible installations. The subsequent `npm install` can therefore resolve versions different from those previously reviewed or tested. In addition, npm installation can execute lifecycle scripts from resolved packages with the privileges of the user running this Skill. The use of `axios@latest` is nondeterministic. It does not identify a specific reviewed version and can introduce breaking changes or supply-chain risk if the registry package changes after the Skill itself was audited. These actions are also performed when the detected indicator is only one of the absolute system files, even if no malicious npm dependency was found. ### Attack Path 1. The user runs `bash ./scripts/check-axios-risk.sh`. 2. One configured indicator is detected, such as a matching dependency version or one of the hard-coded system file paths. 3. The script automatically unin ...[truncated 877 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make the default behavior report-only and require an explicit remediation flag, such as `--remediate`. 2. Present all planned file and dependency changes and require interactive confirmation before destructive operations. 3. Do not delete lockfiles automatically. Preserve the lockfile and use the package manager already associated with the project. 4. Pin remediation to an exact, independently reviewed package version instead of using `axios@latest`. 5. Use lock-preserving installation mechanisms such as `npm ci` where appropriate. 6. Consider disabling dependency lifecycle scripts during initial recovery, for example through `--ignore-scripts`, followed by a reviewed rebuild procedure. 7. Back up the manifest and lockfile before making changes and restore them if remediation fails. 8. Separate dependency remediation from host-level incident response so that a system-file indicator does not automatically rewrite project dependencies. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/check-axios-risk.sh:38
• Finding: Deletion of Absolute System Files Based Only on Path Existence<![CDATA[ ## Vulnerability Details **File Location**: `scripts/check-axios-risk.sh`, lines 38–48 and 82–87 **Vulnerability Type**: Unvalidated deletion outside the project boundary **Risk Level**: High ### Vulnerable Code ```bash RISK_FILES=() if [ -f "/Library/Caches/com.apple.act.mond" ]; then echo -e "${RED}⚠️ macOS 恶意文件：/Library/Caches/com.apple.act.mond${NC}" RISK_FILES+=("/Library/Caches/com.apple.act.mond") HAS_RISK=1 fi if [ -f "/tmp/ld.py" ]; then echo -e "${RED}⚠️ Linux 恶意文件：/tmp/ld.py${NC}" RISK_FILES+=("/tmp/ld.py") HAS_RISK=1 fi ``` ```bash # 修复步骤4：删除系统恶意文件 if [ ${#RISK_FILES[@]} -gt 0 ]; then echo -e "${YELLOW}→ 删除系统恶意文件...${NC}" for file in "${RISK_FILES[@]}"; do rm -f "$file" 2>/dev/null || true done fi ``` ### Technical Analysis The script treats the mere existence of two absolute paths as conclusive evidence of malware. It does not validate file contents, cryptographic hashes, ownership, timestamps, signatures, or provenance before adding the paths to the deletion list. The subsequent `rm -f` operation crosses the target project's boundary and deletes the files without user confirmation. A legitimate or unrelated file at either path can therefore be removed as a false positive. The danger increases if the script is executed with elevated privileges, although the script itself does not attempt to acquire those privileges. Suppressing deletion errors also prevents the operator from learning whether cleanup succeeded. ### Attack Path 1. A legitimate, unrelated, or attacker-created regular file exists at `/tmp/ld.py` or `/Library/Caches/com.apple.act.mond`. 2. The user invokes the audit script. 3. The path-existence check marks the host as compromised without validating the file. 4. The script enters automatic remediation mode. 5. It invokes `rm -f` against the absolute path without confirmation. 6. If the invoking account has permission, the file is deleted. 7. The same indicator also causes unrelated project depen ...[truncated 511 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not delete a file based solely on its pathname. 2. Collect and display metadata such as ownership, permissions, timestamps, size, and a cryptographic hash. 3. Compare the hash against a trusted and versioned indicator set before classifying the file. 4. Default to reporting the indicator and require explicit authorization for quarantine or deletion. 5. Prefer quarantine to deletion so the file remains available for forensic review and restoration. 6. Keep host-level remediation separate from project dependency auditing. 7. Refuse to perform host-level deletion when running with elevated privileges unless the operator explicitly opts in. 8. Report deletion failures and return a nonzero status instead of suppressing errors. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/check-axios-risk.sh:73
• Finding: Suppressed Remediation Failures Produce Misleading Security and Success Claims<![CDATA[ ## Vulnerability Details **File Location**: `scripts/check-axios-risk.sh`, lines 73–98 **Vulnerability Type**: Fail-open error handling and inaccurate security reporting **Risk Level**: Medium ### Vulnerable Code ```bash npm uninstall axios plain-crypto-js 2>/dev/null || true # 修复步骤2：清理缓存 + 重装官方稳定版 echo -e "${YELLOW}→ 安装官方安全版本 axios（最新稳定版）...${NC}" npm install axios@latest --save # 修复步骤3：清理 node_modules + 重新安装（彻底清除残留） echo -e "${YELLOW}→ 清理依赖并重新安装...${NC}" rm -rf node_modules package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null || true npm install 2>/dev/null || true # 修复步骤4：删除系统恶意文件 if [ ${#RISK_FILES[@]} -gt 0 ]; then echo -e "${YELLOW}→ 删除系统恶意文件...${NC}" for file in "${RISK_FILES[@]}"; do rm -f "$file" 2>/dev/null || true done fi echo -e "\n${GREEN}=====================================================${NC}" echo -e "${GREEN}✅ 安全修复完成！${NC}" echo -e "${GREEN}✅ 已卸载恶意版本 → 已安装官方最新 axios${NC}" echo -e "${GREEN}=====================================================${NC}" echo -e "\n${YELLOW}提示：修复后请重启项目生效！${NC}" else echo -e "${GREEN}=====================================================${NC}" echo -e "${GREEN}✅ 项目安全，未检测到任何 Axios 投毒风险${NC}" echo -e "${GREEN}=====================================================${NC}" fi ``` ### Technical Analysis Critical operations append `|| true` and redirect standard error to `/dev/null`. This converts failures into successful shell statuses and removes diagnostic information. Although `set -euo pipefail` is enabled, the explicit `|| true` clauses bypass its fail-fast behavior. The script subsequently prints unconditional claims that remediation completed and that the malicious package was replaced. These claims can be false if uninstalling, reinstalling, deleting lockfiles, or removing host files failed. The clean branch also states that the project is safe. The checks only cover two exact axios version strings, one exact `plain-crypto-js` version, and two file paths. Absence of those limited i ...[truncated 1280 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `|| true` from security-critical operations. 2. Preserve standard error or capture it in a clearly identified audit log. 3. Check the exit status of every uninstall, install, removal, and quarantine operation. 4. Track each remediation action independently and print a verified result for each step. 5. Exit with a nonzero status if any required remediation action fails. 6. Re-run the detection checks after remediation and only report removal for indicators that were verified as absent. 7. Replace absolute statements such as “the project is safe” with precise wording such as “none of the indicators checked by this script were detected.” 8. Document the limited detection scope and recommend broader incident-response and forensic procedures when any compromise indicator is found. ]]>

SkillSpector

Vulnerability Patterns

• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Natural-Language Policy Violations

Medium

• Confidence: 91% confidence
• Finding: The description and instructions are written in Chinese, which effectively forces a specific language for users of the skill. The file does not offer an opt-in language choice or explain that the skill is intended only for a Chinese-speaking or region-specific audience.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The comments and all user-facing status messages are written in Chinese, which imposes a specific language on users. The policy allows locale-specific behavior only when it is explicitly justified or when users are given a choice, neither of which appears in this file.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: This script is named and presented as a risk check, but it conditionally performs destructive remediation: uninstalling packages, deleting lockfiles and node_modules, reinstalling dependencies, and removing files from system paths. That mismatch is dangerous because users may invoke it expecting read-only inspection, while it actually changes the project and host state, increasing the chance of unintended dependency drift, build breakage, or deletion of files without informed consent.

Static analysis

No suspicious patterns detected.