The Moment an Exploit Either Succeeds or Gets Blocked

In the AI era, patching faster still matters. But the decisive security control is what happens when exploitation happens at runtime.

By Gal Elbaz, Co-founder & CTO, Oligo Security

There is a moment in every attack that decides everything: when an exploit tries to run.

That is the point when a weakness becomes a breach, a CVE leads to an incident, and an attacker either gets what they came for or walks away empty-handed. 

Our industry has built most of its work around everything that happens before that moment by hunting, scoring, and prioritizing vulnerabilities, then pushing engineering to patch them faster. That work matters and will always matter, but it is not where the fight is won.

The real battleground is the point of execution.

The Old Model Assumed Time

For years, vulnerability management quietly rested on one assumption: defenders had time.

It was assumed that the model of scanning, triaging, assigning owners, deploying patches, testing it, and shipping it without breaking the business. 

The assumption was never perfect, and it is no longer workable.

Mandiant’s M-Trends reporting has continued to show exploitation of vulnerabilities as a leading initial access vector in serious intrusions. That matches what we see in production: the vulnerabilities that create real incidents are often not exotic. They are known, reachable, and simply not remediated in time.

Look at the recent record. Log4Shell was being weaponized in the wild within hours of disclosure. Spring4Shell, MOVEit, and regreSSHion forced enterprises into multi-week remediation marathons against attackers who needed minutes. Industry data has shown for years that even critical vulnerabilities routinely take 30 days or more to fully eliminate from production environments, and that is for the ones organizations actually find.

AI compresses that gap in ways that many did not see coming.

AI Doesn't Just Find More Vulnerabilities. It Compresses the Exploit Timeline.

This is the sentence security leaders should remember.

AI-assisted reverse engineering, fuzzing, and exploit synthesis are drastically shrinking the window between disclosure and weaponization. Techniques that once required elite human skill can now be reproduced, automated, and scaled.

Meanwhile, the average enterprise patch cycle has not magically accelerated. Backlogs are real, ownership is messy, and production is fragile. No organization on earth can patch at machine speed.

Defenders should keep patching faster. They should keep shifting left. All of that still matters. But there is a truth our industry has been slow to say out loud:

Patching faster is not the same as stopping exploitation.

A patch that ships next week does not stop an exploit today. A ticket in a backlog does not stop command execution. A dashboard that says "exposed" does not stop malicious behavior. A scanner finding does not protect a running application.

At the point of attack, visibility alone is not enough. You need control.

Where Code Becomes Behavior

After years of watching production systems behave very differently from their architecture diagrams, one thing becomes obvious: a vulnerability in source code is only a potential risk.

Actual risk lives somewhere else. It lives at execution, when the application loads libraries, calls functions, parses input, opens files, spawns processes, and talks to the network.

To make it concrete. An attacker-controlled string reaches a deserialization function that should have rejected it, and a process spawns that the application has never spawned before. Template parsing leads to command execution on a host that has no business issuing commands. A vulnerable parser, normally inert, suddenly opens a network connection to an IP it has never seen.

That is where exploitation actually materializes: as behavior. 

This distinction is what separates vulnerability management from exploit prevention. One catalogs what could go wrong. The other decides whether it gets to.

The Exploit Doesn't Care About Your Workflow

Attackers don’t care about your patch cycles. They care about one thing: can they make the application do something it should never do?

A CVE existing is not what makes an exploit successful. An exploit is successful because attacker behavior reaches a dangerous code path and the system allows it to continue. Strip away the acronyms and the dashboards, and that is the whole story.

At that moment, the theory ends. The dashboards do not matter. The reports do not matter. The roadmap does not matter.

The application either allows the behavior, or it does not.

The exploit either succeeds, or it gets blocked.

That is the moment security has to own.

‍