On September 3, 2026, Cloudflare announced early access to the Vulnerability Discovery and Remediation service within Cloudflare Managed Defense, to help teams identify and address the most urgent vulnerabilities in their codebases. The service is currently available only to selected customers by invitation, and each engagement begins with a single application to which the customer grants access to its code for investigation.
The core idea is not limited to running a code scanner and displaying a long list of findings. Combining code analysis with traffic data and security signals is intended to determine whether a vulnerability exists on an active route, how heavily that route is used, whether it is being targeted, and what protections are already applied to it.
From a List of Findings to a Production-Linked Priority
Cloudflare says that modern analysis tools, including large language models, can find many weaknesses in a short time, but that this makes it harder to know what should be fixed first. A scanning tool may uncover a problem in a software handler without explaining whether the code is actually deployed, whether the route that reaches it is being used, or whether attacks or protection rules are associated with it.
The service begins by collecting a snapshot of Web Assets and Web Application Firewall data, including active routes, the volume of requests they receive, and recent security events associated with them. It treats heavily trafficked routes as hot paths subject to stricter security analysis when the deployed code behind them is being examined.
For Cloudflare Workers, the service retrieves the latest version of the code and the routes configured for it, then links them to production endpoint data through Workers Observability and request data. This context remains available during the investigation so that software agents can use it when needed.
How the Models Are Used and What They Propose
The process relies on a reconnaissance agent that links request routes to the parts of the code that handle them, then directs research agents to relevant areas to find vulnerabilities. Cloudflare uses OpenAI Daybreak models, including GPT-5.6 Cyber, during the reconnaissance, research, and verification stages. However, linking a vulnerability to an active route is not enough to prove that it exists; Cloudflare requires every finding to be supported by evidence from the code itself.
After verification, the service produces a ranked list of findings, with an initial risk classification that increases when indicators such as traffic volume or probing activity on the endpoint are present. It also proposes a code patch and may suggest a custom WAF rule to temporarily reduce exposure while the code fix is being reviewed.
If the customer authorizes the service to defend its domain, the proposed WAF rules can be configured with a conservative scope focused on the HTTP method, route, and request details necessary to reach the vulnerable code. The service does not propose a rule when the route pattern consists only of general variables and alternatives, because it prefers missing a potential association to providing protection unsupported by evidence.
Execution Controls and the Limits of Automation
The investigation system runs on Cloudflare, while model prompts are sent from Workers through Cloudflare AI Gateway to OpenAI servers. Model inference does not run on Cloudflare’s edge network, and the model cannot apply the patch or WAF rule it proposes.
Each operation is limited to the code and evidence authorized by the customer, with unnecessary context removed and the sharing-specific redaction controls applied. The system treats code, logs, and request data as evidence for examination, not as instructions to follow. All tool calls are also logged and reviewed according to the access policy, while patches and rules undergo testing outside the model.
Before presenting any finding to the customer, Cloudflare verifies the output. Reviewing edge-protection suggestions includes checking the rule syntax and running it against synthetic test cases representing expected requests, rather than against the customer’s actual traffic. If a test fails or the result remains ambiguous, it is withheld from review and referred for diagnosis.
Why Does This Announcement Matter?
The practical change is shifting vulnerability-remediation priority from a theoretical score in a scan report to an assessment that also considers actual exposure in production. This may help teams facing thousands of findings focus first on active code associated with high traffic or attack activity, while providing a possible temporary WAF-level measure during remediation review.
However, the service does not eliminate the role of engineers or turn automated suggestions into automatic changes. It is in early access, limited to invitations, and requires explicit authorization to access code, asset data, WAF controls, and Workers Trace Events Logpush where available. The customer also reviews every finding before deciding whether to test or deploy it, while the accuracy of the final conclusion remains tied to the available evidence and the limits of the service’s authorized scope.