On September 3, 2026, Cloudflare announced early access to the Vulnerability Discovery and Remediation service within Cloudflare Managed Defense, helping teams identify and address the most urgent vulnerabilities in codebases. The service is currently available to selected customers by invitation only, and each engagement begins with a single application for 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 in an active route, how heavily that route is used, whether it is subject to targeting attempts, and what protections are already applied to it.
From a List of Findings to a Production-Linked Priority
Cloudflare says modern analysis tools, including large language models, can find many weaknesses in a short time, but this makes it more difficult to determine what should be fixed first. A scanning tool may reveal a problem in a software handler without indicating 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 high-traffic routes as hot paths subject to more stringent security analysis when the deployed code behind them is under review.
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 handling 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 validation 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 validation, the service produces a ranked list of findings, with an initial risk classification that increases when indicators such as traffic volume or reconnaissance activity on the endpoint are present. It also suggests a code patch and may propose a custom WAF rule to reduce exposure temporarily 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 take place 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 redaction controls specified for the engagement 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 under the access policy, while patches and rules undergo testing outside the model.
Before presenting any finding to the customer, Cloudflare validates the output. Reviewing edge-protection suggestions includes checking the rule’s 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 finding remains ambiguous, it is withheld from review and referred for diagnosis.
Why Does This Announcement Matter?
The practical change is shifting vulnerability-remediation prioritization from a theoretical score in a scanning report to an assessment that also takes its actual production exposure into account. This may help teams facing thousands of findings focus first on active code associated with high traffic or malicious activity, while providing a potential 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 an early-access phase, limited to invitations, and requires clear 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.