Managed CNAME flaw pushed Cloudflare to sunset SSL for SaaS v1

Cloudflare has disclosed a vulnerability in its retired SSL for SaaS v1 (Managed CNAME) product, found earlier this year through its bug bounty program. The issue stems from the architecture of the original offering, which relied on IP-based routing rather than verified hostnames. While the risk was low, the company has been pushing remaining customers to migrate to SSL for SaaS v2 (Cloudflare for SaaS), the replacement released after v1 was deprecated in 2021.

How v1 routing created a security gap

SSL for SaaS launched in 2017 to let providers extend Cloudflare’s security and performance to their own customers via a Managed CNAME setup. End customers pointed their domains at the SaaS provider’s origin with a CNAME record, and traffic for custom hostnames was proxied based on IP addresses assigned to the zone.

That design carried a subtle flaw. In a standard Cloudflare connection, the certificate served is determined by the SNI in the TLS handshake, while the zone configuration is chosen by the host-header in the HTTP request. In SSL for SaaS v1, the certificate was still tied to SNI, but the zone configuration was selected solely by the anycast IP address the client connected to. Any custom hostname aimed at the correct IP could be served through Cloudflare without verified domain ownership.

An attacker aware of another customer’s Managed CNAME—through public info or social engineering—could abuse host header redirects via DNS manipulation and man-in-the-middle techniques, since Cloudflare would present a valid TLS certificate for the targeted Managed CNAME. For instance, if the anycast IP 192.0.2.1 belonged to a SaaS provider, a request to that IP would be routed to that provider’s origin regardless of the host-header: 

$ curl --connect-to ::192.0.2.1 https://www.cloudflare.com
Here, the certificate would be valid for www.cloudflare.com, but the request would not reach www.cloudflare.com’s origin; it would go to the SaaS provider’s origin assigned to that IP.

Exploitation was unlikely and required layered conditions, such as:

  • DNS poisoning of the target domain to redirect end-user traffic to the wrong IP
  • A method to inject a malicious payload or leverage an existing cross-site scripting vulnerability on the Managed CNAME customer’s site

v2 tightened the model

Cloudflare introduced SSL for SaaS v2—now known as Cloudflare for SaaS—to close that gap. Instead of IP-based routing, v2 uses a verified custom hostname model: custom hostnames must pass hostname verification along with SSL certificate validation before traffic is proxied to the origin. This limits origin access to authorized hostnames and includes hostname pre-validation so customers can confirm ownership before traffic flows through Cloudflare.

Deprecation began in March 2021 with notices to all v1 users of a September 2021 sunset. That timeline slipped for some customers, who received extensions due to migration difficulties. When the vulnerability was disclosed this year, Cloudflare was still working through the last v1 zones.

For the remaining v1 customers, Cloudflare has implemented compensating controls:

  • New accounts and new zones in existing accounts cannot configure v1 via UI or API
  • Cloudflare keeps an allowlist of zones and customers still on the service
  • WAF custom rules have been applied so requests to unauthorized destinations are blocked at the L7 firewall

What customers need to do now

Most Cloudflare customers need no action. The company says it is actively assisting the small number of SSL for SaaS v1 customers still on the old architecture to migrate to Cloudflare for SaaS. As the sunsetting enters its final phase, all current and future deployments will use the v2 verified-hostname model by default.

Cloudflare credited the external researchers who reported the issue responsibly and encouraged continued submissions to its bug bounty program.