Security audit

Gmail Label Manager

Security checks for vulnerabilities and agentic risk

Overview

This Gmail automation is under-documented and can forward sensitive email details to Telegram, write Google Calendar events, mutate Gmail labels, and expose a shell-injection risk from email-derived calendar fields.

Do not install this without review. At minimum, remove eval, disable or explicitly opt into Telegram forwarding, redact email content from notifications and logs, document and gate Calendar writes, and test Gmail mutations in a dry-run or limited account before using it on a real mailbox.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
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 (4)

other

Error

Location: script.sh:272
Finding: Undisclosed Transmission of Sensitive Email Content to Telegram<![CDATA[ ## Vulnerability Details **File Location**: `script.sh:272-300`, with email-content sources at `script.sh:710-731`, `script.sh:744-765`, and `script.sh:778-799` **Vulnerability Type**: Sensitive data disclosure to a third-party service **Risk Level**: High ### Vulnerable Code ```bash send_telegram() { local message="$1" local priority="${2:-normal}" # critical, high, normal, low if [ -z "$TELEGRAM_BOT_TOKEN" ] || [ -z "$TELEGRAM_CHAT_ID" ]; then log_warn "Telegram credentials not configured. Skipping notification." return 1 fi # Add priority emoji local emoji="" case "$priority" in critical) emoji="" ;; high) emoji="⚠️" ;; normal) emoji="ℹ️" ;; low) emoji="" ;; esac local formatted_message="${emoji} ${message}" local response response=$(curl -s -X POST \ "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \ -d "chat_id=${TELEGRAM_CHAT_ID}" \ --data-urlencode "text=${formatted_message}" \ --data-urlencode "parse_mode=HTML" 2>&1) local exit_code=$? echo "[$(date '+%Y-%m-%d %H:%M:%S')] ${response}" >> "$TELEGRAM_LOG" } ``` One of several handlers that supplies email content to this function is: ```bash handle_child_mention() { local email_content="$1" local subject="$2" local sender="$3" local child_name child_name=$(extract_child_name "$email_content $subject") log_info "Processing email mentioning child: ${child_name:-one of the children}" local sender_name sender_name=$(echo "$sender" | grep -oP '^[^<]+' | xargs) local preview preview=$(echo "$email_content" | head -c 300) local telegram_message=" Child Mentioned: ${child_name:-Children} From: ${sender_name} Subject: ${subject} Preview: ${preview}...  Check email - may require attention" send_telegram "$telegram_message" "high" } ``` ### Technical Analysis The script retrieves complete Gmail threads and passes email-derived information to numerous c ...[truncated 1994 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable Telegram transmission by default and require explicit, documented opt-in consent. 2. Update `SKILL.md` to disclose the destination, categories of transmitted data, and conditions under which transmission occurs. 3. Do not send message bodies, body previews, medical information, financial information, or account-security content. 4. Replace raw content with minimal notifications such as a locally generated message identifier and a generic category. 5. Validate ownership of the configured Telegram destination before enabling notifications. 6. Add configurable per-category controls so sensitive classifications cannot be transmitted. 7. Protect bot credentials through a dedicated secret manager and rotate existing credentials if their destination cannot be verified. 8. Provide an offline notification mode that does not disclose Gmail content to an external service. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: script.sh:333
Finding: Arbitrary Shell Command Injection Through Email-Derived Calendar Fields<![CDATA[ ## Vulnerability Details **File Location**: `script.sh:333-355`, with an email-controlled call site at `script.sh:850-883` **Vulnerability Type**: Shell command injection through unsafe use of `eval` **Risk Level**: Critical ### Vulnerable Code ```bash add_calendar_event() { local title="$1" local date="$2" local all_day="${3:-true}" local time="${4:-}" local description="${5:-}" log_info "Creating calendar event: $title on $date" local cmd="gog calendar event create --title \"$title\" --startDate \"$date\"" if [ "$all_day" = "true" ]; then cmd="$cmd --allDay true" elif [ -n "$time" ]; then cmd="$cmd --startTime \"$time\"" fi if [ -n "$description" ]; then cmd="$cmd --description \"$description\"" fi local result result=$(eval "$cmd" 2>&1) || log_warn "Failed to create calendar event: $result" return 0 } ``` An affected call site derives calendar parameters from untrusted email content: ```bash handle_permission_slip() { local email_content="$1" local subject="$2" log_info "Processing school permission slip" local child_name local event_name local event_date local deadline child_name=$(extract_child_name "$email_content") event_name=$(echo "$subject" | sed 's/permission.*slip//i' | xargs) event_date=$(extract_date "$email_content") deadline=$(echo "$email_content" | grep -oiP "deadline[: ]*\K.*" | head -n 1 | xargs) # Other notification and digest operations occur here. if [ -n "$deadline" ]; then add_calendar_event "school Permission Slip Due: ${event_name}" "$deadline" true "" "Child: ${child_name}. Event: ${event_date}" fi return 0 } ``` ### Technical Analysis `add_calendar_event` builds a shell command as a string and then executes that string with `eval`. Several arguments—including the title, date, time, and description—can originate from an email subject or body. Embedding a value inside textual double quotes does not make it safe when the completed s ...[truncated 1881 chars]
Remediation: <![CDATA[ ## Remediation Suggestions Remove `eval` entirely. Construct the command as a Bash array so each value remains one literal argument: ```bash add_calendar_event() { local title="$1" local date="$2" local all_day="${3:-true}" local time="${4:-}" local description="${5:-}" local -a cmd=( gog calendar event create --title "$title" --startDate "$date" ) if [[ "$all_day" == "true" ]]; then cmd+=(--allDay true) elif [[ -n "$time" ]]; then cmd+=(--startTime "$time") fi if [[ -n "$description" ]]; then cmd+=(--description "$description") fi "${cmd[@]}" } ``` Additional hardening should include: 1. Validate dates against a strict supported date format and reject all other input. 2. Validate times against a strict time format. 3. Apply maximum lengths and permitted-character policies to event titles and descriptions. 4. Require user confirmation before creating events from externally supplied email. 5. Restrict event-generating handlers to authenticated, allowlisted senders. 6. Run the automation under a dedicated, minimally privileged account. 7. Rotate or review credentials accessible to the process if the vulnerable script has processed untrusted mail. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: script.sh:333
Finding: Undisclosed Automatic Calendar Modification Triggered by Untrusted Email<![CDATA[ ## Vulnerability Details **File Location**: `script.sh:333-355`, with representative call sites at `script.sh:883`, `script.sh:930`, `script.sh:1020`, `script.sh:1300`, and `script.sh:1522` **Vulnerability Type**: Undisclosed use of Google Calendar write privileges **Risk Level**: Medium ### Vulnerable Code ```bash add_calendar_event() { local title="$1" local date="$2" local all_day="${3:-true}" local time="${4:-}" local description="${5:-}" log_info "Creating calendar event: $title on $date" local cmd="gog calendar event create --title \"$title\" --startDate \"$date\"" if [ "$all_day" = "true" ]; then cmd="$cmd --allDay true" elif [ -n "$time" ]; then cmd="$cmd --startTime \"$time\"" fi if [ -n "$description" ]; then cmd="$cmd --description \"$description\"" fi local result result=$(eval "$cmd" 2>&1) || log_warn "Failed to create calendar event: $result" return 0 } ``` Representative automatic event creation includes: ```bash if [ -n "$deadline" ]; then add_calendar_event "school Permission Slip Due: ${event_name}" "$deadline" true "" "Child: ${child_name}. Event: ${event_date}" fi ``` ```bash add_calendar_event "Absence: ${absence_child}" "$absence_date" true "" "Reason: ${reason:-Not specified}. Submit excusal note." ``` ### Technical Analysis The documented skill purpose is Gmail label organization and archiving. However, the implementation also invokes the authenticated Google CLI to create calendar events. Neither the calendar-write behavior nor the need for Calendar API authorization is disclosed in `SKILL.md`. Event creation is driven by pattern matching and data extraction from incoming email. Pattern matching alone does not establish that the sender is trusted or that the extracted date and event details are correct. Consequently, an external sender can influence calendar state merely by sending a message that matches one of the supported categories. This behavior exceeds the least- ...[truncated 1436 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove calendar functionality from the Gmail label-management skill, or separate it into an independently installed and authorized feature. 2. Clearly document all Calendar API access and mutations before requesting authorization. 3. Request only the minimum Google OAuth scopes required for the enabled feature set. 4. Require explicit user confirmation before creating each event. 5. Restrict automatic event extraction to cryptographically authenticated or strictly allowlisted senders. 6. Validate event dates, times, titles, and descriptions before use. 7. Add deduplication and rate limiting to prevent calendar spam. 8. Provide a dry-run mode that displays the proposed event without modifying Calendar. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: script.sh:14
Finding: Plaintext Retention of Email Metadata and Sensitive Extracted Information<![CDATA[ ## Vulnerability Details **File Location**: `script.sh:14-19`, `script.sh:300`, `script.sh:314-326`, and `script.sh:2359-2362` **Vulnerability Type**: Insecure plaintext storage of sensitive information **Risk Level**: Medium ### Vulnerable Code ```bash readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" readonly LOG_DIR="${SCRIPT_DIR}/logs" readonly LOG_FILE="${LOG_DIR}/gmail-label-log.txt" readonly TELEGRAM_LOG="${LOG_DIR}/telegram-log.txt" readonly DIGEST_FILE="${SCRIPT_DIR}/weekly-digest.txt" readonly CONFIG_FILE="${SCRIPT_DIR}/config.json" ``` Telegram API responses are retained in plaintext: ```bash echo "[$(date '+%Y-%m-%d %H:%M:%S')] ${response}" >> "$TELEGRAM_LOG" ``` Digest entries are also written directly to disk: ```bash add_to_digest() { local category="$1" local entry="$2" local priority="${3:-normal}" { echo "" echo "[$(date '+%Y-%m-%d %H:%M:%S')] [${priority^^}]" echo "Category: $category" echo "$entry" echo "---" } >> "$DIGEST_FILE" } ``` Email metadata is included in the general log: ```bash log_info "==========================================" log_info "Processing: $subject" log_info "From: $sender" log_info "Thread ID: $thread_id" log_info "==========================================" ``` ### Technical Analysis The script writes Gmail subjects, senders, thread identifiers, handler-generated digest entries, and Telegram API responses into files under the skill directory. Handler-generated digest entries can contain family, school, financial, medical, travel, and account-related information. The script creates the log directory with `mkdir -p` but does not establish a restrictive `umask`, explicitly assign file mode `0600`, encrypt stored data, redact sensitive fields, or implement retention limits. File permissions therefore depend on the invoking environment's default `umask`. The project documentation does not disclose that email-derived information will be retained locall ...[truncated 1118 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Avoid writing email bodies, extracted personal details, subjects, senders, and thread identifiers unless strictly necessary. 2. Set restrictive permissions before creating any files: ```bash umask 077 mkdir -p -- "$LOG_DIR" touch -- "$LOG_FILE" "$TELEGRAM_LOG" "$DIGEST_FILE" chmod 600 -- "$LOG_FILE" "$TELEGRAM_LOG" "$DIGEST_FILE" ``` 3. Store logs outside shared project or workspace directories. 4. Redact identifiers and sensitive values before logging. 5. Do not retain complete Telegram API responses unless required for troubleshooting. 6. Introduce automatic log rotation, strict retention limits, and secure cleanup. 7. Encrypt retained sensitive records using keys held outside the project directory. 8. Document all local storage, its purpose, retention duration, and deletion procedure. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
YARA SignaturesMalware Match, Webshell Match, Cryptominer Match
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection

Findings (11)

Ssd 3

High

Confidence: 92% confidence
Finding: Multiple handlers extract and relay private email content in plain language to an external Telegram chat, including previews, children's names, school matters, medical details, travel documents, financial transactions, and account-related information. This is a natural-language data leakage pattern because the script is designed to collect user-provided email contents and include them in outbound messages and logs, even though it does not use explicit exfiltration wording.

Context-Inappropriate Capability

High

Confidence: 97% confidence
Finding: The script sends email-derived content, including previews and sensitive categories such as medical, financial, family, and security alerts, to Telegram via an external API. This is dangerous because it transfers potentially confidential Gmail data to a third-party service without minimization, explicit consent flow, or clear access controls, increasing privacy and data-exposure risk.

Missing User Warnings

High

Confidence: 96% confidence
Finding: Sensitive email content is forwarded to Telegram automatically with no interactive warning, approval step, or visible consent checkpoint. Because the script handles highly personal categories, this silent sharing can expose confidential family, financial, and medical information outside Gmail's trust boundary.

Context-Inappropriate Capability

High

Confidence: 93% confidence
Finding: The script creates Google Calendar events directly from parsed email content, which exceeds passive classification and can cause unintended state changes from untrusted input. Malicious or malformed emails could create misleading events, spam the calendar, or manipulate scheduling based on forged content.

YARA rule 'agent_skill_mcp_tool_poisoning_metadata': MCP/tool metadata poisoning indicators in tool schemas or skill manifests [agent_skills]

High

Category: YARA Match
Content: rity^^}]" echo "Category: $category" echo "$entry" echo "---" } >> "$DIGEST_FILE" } #============================================================================== # CALENDAR FUNCTIONS #============================================================================== add_calendar_event() { local title="$1" local date="$2" local all_day="${3:-true}" local time="${4:-}" local description="${5:-}" log_info "Creating calendar event: $title on $date" local cmd="gog calendar event create --title \"$title\" --startDate \"$date\"" if [ "$all_day" = "true" ]; then cmd="$cmd --allDay true" elif [ -n "$time" ]; then cmd="$cmd --startTime \"$time\"" fi if [ -n "$description" ]; then cmd="$cmd --description \"$description\"" fi local result result=$(eval "$cmd" 2>&1) || log_warn "Failed to create calendar event: $result" return 0 } #============================================================================== # EMAIL PROCESSING UTILITIE
Confidence: 80% confidence
Finding: YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).

Missing User Warnings

High

Confidence: 98% confidence
Finding: The script automatically modifies Gmail threads by applying/removing labels and archiving messages without an explicit warning or confirmation step. Automatic mailbox mutation on untrusted email input can hide important emails, interfere with workflows, and make phishing or other messages less visible to the user.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The skill describes automatically labeling, removing labels, and archiving unread Gmail messages, but it does not prominently warn users that it will modify mailbox state and can move messages out of the inbox without manual review. This creates a real risk of unintended email handling, missed important messages, and user confusion, especially because the behavior is automated and based on inferred patterns from prior archived emails.

Intent-Code Divergence

Medium

Confidence: 88% confidence
Finding: The header describes classification and processing, but the script also modifies labels and archives Gmail threads, which are materially different and more intrusive actions. This mismatch can mislead users about the script's real capabilities and reduce informed consent for mailbox-altering behavior.

External Transmission

Medium

Category: Data Exfiltration
Content: local formatted_message="${emoji} ${message}" local response response=$(curl -s -X POST \ "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \ -d "chat_id=${TELEGRAM_CHAT_ID}" \ --data-urlencode "text=${formatted_message}" \
Confidence: 95% confidence
Finding: This curl call transmits notification content to the Telegram Bot API, crossing a trust boundary to a third-party service. In this script, the transmitted content is often derived from email bodies and may include sensitive personal, medical, financial, and security information.

External Transmission

Medium

Category: Data Exfiltration
Content: local response response=$(curl -s -X POST \ "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \ -d "chat_id=${TELEGRAM_CHAT_ID}" \ --data-urlencode "text=${formatted_message}" \ --data-urlencode "parse_mode=HTML" 2>&1)
Confidence: 94% confidence
Finding: The hardcoded Telegram API endpoint confirms external transmission of collected email-derived data to a non-Gmail service. Given the script's broad handling of personal categories, this transmission materially increases confidentiality and compliance risks.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The script performs automatic calendar creation from email-derived content without warning or confirmation, allowing untrusted email text to trigger account-side actions. This can be abused to clutter calendars, create deceptive reminders, or influence user behavior through crafted messages.

Static analysis

No suspicious patterns detected.