Security audit
Security checks for vulnerabilities and agentic risk
This is a disclosed local file-writing skill, but its broad overwrite authority and confirmed data-integrity flaws make it something users should review carefully before installing.
Install only if you trust agents to write local files on your behalf and can closely review every path and content payload. Avoid using it for production configs, .env files, scripts, or existing spreadsheets unless you have backups and explicitly approve the write; do not rely on --encoding for non-UTF-8 output or on XLSX append to preserve existing workbook data.
write_file.py:490XLSX append mode silently destroys existing spreadsheet data
write_file.py:185Sensitive-path protection can be bypassed through symbolic links and path replacement races
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# 预期输出: [操作中止] 检测到潜在安全风险，请使用 --force 参数确认执行
# 测试 2: 写入敏感文件类型（应被中止）
python write_file.py "/path/to/.env" "SECRET=test"
# 预期输出: [安全警告] 警告：目标文件可能包含敏感信息
# 测试 3: 写入可执行脚本（应输出警告）
The skill presents itself as enterprise-safe, but its documented behavior still permits writing to sensitive paths, executable scripts, and credential-related files with only warning-based controls and a bypass flag. This creates a dangerous trust mismatch: an agent may invoke it assuming meaningful policy enforcement, while the tool can still be used to overwrite configs, persistence scripts, or secret-bearing files.
Explicitly supporting writes to .env files enables modification of credential-bearing configuration commonly used for secrets, API keys, and service credentials. In the context of a generic file-writing skill, this is especially dangerous because an agent can be induced to plant, replace, or corrupt secrets, redirect services, or weaken security controls with a single file write.
|------|--------|----------|
| **文本类** | .txt, .md, .markdown, .rst, .log, .csv, .tsv | UTF-8 文本写入 |
| **代码类** | .java, .py, .js, .ts, .jsx, .tsx, .c, .cpp, .h, .cs, .go, .rs, .rb, .php, .vue | UTF-8 文本写入 |
| **配置类** | .json, .xml, .yaml, .yml, .toml, .ini, .cfg, .properties, .gradle, .config, .env | UTF-8 文本写入 |
| **样式类** | .html, .htm, .css, .scss, .sass, .less | UTF-8 文本写入 |
| **脚本类** | .sh, .bash, .bat, .cmd, .ps1, .sql | UTF-8 文本写入 |
| **Office** | .docx (Word), .xlsx (Excel) | OpenXML ZIP 格式写入 |
Allowing writes to .env.production is especially dangerous because production deployments commonly ingest it automatically, so a single file modification can change credentials, service endpoints, feature flags, or execution behavior at runtime. In an enterprise file-writer skill, this raises the impact from ordinary file output to potential production compromise and persistence.
'.sql', '.graphql', '.gql',
# 配置文件
'.config', '.env', '.env.example', '.env.local', '.env.production',
'.htaccess', '.editorconfig', '.gitignore', '.gitattributes', '.gitmodules',
'.dockerfile', '.dockerignore',
'.makefile', '.mk', '.cmake',
Allowing writes to .env.production is especially dangerous because production deployments commonly ingest it automatically, so a single file modification can change credentials, service endpoints, feature flags, or execution behavior at runtime. In an enterprise file-writer skill, this raises the impact from ordinary file output to potential production compromise and persistence.
'.sql', '.graphql', '.gql',
# 配置文件
'.config', '.env', '.env.example', '.env.local', '.env.production',
'.htaccess', '.editorconfig', '.gitignore', '.gitattributes', '.gitmodules',
'.dockerfile', '.dockerignore',
'.makefile', '.mk', '.cmake',
Allowing writes to .env.production is especially dangerous because production deployments commonly ingest it automatically, so a single file modification can change credentials, service endpoints, feature flags, or execution behavior at runtime. In an enterprise file-writer skill, this raises the impact from ordinary file output to potential production compromise and persistence.
'.sql', '.graphql', '.gql',
# 配置文件
'.config', '.env', '.env.example', '.env.local', '.env.production',
'.htaccess', '.editorconfig', '.gitignore', '.gitattributes', '.gitmodules',
'.dockerfile', '.dockerignore',
'.makefile', '.mk', '.cmake',
This markdown file is written entirely in Chinese and does not indicate that language is optional or limited to a justified region-specific context. Under the policy, forcing a specific language without user opt-in is a natural-language locale violation.
The manifest description, activation conditions, safety guidance, and usage instructions consistently require Chinese comprehension. This effectively forces a specific language/locale for users and agents without documenting an opt-in or justified region-specific constraint.
The report explicitly validates overwrite-capable file writing but does not mention any safeguard, warning, or confirmation requirement around destructive writes. In a file-writer skill, this omission can normalize unsafe usage and increase the risk of accidental data loss or abuse to replace important local files, especially in enterprise contexts where sensitive configuration or document files may exist.
The natural-language description is entirely in Chinese and presents the skill's behavior and support scope only in that language. For a general-purpose file writer, this appears to impose a language/locale constraint without user opt-in or a documented region-specific justification, which matches the policy-violation criteria.
The module docstring presents the skill name, usage, supported file types, and operational description entirely in Chinese, which imposes a specific language on users. Under the policy, locale/language constraints should either be optional for the user or explicitly justified as region-specific; this file does neither.
The manifest explicitly claims correct UTF-8/GBK handling to avoid garbled text, and the CLI exposes an --encoding option, but the actual text write path hard-codes content.encode('utf-8'). This means GBK or any non-UTF-8 encoding request is not honored, so the implemented behavior does not match the stated capability.
The argparse description, help text, examples, warning prompts, success messages, and error output are all written in Chinese. This creates a language policy issue because users are not given a choice of language and no business or regional justification is stated in the file.
The help text explicitly documents '--encoding gbk' as a supported usage example, creating a clear expectation that encoding selection affects file output. In practice, the write path ignores the encoding argument and always writes UTF-8 bytes, so the documentation contradicts actual behavior.
No suspicious patterns detected.