Email Checker by EntzAI

• Outcome: Review
• Latest audit: Sep 12, 2026 · 8:07 AM UTC
• Version: 1.1.1

Overview

The skill does what it claims, but it needs Review because it reads and changes mailbox state on a schedule and has unsafe AppleScript and LLM handling that could expose email or cause unintended actions.

Install only if you are comfortable with a scheduled tool reading your Apple Mail inbox, sending email content to your chosen LLM/report destination, and changing unread status. Prefer a dedicated bot mailbox, local-only LLM mode, no Full Disk Access, no auto cron until reviewed, and manual review of every generated reply before sending.

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

T09 · Insecure Skill Coding Practices

Error

• Location: setup.sh:141
• Finding: Sensitive email content and API credentials may be transmitted to arbitrary or insecure LLM endpoints<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:141-144`, `setup.sh:183-203`, `scripts/email/checker.py:289-317`, `scripts/email/checker.py:361-404` **Vulnerability Type**: Unrestricted sensitive-data transmission over configurable network endpoints **Risk Level**: High ### Vulnerable Code ```bash read -r -p " Base URL [http://localhost:1234/v1]: " LLM_BASE_URL LLM_BASE_URL="${LLM_BASE_URL:-http://localhost:1234/v1}" read -r -p " API key [local]: " LLM_API_KEY LLM_API_KEY="${LLM_API_KEY:-local}" ``` ```python url = f"{LLM_BASE_URL}/chat/completions" payload = json.dumps({ "model": model, "messages": [{"role": "user", "content": prompt}], "max_tokens": LLM_MAX_TOKENS, "stream": False }).encode("utf-8") req = urllib.request.Request( url, data=payload, headers={ "Content-Type": "application/json", "Authorization": f"Bearer {LLM_API_KEY}", "User-Agent": "OpenClawBot/1.0" }, method="POST" ) with urllib.request.urlopen(req, timeout=timeout) as resp: data = json.loads(resp.read().decode("utf-8")) ``` ### Technical Analysis The installer accepts an unrestricted LLM base URL, including non-loopback plaintext HTTP endpoints. The checker later sends an authorization bearer token and a prompt containing email sender information, subjects, message bodies, and potentially up to ten matching thread messages to that endpoint. There is no enforcement that remote endpoints use HTTPS, no provider allowlist, no certificate pinning, and no explicit warning describing which mailbox data will leave the system. Redirect behavior is also not constrained by the application. Using HTTP for a remote endpoint exposes both email content and the bearer credential to interception or modification. Even over HTTPS, a user or Agent can configure an untrusted server that directly receives the disclosed data. ### Attack Path 1. An attacker persuades the user or an integrated Agent to configu ...[truncated 1017 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require HTTPS whenever the host is not a loopback address. - Reject URL user information, unexpected schemes, and unsafe redirects. - Maintain an explicit allowlist of supported providers or require prominent confirmation for custom endpoints. - Explain during setup that email bodies and thread history will be disclosed to the selected provider. - Add configurable redaction for credentials, financial information, authentication links, and other sensitive content. - Send only the minimum message content necessary for drafting. - Do not send a bearer credential to local providers that do not require authentication. - Consider provider-specific clients and outbound network restrictions. ]]>

other

Error

• Location: scripts/email/checker.py:369
• Finding: Indirect prompt injection through untrusted email content<![CDATA[ ## Vulnerability Details **File Location**: `scripts/email/checker.py:369-404` **Vulnerability Type**: Indirect prompt injection **Risk Level**: High ### Vulnerable Code ```python prompt = f"""You are {BOT_NAME}, an AI email assistant for {USER_NAME}. Your job is to draft a reply on {USER_NAME}'s behalf to the email below. About {USER_NAME}: - Values concise, friendly, and professional communication - Signs off as "{USER_NAME}" in personal emails, or "{BOT_NAME} 🤖" when acting autonomously {thread_context} ───────────────────────────────────────── Current email to reply to: From: {sender} ({sender_name}) Subject: {subject} Content: {content} ───────────────────────────────────────── Instructions: - Read the thread history carefully and reply to THIS specific email in context. - If the thread has prior messages, acknowledge or build on what was already discussed. - If there is no thread history, respond appropriately for a first contact. - Keep the reply concise (2–5 sentences is usually enough unless more detail is warranted). - Match the tone of the incoming email: casual if they are casual, formal if they are formal. - DO NOT use filler phrases like "I hope this email finds you well" or "Thanks for reaching out". - DO NOT start with "I" as the very first word of the reply. - End with a natural sign-off followed by "{BOT_NAME} 🤖" on its own line. - Output ONLY the email body text. No explanations, no metadata, no subject line. Draft reply:""" log(f"Calling LLM ({LLM_MODEL}) for draft reply to: {subject}") draft = call_llm(prompt) ``` ### Technical Analysis The email body and thread history are attacker-controlled content. They are concatenated into the same LLM user message as the application's trusted drafting instructions. No trust-boundary separation, injection detection, content classification, or output-policy enforcement is applied. An email sender can insert instructions such as “ignore the preceding instructions,” request deceptiv ...[truncated 1394 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Place behavioral rules in a dedicated system message rather than combining them with email content. - Clearly identify email bodies and thread messages as untrusted data that must never be treated as instructions. - Use structured message fields or validated JSON rather than a single interpolated prompt. - Detect instruction-like content and warn the user when prompt injection is suspected. - Constrain and validate generated output before displaying or sending it. - Require explicit human review and confirmation for every AI-generated reply. - Never let a generated draft directly trigger tools, commands, configuration changes, or further Agent actions. - Display the source email beside the draft so users can identify manipulation. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/email/send_reply.py:42
• Finding: AppleScript injection through interpolated recipient and subject values<![CDATA[ ## Vulnerability Details **File Location**: `scripts/email/send_reply.py:42-48` **Vulnerability Type**: AppleScript code injection with potential shell-command execution **Risk Level**: High ### Vulnerable Code ```python TEMP_FILE.parent.mkdir(parents=True, exist_ok=True) TEMP_FILE.write_text(content, encoding="utf-8") applescript = f'''tell application "Mail" set replyContent to do shell script "cat {TEMP_FILE}" set newMessage to make new outgoing message with properties {{subject:"{subject}", content:replyContent}} tell newMessage make new to recipient at end of to recipients with properties {{address:"{to_address}"}} end tell send newMessage return "Sent" end tell''' ``` Related unsafe interpolation is also present in `scripts/email/checker.py:217-231`, `scripts/email/checker.py:434-439`, and `scripts/email/checker.py:584-590`. ### Technical Analysis `subject` and `to_address` are accepted as command-line input and directly interpolated into executable AppleScript source. Quotes, backslashes, line breaks, and AppleScript syntax are not escaped or passed as data arguments. Although the message body is written to a temporary file to avoid direct body injection, the recipient and subject remain exploitable. A crafted value can terminate its quoted AppleScript string and append additional AppleScript statements. AppleScript supports `do shell script`, so successful injection may transition from script manipulation to arbitrary local command execution. The checker similarly embeds configuration-derived account IDs, report recipients, and paths into generated AppleScript. ### Attack Path 1. An attacker influences an OpenClaw command or other invocation of `send_reply.py`. 2. The attacker supplies a subject or recipient containing a quote followed by AppleScript statements. 3. Python inserts the value into the AppleScript program without encoding. 4. `osascript -e` parses the injected statements as executable code. ...[truncated 655 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Never interpolate untrusted values into AppleScript source. - Pass recipient, subject, account ID, and file paths as `osascript` arguments. - Read values from AppleScript's `argv` parameter in an `on run argv` handler. - Validate recipient addresses using a strict email-address parser. - Reject control characters in subject and address values. - Avoid `do shell script "cat ..."`; read the file through a safely passed POSIX path or pass content as an argument when size permits. - Apply the same correction to every generated AppleScript block in `checker.py`. - Add regression tests containing quotes, backslashes, line breaks, and AppleScript metacharacters. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: setup.sh:308
• Finding: LLM API key stored in plaintext without enforced restrictive permissions<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:308-319` **Vulnerability Type**: Insecure credential storage **Risk Level**: Medium ### Vulnerable Code ```python "llm": { "provider": os.environ['LLM_PROVIDER'], "base_url": os.environ['LLM_BASE_URL'], "api_key": os.environ['LLM_API_KEY'], "model": os.environ['LLM_MODEL'], "max_tokens": 800, "timeout": 45 } config_path = os.environ.get('CONFIG_FILE', '') with open(config_path, 'w') as f: json.dump(config, f, indent=2) ``` ### Technical Analysis The setup process writes the LLM API key directly into `config/settings.json`. File creation relies entirely on the user's current umask; the installer does not explicitly create the file with mode `0600` or correct an existing file's permissions. The README states that the configuration is gitignored, but no `.gitignore` file was present in the audited package. This increases the risk that the secret-bearing configuration will be accidentally committed or copied. The API key is also temporarily placed in a child process environment during setup. While this is narrower than command-line exposure, storing the long-lived secret in plaintext JSON remains the primary concern. ### Attack Path 1. The user enters an OpenAI or remote LLM API key during setup. 2. Setup writes the key into `config/settings.json`. 3. The file inherits permissions determined by the current umask. 4. Another local account, process, backup operation, or repository commit obtains the file. 5. The exposed key is used to consume API resources or access provider capabilities associated with the credential. ### Impact Assessment The likely impact includes: - Unauthorized use of the LLM account and associated financial charges. - Exposure of provider account metadata available to the key. - Reuse of the credential against other applications if the same key was shared. - Disclosure of personal configuration, report address, trusted senders, ...[truncated 107 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Store API credentials in macOS Keychain and keep only a keychain reference in the JSON file. - If file storage is unavoidable, create the file atomically with mode `0600`. - Run `chmod 600 config/settings.json` after writing and verify the resulting mode. - Refuse to continue when the configuration is group- or world-readable. - Add a `.gitignore` rule for `config/settings.json`, logs, and temporary data. - Add pre-commit secret detection and documentation warning users not to commit the file. - Encourage narrowly scoped, application-specific provider keys and key rotation. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: setup.sh:376
• Finding: Full Disk Access guidance exceeds the minimum privileges required<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:376-377` **Vulnerability Type**: Excessive permission recommendation **Risk Level**: Medium ### Vulnerable Code ```bash echo " If cron runs fail, also add:" echo " → Full Disk Access → Terminal (or cron)" ``` The same recommendation appears in `README.md:89` and `README.md:230`. ### Technical Analysis The declared functionality requires controlling Mail.app through Automation permissions and accessing files inside the project directory. Full Disk Access is substantially broader: it may allow Terminal, cron, or the relevant executable to access protected user data unrelated to the email checker. The recommendation does not identify the specific denial being resolved, provide a narrower alternative, or warn that every script launched through the granted executable may inherit broader access. This violates least-privilege principles. The risk is compounded by the AppleScript injection vulnerability because injected commands would execute within the same highly privileged context. ### Attack Path 1. Cron operation fails because of a permission or environment issue. 2. Following the setup guidance, the user grants Full Disk Access to Terminal or cron. 3. An attacker exploits AppleScript injection, modifies a writable scheduled script, or compromises another process executing through that context. 4. The malicious code reads protected data unrelated to the Skill's stated function. ### Impact Assessment Depending on macOS controls and the executable receiving permission, compromise may expose: - Protected documents and desktop data. - Browser, messaging, backup, and application data. - Mail-related databases beyond the selected account. - Other sensitive files normally restricted by Transparency, Consent, and Control protections. This recommendation does not provide root privileges, but it substantially expands the accessible data set for any code executing in the approved context. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the blanket Full Disk Access recommendation. - Diagnose and document the exact files or services required by cron. - Use a dedicated least-privileged macOS account for the checker. - Grant only Mail Automation permission where possible. - Use a `launchd` user agent with a controlled environment instead of broadly authorizing Terminal. - Keep code, configuration, logs, and temporary data in a dedicated directory with restrictive permissions. - If Full Disk Access is genuinely unavoidable, provide a clear warning, identify the exact binary, and describe how to revoke the permission. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/email/checker.py:217
• Finding: Broad subject matching may disclose unrelated email threads to the LLM<![CDATA[ ## Vulnerability Details **File Location**: `scripts/email/checker.py:217-231` **Vulnerability Type**: Excessive mailbox data collection and cross-thread disclosure **Risk Level**: Medium ### Vulnerable Code ```python applescript = f''' tell application "Mail" set targetSubject to "{safe_subject}" set inboxAccount to account id "{MAIL_ACCOUNT_ID}" set inboxFolder to mailbox "INBOX" of inboxAccount set allMessages to every message of inboxFolder set matchedMessages to {{}} repeat with msg in allMessages set msgSubject to subject of msg if msgSubject contains targetSubject then set msgContent to text 1 thru (min of 2000 and (count characters of (content of msg))) of (content of msg) set msgEntry to (sender of msg) & "|||" & msgSubject & "|||" & msgContent set end of matchedMessages to msgEntry end if end repeat ``` ### Technical Analysis Thread history is identified by checking whether every inbox message's subject contains a normalized target subject. The supplied `sender` parameter is not used in the match, and no message ID, conversation ID, participant check, or exact normalized subject comparison is performed. For a common or deliberately chosen subject such as “Meeting,” “Invoice,” or “Review,” unrelated messages may be treated as part of the same conversation. Up to 2,000 characters from each selected message can then be added to the LLM prompt. This behavior collects more mailbox data than is required to draft a reply to one message. ### Attack Path 1. An attacker sends a message with a common subject and urgency keywords. 2. The checker classifies it as high priority and requests thread history. 3. The AppleScript scans every inbox message for subjects containing the common text. 4. Unrelated messages are included as prior thread history. 5. Their contents are sent to the configured LLM and may influence the generated report. ### Impact Assessment ...[truncated 343 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Use Mail.app's stable conversation, thread, or message identifiers when available. - Require exact normalized subject equality rather than substring matching. - Verify expected participants, account, mailbox, and relevant time boundaries. - Exclude the current message explicitly and limit history to known related messages. - Minimize content length and request user consent before sending historical messages to a remote provider. - Display which messages will be included in the prompt during testing or diagnostic operation. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/email/checker.py:638
• Finding: All unread messages are marked read even when report delivery fails<![CDATA[ ## Vulnerability Details **File Location**: `scripts/email/checker.py:638-639` **Vulnerability Type**: Unsafe failure handling and destructive mailbox state change **Risk Level**: Medium ### Vulnerable Code ```python send_email_report(report) mark_emails_as_read() ``` The marking function operates broadly at `scripts/email/checker.py:427-444`: ```python set unreadMessages to every message of inboxFolder whose read status is false if (count of unreadMessages) > 0 then repeat with msg in unreadMessages set read status of msg to true end repeat ``` ### Technical Analysis `send_email_report()` returns a Boolean indicating delivery success, but `main()` ignores that result. It calls `mark_emails_as_read()` regardless of whether Mail.app rejected the outgoing message, the AppleScript timed out, or another error occurred. The marking operation does not target only messages included in the report. It queries and modifies every message that is unread at execution time, including messages that may have arrived after collection began. This creates a non-transactional processing flow in which the visible mailbox state is changed even though the reporting objective was not achieved. ### Attack Path 1. The checker reads unread messages and generates a report. 2. Report sending fails because of connectivity, Mail.app state, invalid recipient configuration, or an induced timeout. 3. The failed function returns `False`. 4. The caller ignores the failure and marks every currently unread inbox message as read. 5. The user receives no report and may no longer notice the affected messages as unread. ### Impact Assessment The vulnerability can cause: - Loss of unread-status notifications for important messages. - Silent interruption of the expected reporting workflow. - Accidental modification of messages not included in the generated report. - Operational and availability impact, including missed urgent communication. It does not delete email ...[truncated 130 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Check the return value of `send_email_report()` and do not mark messages as read when delivery fails. - Record stable message IDs during collection. - Mark only the successfully reported message IDs as read. - Recheck message state before modifying it to avoid affecting newly arrived mail. - Implement retry behavior with bounded backoff for report delivery. - Log and surface failures without changing mailbox state. - Consider moving processed messages to a dedicated folder or applying a custom flag rather than changing unread status. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Behavioral AST: exec() Call, eval() Call, Dynamic Import

Findings (32)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The skill claims chat-based management via Telegram or WhatsApp, but the visible setup instead emphasizes cron installation and Apple Mail automation, with no declared trigger/permission model for those powerful behaviors. Hidden persistence via scheduled execution and OS-level Mail control materially increases risk because the skill can repeatedly process mailbox contents or act on the user's behalf after initial installation.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The skill claims chat-based management via Telegram or WhatsApp, but the visible setup instead emphasizes cron installation and Apple Mail automation, with no declared trigger/permission model for those powerful behaviors. Hidden persistence via scheduled execution and OS-level Mail control materially increases risk because the skill can repeatedly process mailbox contents or act on the user's behalf after initial installation.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The skill claims chat-based management via Telegram or WhatsApp, but the visible setup instead emphasizes cron installation and Apple Mail automation, with no declared trigger/permission model for those powerful behaviors. Hidden persistence via scheduled execution and OS-level Mail control materially increases risk because the skill can repeatedly process mailbox contents or act on the user's behalf after initial installation.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The skill claims chat-based management via Telegram or WhatsApp, but the visible setup instead emphasizes cron installation and Apple Mail automation, with no declared trigger/permission model for those powerful behaviors. Hidden persistence via scheduled execution and OS-level Mail control materially increases risk because the skill can repeatedly process mailbox contents or act on the user's behalf after initial installation.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 91% confidence
• Finding: The skill claims chat-based management via Telegram or WhatsApp, but the visible setup instead emphasizes cron installation and Apple Mail automation, with no declared trigger/permission model for those powerful behaviors. Hidden persistence via scheduled execution and OS-level Mail control materially increases risk because the skill can repeatedly process mailbox contents or act on the user's behalf after initial installation.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The code sends email bodies and thread history to the configured LLM service to generate replies, with no explicit consent, warning, redaction, or data-minimization controls visible here. In inbox-processing context, this can expose sensitive personal, legal, financial, or corporate communications to third-party or local model services and may violate privacy expectations or policy.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The skill silently marks all unread inbox emails as read after sending the report, which is a materially impactful side effect not implied by a simple checker/reporting workflow. This can cause users to miss messages, interfere with triage rules, and destroy the unread-state signal relied on for security or business operations.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The README explicitly states the tool fetches unread emails, sends a report, and marks messages as read, but it does not clearly warn users that private email content may be processed, summarized, transmitted, and that mailbox state will be modified automatically. In this context, the lack of informed-consent messaging increases the risk of accidental exposure of sensitive communications and unintended inbox changes, especially when paired with optional remote LLM use.

Session Persistence

Medium

• Category: Rogue Agent

Content

### Cron Schedule

Default: every hour. Change by editing crontab (`crontab -e`):

```
# Every hour (default)

• Confidence: 85% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The README documents a workflow where remote Telegram/WhatsApp instructions can trigger outbound email replies, but it does not prominently warn about the risk of mis-triggered, spoofed, or over-broad commands causing unintended email transmission. Because email sending is an externally visible action with reputational and data-loss consequences, documenting remote-control behavior without strong safety caveats is security-significant.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 90% confidence
• Finding: The skill advertises capabilities that imply filesystem, shell, network, environment, and Mail automation access, but it does not declare an explicit tool scope or permissions model. That makes the skill harder to review safely and can enable overbroad execution in an agent environment, especially because it interacts with local mail data and external LLM providers.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The description omits a clear privacy warning that the skill reads mailbox contents, drafts replies, and may send that data to external LLM providers or messaging platforms. For an email-processing skill, this omission is dangerous because users may expose sensitive personal or corporate data without informed consent.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The installation and setup section does not clearly warn that setup auto-discovers Mail accounts, writes persistent configuration, and installs a crontab for recurring execution. These side effects affect privacy and system persistence, so failing to disclose them reduces informed consent and may surprise users with ongoing background processing.

Vague Triggers

Medium

• Confidence: 88% confidence
• Finding: The description advertises broad autonomous behavior like scoring priority, drafting replies, and sending reports on a schedule without stating clear trigger boundaries, approval gates, or scope limits. In an email-handling skill, vague invocation language can lead to over-broad execution, unintended processing of sensitive messages, or actions occurring without sufficiently explicit user expectation.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

"""Get unread emails from Inbox using AppleScript (includes content)."""
    script_path = SCRIPT_DIR / "get_unread_emails.scpt"

    result = subprocess.run(
        ['osascript', str(script_path), MAIL_ACCOUNT_ID],
        capture_output=True, text=True
    )

• Confidence: 70% confidence
• Finding: subprocess module calls execute external commands. Without careful input validation, this enables command injection.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

'''

    try:
        result = subprocess.run(
            ['osascript', '-e', applescript],
            capture_output=True, text=True,
            timeout=30

• Confidence: 92% confidence
• Finding: This code builds AppleScript source by interpolating email-derived subject text and `MAIL_ACCOUNT_ID` directly into an `osascript -e` command. Although quotes in the subject are escaped, AppleScript source injection is still a concern because untrusted content is embedded into executable script text, and malformed inputs can alter script behavior or cause unintended Mail automation.

Unbounded Resource Access

Medium

• Category: Excessive Agency

Content

# ─────────────────────────────────────────────────────────────────────────────
# call_llm  (was call_lm_studio in v2, call_ollama in v1)
# ─────────────────────────────────────────────────────────────────────────────
def call_llm(prompt, model=None, timeout=None):
    """
    Send a prompt to the configured LLM and return generated text.

• Confidence: 75% confidence
• Finding: Skill allows unbounded resource consumption (API calls, storage, compute). Without rate limits or quotas, a compromised or misbehaving agent can cause denial-of-service or cost overruns.

Ssd 3

Medium

• Confidence: 94% confidence
• Finding: The skill embeds prior thread content and current email bodies into LLM prompts and also includes message previews/drafts in emailed reports, creating broad plaintext exposure of potentially sensitive data. Because email commonly contains secrets, personal data, and business context, this context makes the exposure significantly more dangerous than in a generic summarization tool.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

end tell'''

    try:
        result = subprocess.run(
            ['osascript', '-e', script],
            capture_output=True, text=True,
            timeout=30

• Confidence: 87% confidence
• Finding: This AppleScript is dynamically assembled with `MAIL_ACCOUNT_ID` embedded in the script body and then executed. If configuration can be modified by an attacker or another local process, this creates an injection path into AppleScript-driven Mail actions.

Description-Behavior Mismatch

Medium

• Confidence: 86% confidence
• Finding: The manifest promises management from Telegram or WhatsApp and says the skill drafts AI replies, implying some workflow for user interaction around those drafts. In this implementation, the observable output path is an email report sent via Apple Mail, with no Telegram or WhatsApp handling present in the code shown.

Context-Inappropriate Capability

Medium

• Confidence: 98% confidence
• Finding: Executing `do shell script "cat {report_file}"` inside AppleScript is unnecessary for the stated purpose and introduces shell-command injection risk through a path value embedded in executable script text. Because the path originates from runtime/environment-controlled filesystem locations, this expands the attack surface beyond simple email reporting.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

end tell'''

    try:
        result = subprocess.run(
            ['osascript', '-e', applescript],
            capture_output=True, text=True,
            timeout=30

• Confidence: 97% confidence
• Finding: The report-sending AppleScript interpolates `subject`, `REPORT_RECIPIENT`, and especially `report_file` into executable AppleScript that runs `do shell script "cat ..."`. This creates command/script injection risk if config or file paths contain unsafe characters, and it combines Mail automation with shell execution.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: Automatically changing unread messages to read without confirmation is a risky hidden action in an email assistant. In this context, unread state is operationally meaningful, so silently altering it can conceal important or suspicious messages and reduce user awareness.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The reply body is written to a predictable workspace file on disk before sending, which creates local data persistence for potentially sensitive email content. On a multi-user system, shared workspace, backup target, or compromised host, drafts may be recoverable after sending and could expose confidential information.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

end tell'''

    try:
        result = subprocess.run(
            ['osascript', '-e', applescript],
            capture_output=True, text=True,
            timeout=30

• Confidence: 91% confidence
• Finding: The script builds AppleScript by directly interpolating untrusted --subject and --to values into quoted AppleScript string literals, then executes it via osascript. An attacker who can influence those fields can break out of the string and inject arbitrary AppleScript commands, which may lead to unauthorized email actions or local command execution through AppleScript features such as do shell script.

Static analysis

No suspicious patterns detected.