.svg)
Introducing Runtime Exploit Blocking
TL;DR: Runtime Exploit Blocking stops exploits inside the application by detecting malicious patterns at the syscall level, without killing containers, processes, or disrupting uptime. It's technique-based (not payload-based), which means one rule can protect against thousands of CVEs. This is the runtime protection teams are using to protect production applications today.
Security teams are tired. Another week, another critical CVE or supply chain attack. The backlog grows, patching takes months, and there's no reliable way to protect applications in the meantime.
WAFs help at the perimeter, but they don't see what happens inside the application. Attackers know this. They craft payloads that slip past signature-based detection, and by the time you've updated your rules, they've moved on to the next variation.
Why Blocking Is A Must Right Now
The majority of cloud security tools don’t keep up with today’s attack landscape. Attackers are using AI to find vulnerabilities, build exploits, and launch attacks faster than any security team can respond. Right now the average time to exploit is roughly one day, and AI advancements like Project Glasswing mean that this will only keep accelerating. For most teams, patching is still the only real mitigation. But patching doesn't scale and teams cannot patch fast enough. Also, patching assumes that a vulnerability is already known to the world and a fix has been created.
In 2026, blocking must be a primary strategy. However, blocking doesn’t exist in most security teams' toolset. WAF rules can't update fast enough to catch modern attacks. CNAPPs have response and containment actions, but they resort to treating symptoms and post-exploit behavior, rather than stopping initial intrusions outright.
Why Previous Approaches Failed
The industry has tried to stop exploits and attacks, but there has never been a viable solution. Not because blocking is a bad idea, but because no one had the right context to do it safely.
RASP promised runtime protection by instrumenting the application. The problem? RASP couldn't tell the difference between normal activity and an actual exploit. It saw too much and understood too little. Teams dealt with latency, false positives, and crashed applications. Most turned it off within months.
Cloud security vendors went a different direction. They added "response" capabilities to their detection products. But look at what that actually means: kill the container, terminate the process, or push a WAF rule. These tools operate at the infrastructure layer. They might know something bad is happening, but they can't see inside the application. They don't know what code is running or when that code starts doing something it shouldn't. Without that context, blunt force is the only option. Take everything down and figure it out later.
That’s why blocking capabilities have never been meaningfully adopted. Runtime blocking exists in product demos and marketing decks, but almost no one runs it in production. The risk of disruption is too high. Teams would rather accept the vulnerability than break the app.
The missing piece was always context. The ability to see running code at the function level and correlate it with syscalls in real time. That's what Oligo's sensor captures, making runtime exploit blocking possible.
Introducing Runtime Exploit Blocking
Runtime Exploit Blocking is a new capability built into the Oligo runtime sensor. It stops exploits before attackers can execute them, inside the application, without disrupting uptime.
Here's how it works: Oligo detects malicious patterns by correlating application-layer function calls with OS-level syscalls. A syscall preceded by a specific set of function calls indicates an exploit is trying to execute. Neither element is malicious on its own. The combination is what matters.
When Oligo detects this pattern, it blocks the syscall directly from the kernel. The attack stops. The application keeps running.
This is not payload inspection. We're not looking at attack strings or signatures. This is technique-based blocking. Attackers reuse techniques across thousands of different CVEs. Just do a quick search for deserialization in the CVE database and look at the results...
Block the technique once, and you neutralize all of them.
This technique-based detection and prevention is powerful because techniques are replicable across so many classes of attacks, including:
- Java Insecure Deserialization
- Python Insecure Deserialization
- JNDI Injection
- Python Template Injection
- And more
Runtime Exploit Blocking Use Cases
Attack Mitigation
Some things should never happen in production. Python deserialization leading to code execution, for example. With Runtime Exploit Blocking, you can sandbox entire libraries by defining which function calls should never lead to certain syscalls. If that pattern executes, Oligo blocks it without exception.
This is how you get ahead of attackers instead of chasing them. You're not patching individual CVEs. You're eliminating the technique they all depend on. For example, in an average-sized cloud environment, one blocking rule in Oligo prevents insecure deserialization for over 100 HIGH and CRITICAL Java CVEs and 80+ Python CVEs. One rule covers them all, including future CVEs that haven't been discovered yet.
One rule that neutralizes hundreds of vulnerabilities. And when the next deserialization CVE drops next month, you're already protected.
CVE Virtual Patch
A critical CVE drops. No patch exists, or your remediation timeline is weeks out. Worst case: the patch breaks your code and requires significant development effort to refactor. With Runtime Exploit Blocking, you enable protection for that specific CVE immediately. You're covered while you plan the fix. Protect now, patch later.
Incident Response
An active intrusion is detected. You need to contain it fast, but you can't afford to take your application offline. Runtime Exploit Blocking lets you close the exploit path in seconds while the application continues serving traffic. This allows you to contain without collateral damage.
Why This Is Different
Runtime Exploit Blocking works because Oligo sees what other tools can't: the correlation between what's happening inside the application and what's happening at the OS level. To put it simply: we see the code running in real-time. Our Deep Application Inspection sensor captures execution telemetry at the function and syscall level. That's what makes the "context" in Runtime Exploit Blocking possible.
A few things worth understanding:
Zero added latency. Blocking rules are triggered by the Oligo sensor and enforced directly in the kernel, where speed and performance matter. No network proxies, no instrumentation overhead, no inspection delays.
Surgical precision. We block the syscall, not the container. The application keeps running normally.
Works on code you don't own. No source code access required. Protect first-party applications and hosted third-party software alike.
Protects AI-powered apps and agents. Building AI into your applications? Starting to test and embed agentic workflows for your applications? Ultimately, AI is code, so Oligo can block exploits targeting your AI ecosystem.
The Bottom Line
Protection scales. Patching doesn't. One technique-based rule protects against hundreds of CVEs, including ones that haven't been disclosed yet.
Runtime blocking has always been a good idea that didn't work in practice. The tools were too risky. The tradeoff between protection and uptime was too steep.
Runtime Exploit Blocking changes that. It's runtime protection teams will actually use, because it stops attacks without stopping the business.
Learn More