CompetitiveSASEZero TrustResilience

Cloudflare's October: Great Under Pressure, Until Zero Trust Went Down

October 25, 2026 · Brian Deitch

Cloudflare had a genuinely impressive October, and a genuinely painful one, sometimes in the same 24 hours. Disclosure: I work at Zscaler, and Cloudflare competes with us in Zero Trust and SSE. So I'll start with what they did well, because they earned it. Every fact here is from Cloudflare's own posts and public status data, linked below.

What They Got Right

PHP2Shell. Cloudflare had WAF rules live at 3:02am UTC on October 21, roughly nine hours before the PHP2Shell vulnerabilities were even public. Free plans included. They also shipped response-side rules that inspect what the origin sends back and can block it before it reaches the attacker. That's a smart layer for memory-leak bugs.

And they were honest about the limits: the WAF is defense in depth, not a patch, attackers were mutating payloads to evade the rules, and on October 23 they flagged a related flaw, CVE-2026-115560, that affects fully patched PHP too. That's the kind of transparency customers should demand from every vendor.

The eMudhra certificate mess. Private keys for eight eMudhra intermediate certificates were compromised, which in theory let an attacker forge a certificate for any domain. Cloudflare learned about it around 17:00 UTC on October 19, shipped WARP and 1.1.1.1 client updates by 02:00 UTC on October 20, updated cloudflared that morning, and had CDN and Zero Trust mitigations fully deployed by that evening. They report no active exploitation on their services. Fast work on an ugly problem.

What Went Wrong

At 03:20 UTC on October 20, in the middle of that certificate response, Cloudflare's WARP and Zero Trust services started failing globally. Access logins, Secure Web Gateway connectivity, and the dashboard were affected, and Cloudflare warned users could see connectivity issues or a degraded internet experience. The fix went in at 04:44 UTC, logins and gateway traffic were restored by 05:46, and it was resolved at 06:32. About three hours, end to end.

Then October 23 brought a cluster: a 20-minute Access availability issue, nearly three hours of degraded performance on traffic between Cloudflare data centers, and over five hours of delayed, missed, and duplicated Workers Cron Triggers. Cloudflare hasn't published a root cause for the October 20 outage that I could find, so I'm not going to guess at one.

The Competitive Lens

Here's the part every security buyer needs to sit with, whichever vendor they pick, mine included.

When your SSE is inline, its uptime is your uptime. A Zero Trust platform isn't a dashboard you check. Every user's access to every app flows through it. When it degrades, people can't work. Three hours of global WARP and Zero Trust trouble isn't a minor incident for the companies routing their workforce through it.

So the questions aren't "do you ever go down?" Everyone does. The questions are:

  • What's the blast radius? Does a failure stay regional, or does it go global?
  • What fails open and what fails closed, and do I get to choose per app?
  • How fast is the status page honest? And will I get a real root cause afterward?
  • What's your track record over a year, not a quarter?

Ask every vendor those questions in writing. Ask Zscaler too. A good vendor will have real answers, not marketing ones.

Bottom Line

Cloudflare's security response this month was excellent: early on PHP2Shell, fast and transparent on eMudhra. But Zero Trust is a reliability business as much as a security one. Blocking the exploit is table stakes. Staying up while you do it is the job.

Sources: Cloudflare on PHP2Shell protections, Cloudflare on the eMudhra certificate compromise, and the October 20 incident timeline

cloudflarewarpcloudflare-onephp2shellemudhracertificatesoutagessezero-trustresilience
All postsDiscuss on LinkedIn