Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io

GHSA-4cm8-xpfv-jv6f

MEDIUM

ZeptoClaw: Email Sender Spoofing to bypass Header-Only From Allowlist Validation

Published
Mar 12, 2026
Updated
Mar 14, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🦀zeptoclaw

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The email channel authorizes senders based on the parsed From header identity only. If upstream email authentication/enforcement is weak (for example, relaxed SPF/DKIM/DMARC handling), an attacker can spoof an allowlisted sender address and have the message treated as trusted input.

Details

Relevant code paths:

  • src/channels/email_channel.rs:311 extracts sender identity from parsed message headers:
    • let from = parsed.from() ... a.address() ...
  • src/channels/email_channel.rs:328 authorizes using that from value:
    • if !self.is_sender_allowed(&from) { ... }
  • src/channels/email_channel.rs:87 onward (is_sender_allowed) performs allowlist/domain matching against the same header-derived value.
  • There is no in-channel validation of sender authenticity indicators such as SPF/DKIM/DMARC results before allowlist trust decisions.

Result:

  • Trust decision is based on a potentially spoofable header field unless mailbox/provider-side anti-spoofing controls are strong and enforced.

PoC

  1. Configure email channel with strict sender allowlist:
    • channels.email.enabled = true
    • channels.email.allowed_senders = ["[email protected]"]
    • channels.email.deny_by_default = true
  2. Ensure the monitored mailbox accepts or forwards a spoofed message (for testing, use a local SMTP path that does not enforce sender authentication strongly).
  3. Send an email to the monitored inbox with forged header identity:
python - <<'PY'
import smtplib
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "[email protected]"   # forged trusted sender
msg["To"] = "[email protected]"
msg["Subject"] = "forged control message"
msg.set_content("FORGED EMAIL CONTENT")

# Example test SMTP endpoint
with smtplib.SMTP("127.0.0.1", 25) as s:
    s.send_message(msg)
PY
  1. Wait for IMAP fetch/IDLE processing.
  2. Observe the message is accepted as allowlisted sender [email protected] and published as inbound channel input.

Impact

  • Vulnerability type: sender identity spoofing risk due to header-based authorization.
  • Affected deployments: those using email channel allowlists where upstream anti-spoof controls are weak, misconfigured, or bypassed.
  • Security effect:
    • Spoofed From headers may bypass logical sender allowlist.
    • Malicious content can enter trusted automation/agent flows as if sent by authorized identities.
  • Risk is reduced in environments with strict SPF/DKIM/DMARC enforcement and strong inbound mail hygiene, but not eliminated at application layer.

Patch Recommendation

Add a sender-authentication gate in src/channels/email_channel.rs immediately after parsing from (src/channels/email_channel.rs:311) and before allowlist enforcement (src/channels/email_channel.rs:328). The gate should require trusted SPF/DKIM/DMARC evidence with domain alignment (for example, DMARC=pass, or aligned SPF/DKIM pass) before is_sender_allowed is evaluated. For backward compatibility, add a configurable mode in EmailConfig (for example, sender_verification_mode), but recommend hardened settings in production: dmarc_aligned, exact-address allowlists, and deny_by_default=true.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iozeptoclawall versions0.7.6

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zeptoclaw. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update zeptoclaw to 0.7.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4cm8-xpfv-jv6f is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-4cm8-xpfv-jv6f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-4cm8-xpfv-jv6f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary The email channel authorizes senders based on the parsed `From` header identity only. If upstream email authentication/enforcement is weak (for example, relaxed SPF/DKIM/DMARC handling), an attacker can spoof an allowlisted sender address and have the message treated as trusted input. ### Details Relevant code paths: - `src/channels/email_channel.rs:311` extracts sender identity from parsed message headers: - `let from = parsed.from() ... a.address() ...` - `src/channels/email_channel.rs:328` authorizes using that `from` value: - `if !self.is_sender_allowed(&from) { ... }` -
O3 Security · Impact-Aware SCA

Is GHSA-4cm8-xpfv-jv6f in your dependencies?

O3 detects GHSA-4cm8-xpfv-jv6f across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.