The time between vulnerability disclosure and exploitation is shrinking rapidly. Attackers can weaponize vulnerabilities in hours, while organizations often need days or weeks to develop, test, and deploy patches.

Sweet Security's new Virtual Patching capability closes that gap, allowing security teams to block exploitation directly inside running applications, without modifying code, redeploying workloads, or interrupting production.

Powered by eBPF-based runtime sensors and application-aware stack tracing, Sweet goes beyond detecting malicious behavior: it can stop dangerous operations at the point of execution.

Node2Shell: Stopping an RCE Before It Executes

The recently disclosed Node2Shell vulnerability (CVE-2026-111497) demonstrates why this approach matters. The vulnerability affects the Brotli decompression library embedded in Node.js, where a specially crafted compressed stream can trigger memory corruption and potentially lead to remote code execution.

In the following demonstration of Sweet's virtual patching capabilities, the attack begins with a malicious Brotli stream reaching Node.js's zlib module. Exploitation of the vulnerable code path hijacks control flow, eventually attempting to execute a shell command through Node.js's child_process API.

Sweet captures the entire execution chain, from the vulnerable library function through the attempted command execution, and blocks the clone() syscall before the malicious child process is created.

The original application continues running.

‍

How It Works: Application Context Meets Kernel-Level Enforcement

Traditional security controls often operate at the network boundary, attempting to identify malicious requests before they reach the application. Sweet takes a complementary approach: enforcing protection at the point where an exploit attempts to perform a dangerous operation.

Sweet's eBPF-based sensors combine kernel-level visibility with application-aware stack tracing, enabling security teams to understand not just what an application is doing, but why and where an operation originated.

For example, a Node.js application launching a child process may be perfectly legitimate – but when that operation originates from a vulnerable Brotli decompression routine, as indicated by the stack trace, the execution context tells a very different story.

In our Node2Shell demonstration, Sweet applies a targeted blocking rule:

• Process: Node.js
• Call stack: Contains node:zlib._close()
• Operation: clone() (process creation)
• Action: Block execution

When the execution path matches the rule, Sweet prevents the syscall from completing, stopping the attempted process creation without terminating the application.

The same enforcement mechanism supports blocking other system calls, allowing security teams to define targeted protections against different exploitation techniques based on runtime context.

From Detection to Prevention, Without Waiting for a Patch

Virtual patching provides an immediate layer of protection while engineering teams work on permanent remediation. Through Sweet's platform, security teams can identify vulnerable workloads, investigate exploit paths, and enforce targeted protection policies directly through the existing runtime sensors.

No application code changes or redeployments are required.

And unlike broad process termination or workload isolation, targeted syscall blocking can prevent a specific malicious operation while allowing legitimate application activity to continue.

Virtual patching is not a replacement for fixing the underlying vulnerability. Rather, it allows organizations to reduce exposure immediately instead of remaining vulnerable throughout the remediation process, as this can take days, weeks, or even months.

Don't Just Detect the Exploit. Stop It.

As AI accelerates vulnerability discovery and exploitation, detecting threats and issuing remediation tickets is no longer enough. Sweet's Virtual Patching brings prevention directly into the application runtime, combining deep execution visibility with precise enforcement.

The result: exploitation attempts blocked, applications kept running, and security teams no longer forced to choose between immediate protection and operational continuity.