Silent-Forwarder: the mail-security vulnerability class your registrar isn't telling you about

The 'Forwarders' feature at nearly every domain registrar and shared-hosting provider lets anyone who can see your account silently redirect your email — invisibly, without notification, and often without an audit trail you can inspect. We're publishing the paper, the open-source detector, and an IETF draft of the fix today.

Silent-Forwarder: the mail-security vulnerability class your registrar isn't telling you about

TL;DR

  • The gap: domain registrars (Porkbun, Namecheap, GoDaddy, Dynadot, Cloudflare Registrar, and many others) and shared-hosting cPanel/WHM installations let any administrator of your account add a mail forwarder — redirecting your entire mailbox to any external address — with no notification to you, no proof-of-ownership of the destination, and in most cases no audit log you can inspect.
  • The impact: because email is the recovery channel for essentially every consumer and enterprise identity, a silent forwarder converts a one-time registrar-account compromise or a successful support-ticket phishing call into a persistent, invisible account-takeover posture across every service you use.

What we are publishing today

  1. Silent-Forwarder (paper, arXiv) — the full research paper, including a STRIDE threat model, a four-adversary-class attacker-defender formalism, and a reproducible six-dimensional measurement protocol.
  2. divolt-security-research/forwardguard — Apache-2.0 open-source detection tooling, four pipelines, Docker image, SIEM-friendly output. Runs today against Porkbun, cPanel, and Cloudflare Email Routing; Google Workspace and Microsoft 365 adapters next.
  3. draft-divolt-smfps-00 — an IETF Internet-Draft of the Silent-Mail-Forwarding Prevention Standard. Eight normative requirements, each with a conformance test. Submitted today to the IETF mailmaint working group.

Why we are publishing all three at once

Research papers describe a problem. Open-source tools let defenders act today. Standards give vendors a path to fix the class permanently. Any one of these alone is insufficient. We are publishing all three on the same day because the problem is systemic, the window to detect it is short, and the vendor path to a durable fix needs a specification to converge on.

This is Divolt Security Research's inaugural public work. We are releasing it under the research arm because the artefact belongs to the community, not to any one commercial product. The managed-service variant of ForwardGuard that we will offer at divoltbtc.com/forwardguard is strictly optional; the open-source core is complete, free, and self-sufficient.

What is the silent-forwarder primitive?

A mail forwarder is a legitimate SMTP feature: a receiving mail-transfer agent takes mail addressed to one address and re-sends it to another. Gmail has required out-of-band confirmation for forwarders since 2010; a destination address has to click a verification link before any mail is actually forwarded, and the primary mailbox owner is notified of the change. For a decade now, "forwarding attacks" against Gmail have been noisy and observable.

The two much larger classes of mail-handling systems that have not received the same treatment are:

  1. Domain registrars offering "email forwarding" as a bundled feature of domain registration. Add a forwarder in the Porkbun / Namecheap / Hover / GoDaddy / Dynadot / Gandi / Cloudflare Registrar / &c. control panel and mail starts flowing to your target destination within minutes. The destination is not asked to confirm anything. The mailbox owner (if different from the registrar-account owner) is not notified.
  2. The "Forwarders" feature of cPanel/WHM, which powers an estimated 70% of commercial shared-hosting mailboxes. The forwarder is often created in the filesystem as a one-line .forward or /etc/valiases/domain.tld entry, invisible to any user who does not have shell access to the account.

We call the resulting capability — silent, unaudited, unnotified redirection — the silent-forwarder primitive. Its security impact is disproportionate to its complexity because email is still the single most important recovery channel on the Internet.

Who exploits this?

Four adversary classes, all empirically observed in the field (see §3.1 of the paper):

  • A1 — Insider. An outsourced IT contractor, an operations assistant, a former employee whose access was not revoked. The primitive is directly available to them; they do not need to escalate privileges.
  • A2 — External admin-compromise. An attacker who acquired the registrar or cPanel account credentials by phishing, credential stuffing, or breach replay. The Verizon DBIR 2024 attributes 68% of web-application breaches to credential-based access; this is the modal case.
  • A3 — Reseller or supply-chain compromise. The attacker gains access via a managed-services provider whose administrative API has write access to your domain. See the 2024 Squarespace / Google Domains migration incidents.
  • A4 — Support-ticket social engineering. The attacker opens a support ticket with the registrar and persuades a human to add a forwarder on their behalf. See the 2022 OpenSea DNS-registrar incident and the 2023 Reddit administrative-support compromise.

What should defenders do today?

  1. Install ForwardGuard. Point it at your registrar accounts, your cPanel installation, and your IMAP mailboxes. Run it as a cron, or as a daemon with syslog + webhook alerting. The whole thing fits in a Docker container. If a silent forwarder is implanted at any point in the future, you find out.
  2. Audit your current forwarders. Open the DNS/email control panel at every registrar and hosting provider that holds any of your domains. Enumerate every active forwarder and verify each is legitimate.
  3. Make an operational note: email forwarding is a configuration-plane change at your registrar. Treat it with the same operational scrutiny as a DNS change or a domain-transfer out.

What should vendors do?

Adopt SMFPS. The specification is eight requirements, each with a conformance test. The minimum compliance profile — R1 through R4 — eliminates the silent-forwarder primitive while preserving every legitimate forwarding use-case. We expect first implementations within three to six months and would love to collaborate with your security team on an early rollout.

Run ForwardGuard against your domains this weekend.

Open-source, Apache 2.0, Dockerised. Twenty minutes of configuration, then it runs forever and tells you if a silent forwarder is ever added.

Get ForwardGuard on GitHub Read the SMFPS standard

Divolt Security Research

Divolt is a security startup headquartered in Accra, Ghana. Divolt Security Research is the arm of the company that publishes open artefacts; we also build the Divolt Aegis continuous-pentest platform. We think the mail-plane and the identity-plane are the two under-researched attack surfaces of the current decade. Silent-Forwarder is the first paper in that programme; the next three are drafted and in review internally.

If you operate a registrar or a hosting-control-panel product and want to pilot an SMFPS implementation, write to research@divoltbtc.com. If you want ForwardGuard run against your domains on a managed service, write to sales@divoltbtc.com. If you found a bug in ForwardGuard, write to security@divoltbtc.com.

— Divolt Security Research, Accra, 2026-10-18