GHSA-4cm8-xpfv-jv6f
MEDIUMZeptoClaw: Email Sender Spoofing to bypass Header-Only From Allowlist Validation
Blast Radius
zeptoclawReal-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:311extracts sender identity from parsed message headers:let from = parsed.from() ... a.address() ...
src/channels/email_channel.rs:328authorizes using thatfromvalue:if !self.is_sender_allowed(&from) { ... }
src/channels/email_channel.rs:87onward (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
- Configure email channel with strict sender allowlist:
channels.email.enabled = truechannels.email.allowed_senders = ["[email protected]"]channels.email.deny_by_default = true
- Ensure the monitored mailbox accepts or forwards a spoofed message (for testing, use a local SMTP path that does not enforce sender authentication strongly).
- 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
- Wait for IMAP fetch/IDLE processing.
- 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
Fromheaders may bypass logical sender allowlist. - Malicious content can enter trusted automation/agent flows as if sent by authorized identities.
- Spoofed
- 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | zeptoclaw | all versions | 0.7.6 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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.
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.
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
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.