Full Report
Cloudflare Email Routing was in a closed beta, with the author not being invited. A check in the UI was placed to allow access to the functionality or not; this could be bypassed via changing a boolean from true to false. The actual bug has to do with the email routing itself. When setting up routing, you need to prove ownership of it. Changes, such as modifying the DNS records, should not be possible until ownership is verified of the domain. A domain can only be active in my account at a time; but, multiple accounts can be unverified/pending at the same time. The author wanted to verify that the ownership check for a domain was validated prior to making changes. It turns out, that it wasn't! So, an attacker could have a domain in the pending state and still make changes to it. Obviously, this only worked for domains already using Cloudflare Email routing. As an attacker, this allows for the hijacking of email routing entirely by specifying an additional location for it to be returned to. This completely breaks the price of email! Additionally, emails are commonly used for password resetting, making all users at major risk. Overall, two great bug finds for a bug bounty payout.
Analysis Summary
# Vulnerability: Hijacking Cloudflare Email Routing via Improper Ownership Verification
## CVE Details
- **CVE ID**: Not Assigned (Cloudflare private bug bounty program)
- **CVSS Score**: Estimated 8.8 (High/Critical)
- **CWE**: CWE-285 (Improper Authorization), CWE-639 (Insecure Direct Object Reference)
## Affected Systems
- **Products**: Cloudflare Email Routing (Beta)
- **Versions**: Production environment prior to December 9, 2021
- **Configurations**: Any domain actively using Cloudflare’s Email Routing service during the closed beta period.
## Vulnerability Description
Two primary flaws were combined to achieve this hijacking:
1. **Client-Side UI Bypass**: Access to the Email Routing beta was restricted via a client-side flags check (`https://dash[.]cloudflare[.]com/api/v4/zones/<zone_id>/flags`). By intercepting the response and changing the `"beta"` boolean from `false` to `true`, unauthorized accounts could access the configuration interface.
2. **Missing Ownership Verification**: The Cloudflare API failed to verify if a zone (domain) was active and verified in a specific account before applying Email Routing configuration changes. While a domain can only be *active* in one account, it can exist as a *pending/unverified* zone in multiple accounts. The backend allowed users with the domain in a "pending" state to overwrite the global routing rules for that domain if it was already utilizing the Email Routing service.
## Exploitation
- **Status**: Fixed in production; PoC demonstrated by researcher; no known exploitation in the wild.
- **Complexity**: Low
- **Attack Vector**: Network
- **Pre-requisites**: The target domain must have already been enrolled in Cloudflare Email Routing.
## Impact
- **Confidentiality**: High (Attacker can intercept and read all incoming emails by redirecting them to a rogue destination address).
- **Integrity**: High (Attacker can prevent emails from reaching the intended recipient; potential for account takeovers via password reset hijacking).
- **Availability**: High (Email service for the target domain is effectively disrupted/redirected).
## Remediation
### Patches
- **Cloudflare Side**: The vendor implemented server-side authorization checks between December 9 and December 14, 2021. The API now validates that a zone is active and verified within the specific account attempting to modify routing rules. No user action is required.
### Workarounds
- There are no known client-side workarounds other than ensuring Multi-Factor Authentication (MFA) is enabled on all accounts linked to the domain to mitigate the impact of hijacked password reset emails.
## Detection
- **Indicators of Compromise**: Unexpected changes in email delivery; emails not arriving at the configured destination; unauthorized destination addresses appearing in Cloudflare Email Routing logs (if available to the domain owner).
- **Detection Methods**: Since this was a server-side logic flaw within a managed service, historical detection requires reviewing Cloudflare audit logs for configuration changes made from unauthorized or unrecognized account IDs.
## References
- **Vendor Report**: hxxps://hackerone[.]com/reports/1419341
- **Original Write-up**: hxxps://albertpedersen[.]com/blog/hijacking-email-with-cloudflare-email-routing/
- **SecurityTrails (Used for targeting)**: hxxps://securitytrails[.]com/list/mx/amir[.]mx[.]cloudflare[.]net