ZOOMSDAY: What Happens When Exploits Outrun Patches?

A vulnerability as severe as remote code execution can go from public advisory to working exploit much faster than most orgs can go from triage to patch. AI compresses the amount of time and expertise required for vulnerability research, but defenders are increasingly playing a game where the attacker gets the first (and faster) move. How do we level the playing field?

Binary to RCE in hours

In August 2026, security researchers at A Security disclosed a set of vulnerabilities in Zoom that they called ZOOMSDAY, in Zoom's annotation functionality, including memory-corruption issues that could ultimately be chained into remote code execution (RCE).

Like nearly every piece of written content in 2026, you will be hearing more about AI in this one. The researchers used AI-assisted analysis alongside tools including IDA Pro and Frida to reverse engineer and understand Zoom's native code and proprietary annotation protocol. Their initial static analysis didn't immediately identify the vulnerable component. In fact, the annotation library eventually found to contain the relevant vulnerabilities ranked only 45th in their initial prioritisation.

Then, rather than simply looking for dangerous functions, the researchers dynamically traced Zoom while exercising different meeting functionality and identified code that was actually involved in processing remotely supplied annotation data. From there, they reconstructed parts of the undocumented protocol, identified attacker-controlled fields reaching native parsers, found memory-safety issues, and developed working exploitation paths.

According to A Security, the process from initial discovery to a working exploit took less than 24 hours and fewer than 20 prompts. Is this proof of the AI-doom reality where autonomous agents hack us all?

Not yet, fortunately so. This wasn't a case of an AI independently deciding to hack Zoom from scratch (phew!). The researchers brought substantial expertise, chose the target and methodology, and orchestrated the underlying reverse-engineering and dynamic-analysis tooling. We believe that actually makes the result more interesting, not less. Tasks that traditionally required significant manual effort across reverse engineering, protocol analysis, debugging and exploit development can increasingly be accelerated by models that can reason over, and interact with, those tools. The result is a shrinking distance between discovering that something is vulnerable and demonstrating that it can actually be exploited.

The exploit clock is shrinking

There has always been a race between disclosure and exploitation. A vulnerability becomes public, then security teams investigate, vendors release patches and organisations assess exposure. Eventually, the vulnerable systems are updated. That traditional workflow assumes some breathing space.

Now, once technical details become public, the information needed to reproduce or weaponise a vulnerability is accessible to everyone. And AI-assisted research introduces another variable: the amount of human effort required to turn that information into something operational can decrease.

The old mental model was roughly:

The first two arrows, in red, used to provide some amount of friction, which is now evaporating. A public advisory might contain the affected component, vulnerable function, input conditions and patch diff. Historically, an attacker might still need substantial reverse engineering to understand how those pieces fit together.

Now, increasingly capable models can help with that work. Every CVE doesn't necessarily become an exploit overnight, but the distribution of time-to-exploit is changing. A vulnerability can become practically exploitable before the organisation has finished deciding whether it matters. Picture your average security team: a vulnerability scanner reports a Medium severity issue which sits behind several layers of infrastructure, and the affected component isn't obviously internet-facing. Thousands of findings to triage, the ticket is scheduled for remediation next week. Then someone proves that the vulnerable code is reachable through a path the organisation didn't know existed. What now?

Vulnerable doesn't always mean exploitable

Severity tells us something about the characteristics and potential impact of a vulnerability but doesn't necessarily tell us: can an attacker reach it from here? Does the vulnerable code execute in this deployment? And can the vulnerability actually be weaponised against this asset? Those are fundamentally different questions from "how bad is it, scale of 1-10."

Modern vulnerability management often operates at enormous scale. Organisations can have thousands, sometimes millions, of findings across endpoints, APIs, cloud workloads, containers and third-party dependencies.

The natural response is to prioritise on the basis of signals like severity, but that is still a proxy. The missing piece is often exploit validation.

How do we level the playing field?

If attackers can increasingly compress the time from vulnerability disclosure to exploitation, security teams also need a way to compress the time from "we found a vulnerability" to "we know whether this vulnerability actually matters here."

Exploit validation could provide that layer. A validated finding can tell defenders that a supposedly low-priority vulnerability has a real attack path, and it can also provide evidence that a seemingly severe vulnerability is not reachable under the current deployment conditions.

Security teams need environment-specific evidence rather than relying entirely on severity, assumptions or inventory data. And that evidence can change what gets fixed first. Validation needs to be designed carefully, manual or automated with controlled payloads, constrained execution, clear stop conditions and an emphasis on demonstrating exploitability without turning the validation system itself into an attack platform.

The race isn't going away

ZOOMSDAY is formal evidence for a pattern we've been noticing in the field firsthand: parts of the vulnerability research and exploitation workflow can be compressed dramatically when experienced researchers combine AI with mature security tooling.

The exploit clock will continue to move, what we do with the shrinking window is what matters. When the time between disclosure and exploitation keeps shrinking, knowing what exists isn't enough, but knowing what is actually exploitable may be the edge defenders need.