Cloudflare launches Zero Wire: free briefings to tell you which critical vulnerability to patch first

On November 3, 2026, Cloudflare introduced Zero Wire, a new section of Cloudflare Radar dedicated to critical Internet vulnerabilities. It's not yet another CVE database: it's a news-agency-style "wire service" with short briefings that explain what happened, who should check, what to do right now, and where the evidence is. It's public, free, and useful even if you're not a Cloudflare customer. It matters because the pace of serious vulnerabilities isn't slowing down: in October and November alone we've already had php2shell in PHP, a use-after-free in Linux TCP, and node2shell in Brotli, and anyone who manages servers needs to separate the noise from the urgent without reading ten different advisories before breakfast.

Why Cloudflare says it's needed

The announcement, signed by Daniele Molteni and Celso Martinho, opens with a scene familiar to anyone who runs infrastructure: it's 7 a.m., a critical vulnerability drops, and the team starts comparing vendor advisories, reading research, and checking which systems run the affected software, while the company asks the usual question: does it hit us, and what are we doing about it? And before you finish, another one arrives.

Cloudflare attributes part of that pressure to artificial intelligence. According to the post, AI is changing "the volume and speed" at which critical vulnerabilities are discovered, because it can analyze huge codebases and find flaws that have been hiding for years. This isn't theory: according to Cloudflare, php2shell itself was disclosed in a coordinated way by Calif.io, Wiz, OpenAI, and Quarkslab.

What exactly Zero Wire is

Zero Wire lives inside Radar, in the security section. Cloudflare makes clear that it does not aim to catalog every CVE, but to complement vendor advisories and vulnerability databases. Its focus is critical flaws in software exposed to the Internet: web applications, the runtimes and libraries they depend on, and published services, which is precisely where a proxy can help slow down exploitation.

A detail worth noting: having a Cloudflare WAF rule is not a requirement for a vulnerability to be included. Some flaws need vendor patches or changes that web traffic can't reveal, and they're documented anyway.

The front page splits the briefings into two trays:

Needs attention: flaws with known exploitation, ongoing research, or guidance that's still changing.
Reference: briefings whose guidance has stabilized. Cloudflare insists that moving to this tray doesn't mean everyone has already patched.

Each card shows a status and a last-reviewed date. At the time of writing, the urgent tray had five briefings reviewed between October 19 and November 2: the use-after-free in IPv4 TCP on Linux (CVE-2026-98432), php2shell, the compromise of eMudhra intermediate certificates, node2shell (CVE-2026-111497, in the Brotli decoder), and command execution in Citrix NetScaler (CVE-2026-88771). Under reference there was the WordPress SQL injection and RCE. There's also an RSS feed to follow additions and changes.

Diagrama: anatomía de un briefing de Zero Wire, con sus seis secciones (tarjeta y estado, overview, qué hacer ya, prompt para tu agente, cobertura de Cloudflare, evidencia y cronología) y las bandejas Needs attention y Reference

How each briefing is put together

The php2shell briefing shows how it works in practice. The structure is the same in all of them:

Section	What it answers
Overview	What happened, why it matters, and which teams should investigate
What to do now	The concrete next steps
Prompt for an agent	How to assess your own infrastructure with AI, read-only
Cloudflare coverage	Whether WAF rules exist and how to configure them
Evidence and sources	Vendor advisory, CVE records, CISA KEV, observed traffic
Timeline	What changed and when

In php2shell's case, the briefing makes clear something many people still confuse: these are flaws in the PHP runtime (CVE-2026-109618 and CVE-2026-109619), so updating WordPress, Magento, or a plugin fixes nothing. It points to the official PHP advisory, which asks you to update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 and lists as exposed every installation that serves web requests: PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. The briefing also separates a third related CVE, CVE-2026-115560, which only applies with an uncommon session configuration and for which PHP recommends disabling session.upload_progress until its next maintenance release.

The timeline sums up in five lines what happened from October 21 to 30, including that CISA added the two original CVEs to its known exploited vulnerabilities catalog on October 26. For anyone coming back to the briefing, that saves rebuilding the story from scratch.

The prompt for your AI agent

The newest part is a prompt ready to copy into an agent with access to your infrastructure. In the php2shell briefing, the text asks the agent for a read-only assessment: don't send exploit payloads, don't trigger memory exhaustion, and don't change anything. It asks it to check current advisories, inventory PHP across hosts, containers, Kubernetes, and images, check the runtime that actually serves requests (not just the CLI version), evaluate each CVE separately, and report the WAF separately from patch status. The expected result is a per-asset table of what's affected, what's fixed, and what's unknown.

Cloudflare clarifies that copying the prompt doesn't scan or modify anything by itself. My take: it's a good template even if you don't use agents, because it forces you to separate three questions that get mixed up in every crisis: am I affected? have I patched? and am I being attacked?

What Zero Wire doesn't do

The announcement is honest about its limits, and it's worth keeping them in mind:

A WAF doesn't replace the patch. Cloudflare repeats it: a rule is a compensating control for the traffic it covers. It can keep exposed data from reaching the attacker, but it doesn't undo what has already happened on the origin server.
Seeing attacks doesn't prove compromises. The charts of requests matching WAF rules don't count compromised systems or successful exploits. And the fact that Cloudflare doesn't see attempts on its network doesn't mean they don't exist elsewhere.
The card's status isn't a verdict on your environment. Known exploitation, open research, and patch available describe different things.
Dashboard links don't activate anything. They take you to the rule configuration so you can check whether you're protected; they don't enable rules or verify deployments.

And one the post doesn't say but needs saying: it's an editorial selection by Cloudflare, with its own telemetry and its own products in the coverage section. It doesn't replace subscribing to the security advisories of your distribution, your CMS, and your runtime. If you use Drupal, for example, Drupal's security advisories remain the source that rules.

What to do with this

If you manage web servers, Zero Wire works as a first-line filter: add its RSS to your reader or your alerts channel, and when something shows up in "Needs attention" that touches your stack, go straight to the vendor advisory the briefing links. If your site goes through Cloudflare, check under Security > Security Rules that the managed rules are in blocking mode, but don't confuse that with being patched.

My final take: the value isn't that Cloudflare discovers vulnerabilities, but that it sorts them with a discipline many teams don't have at 7 a.m.: what's confirmed, what isn't known, and who has to move. The fact that it's free and public means there's no excuse for not having it on your radar.