email-pro-optimized

• Outcome: Review
• Latest audit: Sep 12, 2026 · 7:22 AM UTC
• Version: 2.2.0

Overview

This email skill has real email functionality, but it also ships exposed OAuth credentials and undocumented developer scripts that can publish code or overwrite another workspace.

Install only after reviewing and removing the exposed Outlook OAuth secret, using your own OAuth app credentials, and avoiding or deleting auto-push.py and sync-updates.py. Treat files under ~/.openclaw/credentials as sensitive, review OAuth scopes before granting access, and verify every send, attachment, backup, or repository-push action before running it.

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 (6)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/authorize-outlook.sh:6
• Finding: Hard-Coded Outlook OAuth Client Secret<![CDATA[ ## Vulnerability Details **File Location**: `scripts/authorize-outlook.sh:6-9`; duplicated in `README.md:30-35` and `README.md:109-115` **Vulnerability Type**: Hard-coded reusable application credential **Risk Level**: High ### Vulnerable Code ```bash python3 authorize.py outlook \ --client-id "0360031a-ad0e-4bce-9d2f-0c53eda894b8" \ --client-secret "914fb58f-4aea-4ddb-bb97-51d66581cfee" \ --tenant-id "40a99b83-a343-41ca-b303-3e122965a6d8" \ --name "outlook_live" ``` The same client ID, client secret, and tenant ID are also published in the project documentation and example configuration. ### Technical Analysis A live-looking, reusable OAuth client secret is embedded directly in the distributed Skill. Anyone who can download the package, inspect its documentation, or access its source history can recover the credential. The shell wrapper also passes the secret as a command-line argument. Depending on the operating system and execution environment, command-line arguments may be exposed through process inspection, audit logs, shell tracing, monitoring tools, or diagnostic reports. Although an OAuth client secret does not independently provide mailbox access, it authenticates the application during authorization-code exchange and token refresh. Its disclosure destroys the confidentiality expected of a confidential-client credential and can facilitate application impersonation or OAuth-flow abuse. ### Attack Path 1. An attacker downloads or otherwise obtains the Skill package. 2. The attacker extracts the client secret, client ID, and tenant ID from `authorize-outlook.sh` or `README.md`. 3. The attacker configures a client that impersonates the distributed OAuth application. 4. The attacker combines the exposed credential with authorization codes, refresh tokens, redirect-flow weaknesses, or social engineering to perform token exchanges as that application. 5. The compromised application credential remains usable until revoked or expired. ...[truncated 553 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed Azure client secret immediately. 2. Remove the secret from the shell script, README, example configuration, release artifacts, and repository history. 3. Require each operator to register or supply their own OAuth application credentials. 4. Load confidential values from protected environment variables, an operating-system secret manager, or an owner-readable configuration file. 5. Do not pass secrets through command-line arguments. Read them from the environment, a protected file descriptor, or an interactive secret prompt. 6. Add automated secret scanning to the release and commit process. 7. Review authorization and token logs for historical use of the exposed application credential. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/auto-push.py:13
• Finding: Shell Command Injection Through Git-Controlled Filenames<![CDATA[ ## Vulnerability Details **File Location**: `scripts/auto-push.py:13-21` and `scripts/auto-push.py:72-98` **Vulnerability Type**: OS command injection **Risk Level**: High ### Vulnerable Code ```python def run_command(cmd, cwd=None): try: result = subprocess.run( cmd, shell=True, cwd=cwd or SKILL_DIR, capture_output=True, text=True, timeout=30 ) return result.returncode == 0, result.stdout, result.stderr ``` Git-controlled filenames are incorporated into the commit message: ```python message += "\n📋 Changes:\n" for status, filename in changed_files: if status.startswith('M'): message += f" ✏️ {filename}\n" elif status.startswith('A'): message += f" ➕ {filename}\n" elif status.startswith('D'): message += f" ➖ {filename}\n" message += f"\n🤖 Auto-committed by sync script" return message ``` The resulting message is interpolated into a shell command with incomplete escaping: ```python def commit_changes(message): escaped_message = message.replace('"', '\\"').replace('$', '\\$') success, stdout, stderr = run_command(f'git commit -m "{escaped_message}"') ``` ### Technical Analysis `git status --porcelain` supplies filenames that are treated as untrusted input. Those filenames are copied into a commit message and then interpolated into a command executed with `shell=True`. Escaping only double quotes and dollar signs does not make a string safe for shell evaluation. Shell metacharacters and constructs such as backticks, backslashes, command substitutions, and embedded control characters can retain special meaning. A repository containing a crafted filename can therefore transform an intended `git commit` operation into arbitrary shell execution. The flaw is particularly dangerous because the script is expressly intended to operate on changed and untracked repository content, which is exactly where an a ...[truncated 1178 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `shell=True` from every subprocess invocation. 2. Pass commands as argument arrays: ```python subprocess.run( ["git", "commit", "-m", message], shell=False, cwd=cwd or SKILL_DIR, capture_output=True, text=True, timeout=30, check=False, ) ``` 3. Convert all other Git commands to fixed argument arrays, including status, add, log, branch lookup, and push. 4. Parse Git output using a NUL-delimited format such as `git status --porcelain -z` so unusual filenames cannot corrupt line-oriented parsing. 5. Do not attempt to implement shell safety through ad hoc character replacement. 6. Add tests using filenames containing quotes, backticks, dollar signs, backslashes, newlines, spaces, and leading dashes. 7. Consider removing this developer-oriented publishing utility from the distributed email Skill. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/oauth_handler.py:24
• Finding: OAuth Login CSRF and Account Misbinding Due to Missing State Validation<![CDATA[ ## Vulnerability Details **File Location**: `scripts/oauth_handler.py:24-31`, `scripts/oauth_handler.py:51-61`, and `scripts/oauth_handler.py:99-108` **Vulnerability Type**: OAuth callback CSRF and authorization-response misbinding **Risk Level**: High ### Vulnerable Code The callback accepts any authorization code without validating a flow-specific state value: ```python def do_GET(self): query = urlparse(self.path).query params = parse_qs(query) if 'code' in params: OAuthCallbackHandler.auth_code = params['code'][0] self.send_response(200) self.send_header('Content-type', 'text/html; charset=utf-8') self.end_headers() self.wfile.write(b'<html><body><h1>Authorization Success!</h1><p>You can close this window now.</p></body></html>') else: self.send_response(400) self.end_headers() ``` The Gmail authorization URL contains no `state` value: ```python params = { 'client_id': self.client_id, 'redirect_uri': self.redirect_uri, 'response_type': 'code', 'scope': 'https://www.googleapis.com/auth/gmail.modify', 'access_type': 'offline', 'prompt': 'consent' } return f"{self.auth_uri}?{urlencode(params)}" ``` The Outlook authorization URL has the same omission: ```python params = { 'client_id': self.client_id, 'redirect_uri': self.redirect_uri, 'response_type': 'code', 'scope': 'https://graph.microsoft.com/.default', 'access_type': 'offline' } return f"{self.auth_uri}?{urlencode(params)}" ``` ### Technical Analysis OAuth authorization-code clients must generate an unpredictable, per-authorization `state` value and verify that the callback contains the same value. This binds the callback to the authorization attempt initiated by the local client and prevents login CSRF and authorization-response substitution. This implementation neither sends nor validates `state`. The local HTTP handler accepts the first request containing a `code` query ...[truncated 1759 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Generate a cryptographically random state value for every authorization attempt, for example with `secrets.token_urlsafe(32)`. 2. Include that state in the authorization URL. 3. Store the expected state only for the lifetime of the local authorization attempt. 4. Compare callback state using `hmac.compare_digest()` and reject missing or mismatched values. 5. Reset `OAuthCallbackHandler.auth_code` and all flow state before starting each callback server. 6. Restrict callbacks to a fixed expected path rather than accepting codes on arbitrary paths. 7. Add PKCE with an S256 code challenge and verifier, particularly because this is a local/native-style client. 8. Shut down and close the HTTP server deterministically after success or timeout. 9. Return a failure response for provider error parameters and do not save token responses unless all required token fields are present. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: scripts/sync-updates.py:69
• Finding: Undisclosed Writes Into a Separate OpenClaw Workspace<![CDATA[ ## Vulnerability Details **File Location**: `scripts/sync-updates.py:14-16` and `scripts/sync-updates.py:69-87` **Vulnerability Type**: Cross-workspace file modification **Risk Level**: Medium ### Vulnerable Code ```python SKILL_DIR = Path.home() / '.openclaw' / 'skills' / 'email-pro-optimized' WORKSPACE_DIR = Path.home() / '.openclaw' / 'workspace-telegram-bot1' SYNC_STATE_FILE = SKILL_DIR / '.sync-state.json' ``` ```python def sync_to_workspace(changed_files): if not changed_files: print("\n✅ No synchronization required") return True workspace_skill_dir = WORKSPACE_DIR / 'skills' / 'email-pro-optimized' workspace_skill_dir.mkdir(parents=True, exist_ok=True) for file_rel_path in changed_files: src = SKILL_DIR / file_rel_path dst = workspace_skill_dir / file_rel_path dst.parent.mkdir(parents=True, exist_ok=True) shutil.copy2(src, dst) return True ``` The displayed status text has been translated for report readability; the file operations are unchanged. ### Technical Analysis The Skill is declared as an email-management utility, but this maintenance script writes Skill code and documentation into a separate, hard-coded Telegram-bot workspace. This crosses the Skill's normal directory boundary and is not required to read, analyze, or send email. The destination is selected without an operator-provided path, ownership validation, confirmation, backup, or check for existing unrelated content. `shutil.copy2()` overwrites destination files with the same names and preserves source metadata. The distributed documentation's file-structure sections do not identify this synchronization utility, making the cross-workspace behavior insufficiently disclosed to users. ### Attack Path 1. The user has an OpenClaw workspace at `~/.openclaw/workspace-telegram-bot1`. 2. The user runs `scripts/sync-updates.py`, believing it is a maintenance operation for the email Skill. 3. The script detect ...[truncated 749 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove this developer-specific synchronization script from the distributed email Skill. 2. If synchronization is retained, require the destination workspace to be supplied explicitly by the operator. 3. Display the resolved source and destination paths and require confirmation before writing. 4. Restrict destinations to an approved workspace root after resolving symlinks and normalized paths. 5. Refuse to overwrite existing files unless the user explicitly approves each overwrite. 6. Create backups or use atomic writes with rollback support. 7. Document every cross-workspace write in `SKILL.md` and explain why it is necessary. 8. Run maintenance and publishing utilities separately from normal email operations and under narrower filesystem permissions. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: scripts/auto-push.py:50
• Finding: Broad Repository Staging and Unreviewed Network Publication<![CDATA[ ## Vulnerability Details **File Location**: `scripts/auto-push.py:50-62` and `scripts/auto-push.py:112-135` **Vulnerability Type**: Overbroad file collection and Git upload **Risk Level**: Medium ### Vulnerable Code ```python def stage_changes(): success, stdout, stderr = run_command("git add -A") if success: print("✅ All changes staged") return True else: print(f"❌ Staging failed: {stderr}") return False ``` ```python def push_changes(): success, branch, _ = run_command("git rev-parse --abbrev-ref HEAD") if not success: return False branch = branch.strip() success, stdout, stderr = run_command(f"git push origin {branch}") if success: return True else: if "no upstream branch" in stderr.lower() or "set-upstream" in stderr.lower(): success, _, _ = run_command(f"git push -u origin {branch}") if success: return True return False ``` The displayed messages have been translated for report readability; the staging and push commands are unchanged. ### Technical Analysis `git add -A` stages every modified, deleted, and untracked file visible to the repository, rather than only files belonging to the Skill or files explicitly selected by the user. The script then creates a commit and pushes it to the configured `origin`. This behavior can collect unrelated repository content, local artifacts, temporary files, configuration data, or credentials that were accidentally created under the repository root. The configured remote is not allowlisted or presented for approval before transmission. Automatic commit and push behavior is not necessary for email reading or sending. It is a developer publishing operation with materially greater filesystem and network authority than the Skill's declared runtime purpose. ### Attack Path 1. A credential file, private configuration, generated artifact, or other sensitive file exi ...[truncated 883 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove automatic publishing utilities from the runtime Skill package. 2. Replace `git add -A` with an explicit allowlist of intended Skill files. 3. Show the complete staged diff and require confirmation before committing. 4. Resolve and display the remote URL and branch before any push, then require explicit approval. 5. Reject unexpected remote hosts or repositories unless the user deliberately overrides the restriction. 6. Add repository-level secret scanning before commit and push. 7. Abort when credential-like filenames or high-entropy secrets are detected. 8. If a sensitive file has already been committed, remove it from Git history and rotate the affected credential; deleting it in a later commit is insufficient. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: scripts/oauth_handler.py:51
• Finding: OAuth Scopes Exceed the Minimum Privileges Required<![CDATA[ ## Vulnerability Details **File Location**: `scripts/oauth_handler.py:51-58` and `scripts/oauth_handler.py:99-105` **Vulnerability Type**: Excessive OAuth authorization scope **Risk Level**: Medium ### Vulnerable Code Gmail authorization requests mailbox modification authority: ```python params = { 'client_id': self.client_id, 'redirect_uri': self.redirect_uri, 'response_type': 'code', 'scope': 'https://www.googleapis.com/auth/gmail.modify', 'access_type': 'offline', 'prompt': 'consent' } ``` Outlook authorization requests all permissions preconfigured for the application: ```python params = { 'client_id': self.client_id, 'redirect_uri': self.redirect_uri, 'response_type': 'code', 'scope': 'https://graph.microsoft.com/.default', 'access_type': 'offline' } ``` ### Technical Analysis The implemented provider operations read message metadata and send messages. Gmail's `gmail.modify` scope additionally permits mailbox state modification and therefore grants authority beyond a narrowly separated read/send design. Microsoft's `.default` scope requests the statically configured permission set for the application. The source does not enumerate that set, so users cannot determine from the authorization request which mailbox privileges they are granting. Its effective authority may grow if the Azure application registration is later changed. Both flows request offline access and persist refresh tokens. Excessive scopes therefore remain usable across access-token refreshes and increase the consequences of local token theft. ### Attack Path 1. A user runs the Gmail or Outlook authorization flow. 2. The authorization request asks for `gmail.modify` or the application's full Microsoft Graph `.default` permission set. 3. The user grants consent, and the resulting access and refresh tokens are stored locally. 4. An attacker obtains the token file through another local compromise, backup exposure, or command-execut ...[truncated 565 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Define the exact operations the Skill supports and map each operation to the narrowest provider scope. 2. For Gmail, request narrowly scoped read and send permissions instead of `gmail.modify` when modification is not implemented. 3. For Microsoft Graph, enumerate explicit delegated permissions rather than relying on `.default`. 4. Separate read-only and send authorization profiles so users can enable only the capability they need. 5. Display the requested scopes before opening the browser and document them in `SKILL.md`. 6. Revoke existing broadly scoped grants and require reauthorization after reducing the scope set. 7. Protect refresh tokens with an operating-system credential store where available, rather than relying only on a plaintext JSON file with mode `0600`. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (54)

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: The README publishes real-looking Outlook OAuth client credentials, including a client secret and tenant ID, tied to a live-looking mailbox/account workflow. Even if these are test credentials, exposing reusable OAuth application secrets in public documentation enables unauthorized use of the app registration, phishing-style consent abuse, token acquisition attempts, and misuse of associated Microsoft resources.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a general-purpose, high-performance email client/library with IMAP read, SMTP send, OAuth 2.0, and concurrency across major providers. The actual code is much narrower: it only connects via IMAP to one configured account, reads INBOX messages, analyzes subjects, categorizes emails, and prints summary statistics. There is no SMTP functionality, no OAuth 2.0 flow, no concurrent processing, and no substantiation of the stated 4–5x performance claim. The primary purpose in the code chunk is email analysis rather than full email read/write tooling, so the description does not accurately represent the supplied code.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a full-featured email tool with multi-provider support (QQ, Gmail, Outlook), IMAP/SMTP functionality, OAuth 2.0, and performance/concurrency claims. The supplied code chunk only implements a command-line entrypoint for OAuth authorization for Gmail and Outlook. It does not perform email reading or sending, does not demonstrate concurrency or high-performance behavior, and does not include QQ support. Therefore, the code's actual behavior is materially narrower than the declared purpose.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description is for an email client/tool with IMAP/SMTP/OAuth functionality and performance claims. The supplied code does not implement any email-related behavior at all. Instead, it operates as a repository maintenance script for auto-committing and pushing code changes via git. This is a materially different primary purpose and uses different resources (local filesystem/git remote) than declared. Therefore, this is a clear description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 84% confidence
• Finding: The code generally matches the broad purpose of an email utility for reading and sending mail. However, the declared description specifically emphasizes IMAP/SMTP, OAuth 2.0, concurrency, and major performance gains, none of which are demonstrated in this chunk. More importantly, the code includes additional undeclared behavior: it accesses a local credential file and can enumerate all configured email accounts and metadata via `list-accounts`. That local credential/configuration access is a materially relevant capability not stated in the description. Therefore this is a partial but meaningful description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The declared description presents the skill as an operational email client/tool with IMAP/SMTP, OAuth, and concurrent mail processing. However, this code chunk does not implement email functionality itself. Instead, its primary purpose is repository/skill maintenance: checking dependencies, verifying the existence of scripts, reading and listing locally stored OAuth token accounts, validating source file contents, generating a maintenance report, and writing updated metadata with an incremented version. Access to local credential files and metadata mutation are undeclared capabilities relative to the email-tool description. Therefore the code behavior materially differs from the declared purpose.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: 该代码片段的功能范围明显比描述更窄，核心是 OAuth 2.0 授权与 token 生命周期管理，只覆盖 Gmail 和 Outlook。它通过本地 8080 回调服务器接收授权码，向 Google/Microsoft token 端点换取和刷新令牌，并将令牌写入本地凭据文件。虽然描述提到 OAuth 2.0，与代码部分一致，但描述的主要用途是完整邮件工具（QQ/Gmail/Outlook、IMAP 读、SMTP 写、并发处理、高性能），而这些关键能力在本片段中都没有体现。因此描述与实际代码行为存在实质性不匹配。

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: 整体上，这段代码的主要目的确实是邮件收发，并且覆盖 QQ、Gmail、Outlook，也包含 OAuth 2.0 相关处理，因此大方向与描述相近。但描述中的关键卖点“高性能”“并发处理”“比 imap-smtp-email 快 4-5 倍”在代码中没有体现，属于重要功能/特性缺失。此外，描述容易让人理解为三者都通过 IMAP/SMTP 工作，但实际 Gmail 和 Outlook 使用的是各自 API。再者，Outlook 的发送接口没有实现附件支持。虽然没有发现明显恶意或无关能力，但描述对实际能力有实质性夸大，因此应判定为不匹配。

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description presents an end-user email client/tool with IMAP/SMTP/OAuth capabilities and performance claims. The supplied code does not implement email access, sending, OAuth flows for providers, or concurrent email processing. Instead, it is a development/maintenance script for synchronizing skill source files, generating changelog entries, updating version metadata, and checking deployment configuration. This is a materially different primary purpose and introduces undeclared filesystem and publishing-related capabilities unrelated to the stated email functionality.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: This script is an auto-commit/auto-push utility embedded in a skill advertised as an email tool, which is a strong scope mismatch. Unrelated repository-manipulation capability increases supply-chain risk because users seeking email functionality would not reasonably expect code that stages, commits, and pushes local changes to a remote repository.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

def run_command(cmd, cwd=None):
    """运行命令"""
    try:
        result = subprocess.run(
            cmd,
            shell=True,
            cwd=cwd or SKILL_DIR,

• Confidence: 97% confidence
• Finding: Using shell=True in a generic command runner is a classic tool-parameter abuse pattern because it allows command strings to be interpreted by the shell. In this script, dynamic command construction for git push and git commit means repository-derived or attacker-influenced data can become part of executed shell syntax, enabling arbitrary command execution under the user's account.

Context-Inappropriate Capability

High

• Confidence: 96% confidence
• Finding: The code stages all changes, creates commits, and pushes to origin, performing local source-control mutation and outbound network operations unrelated to an email-processing skill. If run in a user's environment, it can publish unintended files, secrets, or malicious modifications to a remote repository, making the context especially dangerous due to the unjustified capability.

Context-Inappropriate Capability

Medium

• Confidence: 91% confidence
• Finding: The README discloses live-looking email addresses, account aliases, provider status, and exact credential/token storage paths. This leaks operational details that can aid targeted phishing, credential theft attempts, account enumeration, and discovery of sensitive local files used by the tool.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: This markdown file describes actions that transmit data to external email providers and recipients, including sending message bodies and attachments, but it does not warn users that content and files will be transmitted off-system. It also later shows mailbox export to a local backup file without caution about sensitive email data retention.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The documentation states that OAuth access and refresh tokens are automatically saved, but does not prominently warn users that these tokens are sensitive credentials that enable mailbox access. Although the file mentions storage permissions later, it does not provide a clear caution in the workflow where tokens are created and stored.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 90% confidence
• Finding: The skill declares capabilities that clearly involve reading local credential files, writing token/config files, network access, and shell execution, but it does not declare any explicit tool scope or permissions boundary. In an agent environment, this increases the chance of overbroad execution and makes sensitive operations less transparent to users and reviewers.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The send and authorization examples trigger real external actions, including browser-based account authorization and live email delivery, but the documentation does not clearly warn users that these are not dry-run commands. Users may unintentionally grant mailbox access or send real messages, especially in an automated agent setting.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation explicitly directs users to store email credentials and OAuth tokens in local files but does not include prominent warnings about their sensitivity, persistence, or secure file permissions. In an agent context, this can lead to accidental credential exposure, unsafe backups, or broader compromise of connected email accounts.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The script reads stored email credentials from a fixed path and accesses mailbox contents immediately, but provides no user-facing warning, consent prompt, or scope disclosure before handling sensitive data. In an agent-skill context, this is dangerous because mailbox access exposes private communications and account metadata, and users may not realize the skill performs live account access rather than offline analysis.

Missing User Warnings

Medium

• Confidence: 99% confidence
• Finding: The script embeds an Outlook OAuth client secret directly in a distributable shell script, exposing a credential to anyone who can read the repository or package. In an email authorization skill, this is especially risky because the secret can be reused to impersonate the application in OAuth flows, abuse Microsoft app quotas, or facilitate unauthorized token acquisition depending on app registration settings.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: This code accepts sensitive OAuth client secrets as command-line arguments and passes them into authorization routines, but provides no warning, confirmation, or user-facing notice about handling credentials. For code files, accessing sensitive credentials without any disclosure is in scope when there is no visible prompt, log, or explanatory comment/docstring describing the sensitivity of the operation.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

def run_command(cmd, cwd=None):
    """运行命令"""
    try:
        result = subprocess.run(
            cmd,
            shell=True,
            cwd=cwd or SKILL_DIR,

• Confidence: 96% confidence
• Finding: The helper executes shell commands via subprocess.run(..., shell=True), which turns any string passed into run_command into shell-interpreted input. In this file, later commands interpolate values such as the current git branch into command strings, so a crafted branch name or future caller-controlled input could trigger command injection and arbitrary command execution.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The main flow automatically stages, commits, and pushes repository changes without a confirmation prompt, dry-run preview, or explicit warning about consequences. This can cause irreversible or hard-to-revert publication of local changes and secrets, especially because the script targets a repository under the user's home directory and pushes to a configured remote.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: This code file contains natural-language strings and documentation that assume Chinese as the only interaction language. Under the policy, forcing a specific language without opt-in is a locale/language policy violation unless the restriction is clearly justified, which is not indicated here.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: The `list_accounts` command exposes all configured email account identifiers and associated metadata such as email addresses, provider, status, and notes from a credentials file. In a multi-user, agent, or shared execution context, this creates unnecessary account enumeration and leaks sensitive operational information beyond the core read/send mail functionality.

Static analysis

No suspicious patterns detected.