GHSA-4CM8-XPFV-JV6F: Email Sender Spoofing and Authentication Bypass in ZeptoClaw

ZeptoClaw is a personal AI assistant written in Rust that processes inbound emails to execute specific automated tasks and agent instructions. The system utilizes an allowlist mechanism to restrict task execution to authorized users. This allowlist historically relied entirely on the parsed MIME From header to identify the sender.

The core vulnerability exists in how ZeptoClaw validates these inbound email identities. Prior to version 0.7.6, the application implicitly trusted the MIME From header without enforcing cryptographic verification of the sender's domain. This design flaw aligns with CWE-345 (Insufficient Verification of Data Authenticity) and CWE-306 (Missing Authentication for Critical Function).

Because the application decoupled the identity check from the underlying transport security mechanisms, an attacker could trivially spoof the sender address. Any email presenting an authorized address in the From header would be processed as a legitimate instruction. This allowed unauthorized entities to interact with the AI agent and execute commands on behalf of an allowlisted user.

The vulnerability stems from the fundamental architectural difference between the SMTP transport envelope and the MIME message payload. In the SMTP protocol, the MAIL FROM command defines the envelope sender, which is used by mail transfer agents (MTAs) for routing and bounce processing. The MIME From: header, contained within the message data (DATA), is strictly for display purposes in the recipient's mail client.

ZeptoClaw's inbound email processor extracted the identity directly from the MIME From: header. The parsing logic read this string and immediately queried the internal allowlist. If the address matched an authorized user, the application transitioned to processing the email body as an authenticated command payload. The application did not compare the MIME header against the SMTP envelope sender.

Furthermore, the application logic did not verify the results of Sender Policy Framework (SPF) or DomainKeys Identified Mail (DKIM) checks. Even if an upstream MTA flagged an email as failing cryptographic authentication, ZeptoClaw ignored these signals. The application assumed that the presence of an email in its processing queue implied that the upstream infrastructure had already validated the sender's identity, an assumption that breaks down when handling generic SMTP relays or misconfigured MTAs.

The vulnerability was addressed in ZeptoClaw version 0.7.6 via commit bf004a20d3687a0c1a9e052ec79536e30d6de134 (PR #324). The patch redesigns the identity verification pipeline by introducing strict identity binding and mandatory cryptographic validation. The updated logic acts as a secondary defense layer, operating independently of the upstream MTA's configuration.

The core of the fix involves correlating the SMTP envelope sender with the MIME From: header. The application now rejects inbound emails where these two values do not match or align according to strict domain rules. This explicitly prevents an attacker from using a controlled envelope sender to bypass spam filters while spoofing the display header.

Additionally, the patch enforces mandatory SPF and DKIM validation for all allowlisted domains. The application now parses the Authentication-Results headers appended by the receiving MTA. If an email originates from an allowlisted address but lacks a cryptographic proof of authenticity (a pass result for DKIM and SPF), ZeptoClaw rejects the payload.

The release also included a secondary security hardening measure targeting attachment processing. The patch introduced strict sanitization of attachment filenames to prevent path traversal sequences (e.g., ../../). This prevents an authenticated (or successfully spoofed) attacker from writing files to arbitrary system directories.

Exploiting this vulnerability requires network access to the SMTP gateway or relay that feeds emails into the ZeptoClaw application. The attacker must also possess knowledge of at least one email address present on the target's allowlist. The attack does not require direct access to the victim's internal network, provided the inbound mail route is publicly accessible.

An attacker initiates the exploit by constructing a malicious email. The SMTP envelope sender (MAIL FROM) is set to an arbitrary domain controlled by the attacker. This ensures that the email successfully traverses initial spam filters that rely on SPF checks against the envelope domain. The attacker then constructs the MIME payload, setting the From: header to the known allowlisted email address.

Upon receiving the email, the vulnerable version of ZeptoClaw parses the spoofed From: header, confirms its presence in the allowlist, and executes the instructions within the email body. The attacker can structure the body to issue commands to the AI assistant, resulting in unauthorized actions being performed under the context of the spoofed user.

The successful exploitation of this vulnerability results in an unauthorized user gaining complete interaction capabilities with the ZeptoClaw AI assistant. Because the application processes the attacker's email as if it originated from a highly trusted source, all authorization controls protecting the AI agent's functions are bypassed. The attacker achieves the same level of privilege as the allowlisted user.

The concrete impact depends heavily on the specific agent instructions the AI is configured to handle. If the assistant is integrated with internal APIs, databases, or sensitive local files, the attacker can instruct the AI to exfiltrate data, modify records, or initiate unauthorized state changes. The execution of these commands occurs seamlessly without generating explicit authentication failure logs.

The associated CVE (CVE-2026-32231) carries a CVSS v3.1 base score of 8.2 (High). The vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N accurately reflects the remote, unauthenticated nature of the attack. While availability is not directly impacted, the integrity of the system and the confidentiality of the data accessible to the AI agent are significantly compromised.

The primary and most comprehensive remediation is upgrading the ZeptoClaw installation to version 0.7.6 or later. This release contains the necessary structural changes to the email parsing logic, enforcing both envelope-to-header binding and cryptographic signature validation. System administrators must ensure that the updated binary is deployed across all environments processing inbound communications.

Organizations should also harden their upstream mail infrastructure. The MTA responsible for receiving external emails before routing them to ZeptoClaw must be configured to strictly enforce Domain-based Message Authentication, Reporting, and Conformance (DMARC) policies. Emails failing SPF or DKIM checks should be rejected at the network edge rather than passed downstream.

As a defense-in-depth measure, administrators should implement network isolation for the ZeptoClaw webhook and email processing interfaces. Restricting incoming connections on these endpoints to known, trusted IP ranges or specific internal relays minimizes the attack surface. Regularly auditing the ZeptoClaw allowlist to remove inactive or unnecessary accounts further reduces the potential targets for spoofing attacks.