Cloudflare Publishes a Wire Service for Critical Vulnerabilities

TL;DR

• Zero Wire is a public vulnerability intelligence feed inside Cloudflare Radar that publishes short briefings on critical vulnerabilities in Internet-facing software; one briefing can cover several related CVEs when grouping them clarifies the response.
• Cloudflare announced it on 3 November 2026, with each briefing covering what happened, who should investigate, what to do now and where the evidence sits.
• The homepage sorts briefings into "Needs attention" and "Reference", and each card carries a status plus a last-checked date; a briefing in Reference can still concern an organisation with unfinished remediation.
• Evidence links point at CVE records, research and CISA's Known Exploited Vulnerabilities Catalog, and the network charts count requests matching WAF managed rules. Cloudflare says these counts measure attempts seen by its rules; evidence from an organisation's systems is required to determine compromise.
• Each briefing offers a pre-compiled prompt that asks an AI agent connected by your team to perform a read-only assessment of your environment.
• Where a WAF rule exists, the card reports its availability and sends you to review your configuration; the link opens the relevant configuration for review; rule activation requires a separate configuration action.
• The format stops at the edge of your estate: asset identity, ownership, installed version and control state stay with your team, and those four fields decide whether a briefing becomes an answer.

Cloudflare published Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities, on 3 November 2026. The product is small and specific: a public feed inside Cloudflare Radar that publishes briefings on critical issues in Internet-facing software and can cover several related CVEs together when that makes the response clearer, written so that a security lead can read it in the time it takes to finish a coffee and an engineer can follow the same page down to the technical guidance. The framing in the post is a wire service, and that framing carries the design.

A curated feed for exposed software

The choice of scope reads as deliberate. Zero Wire focuses on critical CVEs in web applications, the runtimes and libraries they depend on, and services exposed to the internet. It is a curated set of significant issues, with vendor advisory and vulnerability-database coverage left where it already exists. Cloudflare describes the feed as public and says that issues can be included independently of WAF rule availability.

A briefing carries five fields and one date

Open a card and the structure is the same every time. The overview explains what happened, why it deserves attention and which teams should investigate. "What to do now" gives a short list of next steps, which can mean identifying affected deployments, checking versions with a hosting provider, applying vendor updates, reviewing suspicious activity or holding compensating controls in place. The evidence section links outward. The Cloudflare section says what the vendor's own controls cover. The update chronology records new advisories and changes to guidance.

Two fields do the quiet work

The homepage places issues requiring active assessment or action under “Needs attention” and keeps briefings under “Reference” when guidance has stabilised; the last-checked date says when the underlying evidence was last reviewed. Cloudflare is explicit that the two categories answer different questions, and that a briefing in Reference can still matter to an organisation that has not finished remediation. That sentence is the honest part of the design: a Reference label describes the state of public guidance, and a patched estate is a fact about your own systems.

The php2shell entry shows where traffic evidence stops

The most useful briefing in the launch set is probably the one on php2shell, the two PHP runtime vulnerabilities that landed in October 2026. The card explains that the flaws sit in the runtime itself, which matters for anyone running WordPress or Magento on a platform they did not build: updating a plugin or an application bundle leaves the interpreter untouched. The briefing names the system owners who should care and links the PHP project's own security guidance for affected versions.

The evidence section on that page includes a chart of HTTP requests matching Cloudflare's WAF managed rules for php2shell over time. Read it as a measure of attacker interest. Cloudflare's own note is explicit: a matched request is an attempt in flight, and the count tracks how much attention a vulnerability is attracting. The number of compromised systems requires separate evidence. The corollary is stated too, in the general briefing text. Determining whether a particular organisation was compromised requires evidence from that organisation's systems, and exploitation elsewhere remains possible when Cloudflare's network records no attempts.

That paragraph is the reason this feed is worth reading. Most vulnerability dashboards place the internet's activity and a specific company's exposure on the same plane. A chart of blocked requests is telemetry about the traffic Cloudflare saw, and the only party that can turn it into a statement about your estate is the party holding the asset list.

Status and last-checked describe the evidence, and the reader supplies the asset

Start with the four fields an operator must supply, and the format becomes clearer. Your own records must identify which of your hosts runs the affected runtime, who approves an out-of-band update, whether that host answers the internet at all, and whether the rule that would mitigate the issue is actually switched on. Those four answers live in an inventory, a rota and a change record.

Consider a hypothetical case. A Casablanca logistics company runs its customer portal on a managed PHP platform and a small intranet on an old interpreter image that nobody has touched since the migration. The php2shell briefing applies to both: the hosting provider's patch process covers the portal, and the company owns remediation of the intranet image. An asset register that records the interpreter version distinguishes them.

The pre-compiled prompt produces questions for your estate

Each briefing ships with a prompt intended for an AI agent, asking for a read-only assessment of deployed software, relevant vendor fixes, exposure and compensating controls, with per-asset evidence, explicit unknowns and next actions. Cloudflare defines the scope carefully: the prompt asks the AI agent connected by your team to perform a read-only assessment. It structures the conversation your team has with its own tooling.

That is a reasonable shape for the job, and the wording that matters is "unknowns". Confident answers about an estate nobody has inventoried amount to plausible fiction. An assessment that lists its unknowns gives an operator concrete questions to pursue.

The same logic applies to the update chronology, which records new advisories and revisions to the response guidance. A team that read a briefing on the first day and returns a week later needs to know what moved, and the chronology with the last-checked date answers that question without a full re-read.

WAF coverage carries a review step

Where a CVE can be addressed with a WAF rule, the briefing reports that a rule exists and what configuring it requires, with links that take paid and free plans to the relevant dashboard. The next step printed on the card is a review step: check your configuration to determine whether you are protected. A link opens the relevant configuration for review; rule activation requires a separate configuration action.

Cloudflare's own caveat is the one to keep: a WAF mitigation provides a compensating control for covered traffic, and actions already performed at the origin remain in effect after requests are blocked. If an attacker reached the interpreter before the rule was deployed, the rule changes nothing about what already happened. A WAF mitigation provides a response window. Following the vendor's remediation guidance fixes the vulnerable software, and the feed is clear about the role it offers.

What an operator attaches to the card

The briefing format is worth adopting internally even for a team that never opens Radar. Four fields turn a public card into a decision: the asset, the owner, the version read from the host, and the state of the compensating control. Two of those are inventory work, one is a change-management habit, and one is a configuration check performed in the dashboard. Monitoring adds the fifth, which is the evidence that something tried the door — the sort of alerting that belongs in infrastructure monitoring with plain-language alerts and should reach operators as events occur.

The habit that makes the format pay off is smaller than a programme. When a briefing arrives, write the four answers next to the card, including the ones you cannot answer. The unknowns become the backlog, and the next disclosure finds a shorter list.

Sources

• Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities, Cloudflare, blog.cloudflare.com, 2026-11-03
• Cloudflare deploys protections against php2shell vulnerability, Cloudflare, blog.cloudflare.com, 2026-10-21

Source: the Cloudflare post of 3 November 2026, read in full on the same day. The Zero Wire scope, the Needs attention and Reference categories, the status and last-checked fields, the update chronology, the pre-compiled prompt and its read-only limit, the php2shell example, the CISA Known Exploited Vulnerabilities Catalog link, the WAF managed-rule chart and its caveat, the "Review your WAF configuration" step and the compensating-control note all come from that post. The four-field operator checklist and the Casablanca example are Netics analysis.