Openclaw Email Bypass

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:56 AM UTC
• Version: 0.1.2

Overview

The skill does what it says by sending email through a Google Apps Script relay, but it under-discloses the public relay exposure and third-party Google data path.

Review this before installing. Only use it if you control the Google Apps Script deployment, understand that email contents and metadata pass through Google services, use a strong rotatable token, avoid confidential or regulated content unless approved, and consider pinning dependencies and adding rate limits or access restrictions.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:5
• Finding: Unpinned Third-Party Dependency Installation## Vulnerability Details **File Location**: `SKILL.md:5` (also documented in `README.md:82`) **Vulnerability Type**: Unpinned dependency installation from a mutable package source **Risk Level**: Medium ### Vulnerable Code `SKILL.md:5`: ```yaml metadata: {"clawdbot":{"emoji":"✉️","requires":{"bins":["python3"]},"install":[{"id":"pip","kind":"exec","command":"pip3 install requests","label":"Install python requests"}]}} ``` The equivalent installation guidance appears in `README.md:82`: ```bash pip install requests ``` ### Technical Analysis The installation command does not pin `requests` to a reviewed version and does not verify package integrity with cryptographic hashes. Consequently, the installed artifact is determined by mutable package-index state and the user's pip configuration at installation time. Although the package name is legitimate and the project contains no evidence that it intentionally selects a malicious dependency, this installation pattern leaves the runtime supply chain insufficiently constrained. A compromised package release, package index, configured mirror, or pip configuration could cause installation of code that was not part of the audited project. Python packages may execute installation or build-related code and are subsequently imported by `scripts/send_email.py`. Malicious code delivered through this dependency could therefore execute in the Python process under the privileges of the user running the installation or email script. ### Attack Path 1. An attacker compromises a dependency release, the selected Python package index, or a mirror configured in the victim's pip environment. 2. The user or skill framework executes `pip3 install requests` as specified in `SKILL.md`. 3. Because no reviewed version or artifact hash is required, pip accepts the attacker-controlled package artifact selected by dependency resolution. 4. Attacker-controlled code executes during package instal ...[truncated 757 chars]
• Remediation: ## Remediation Suggestions 1. Pin `requests` and all transitive dependencies to reviewed versions using a lock file. 2. Record cryptographic hashes for every permitted distribution and install with hash verification, such as: ```bash python3 -m pip install --require-hashes -r requirements.txt ``` 3. Generate `requirements.txt` through a reproducible dependency-management workflow and commit it to the project. 4. Configure installation to use an explicitly trusted package index rather than inheriting an arbitrary local mirror. 5. Perform dependency vulnerability and provenance checks during releases. 6. Install dependencies inside a dedicated virtual environment under an unprivileged account. 7. Replace the inline `pip3 install requests` metadata command with installation from the reviewed, hash-locked dependency file.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Taint Tracking: Direct Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (8)

Tainted flow: 'url' from os.getenv (line 7, credential/environment) → requests.post (network output)

Critical

• Category: Data Flow

Content

}
    
    try:
        response = requests.post(url, json=payload)
        if response.text.strip() == "Success":
            print(f"Email sent successfully to {to}")
            return True

• Confidence: 90% confidence
• Finding: Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The skill is described as secure and self-hosted, but its documented behavior depends on sending email content and an authentication token to a Google Apps Script webhook URL. This mismatch is dangerous because it can mislead reviewers and users about the true trust boundary, causing sensitive data to be exfiltrated to an external service under the guise of a local or self-hosted workflow.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The manifest says mail is routed through a private Google Apps Script relay but gives no warning that message bodies, headers, recipients, and possibly credentials or tokens may traverse third-party infrastructure. This omission is dangerous because users may unknowingly send sensitive data through an external relay, creating confidentiality, compliance, and abuse risks, especially given the explicit purpose of bypassing normal mail restrictions.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The README encourages use of the relay for potentially sensitive communications such as alerts, reports, and job applications, but it does not clearly explain the privacy and data-handling implications of sending message contents through a Google Apps Script web endpoint tied to a personal Google account. Even though it is self-hosted, email bodies, recipients, and metadata are still transmitted to and processed by Google services, which can expose sensitive data if users misunderstand the trust boundary or deploy the web app too broadly.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 96% confidence
• Finding: The skill advertises code execution that uses environment variables and network access, but it does not declare any tool scope such as permissions or allowed-tools. That omission weakens transparency and policy enforcement, making it easier for the skill to access secrets and send outbound requests without an explicit capability declaration or user review.

Vague Triggers

Medium

• Confidence: 90% confidence
• Finding: The manifest explicitly markets an email-bypass capability using broad language ('Bypass SMTP port blocks') without clearly constraining legitimate use cases, authorization requirements, or abuse boundaries. In a skill intended to send email through alternative infrastructure, vague activation and positioning increase the risk of misuse for policy evasion, spam delivery, or exfiltration workflows.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The setup explicitly instructs deploying the Google Apps Script as a public web app with access set to 'Anyone', relying only on a shared bearer token for protection. This increases exposure to abuse, token leakage, unauthorized relay use, and privacy issues if requests or logs are mishandled, and the guide does not prominently warn users about these risks or recommend stronger access controls.

External Transmission

Medium

• Category: Data Exfiltration

Content

}
    
    try:
        response = requests.post(url, json=payload)
        if response.text.strip() == "Success":
            print(f"Email sent successfully to {to}")
            return True

• Confidence: 80% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.