Waratek launches zero-config reflection attack defense

Waratek on August 18, 2026, released a new Reflection Protection rule that blocks unsafe reflection and dynamic class-loading exploits at the runtime layer. The feature is designed to stop both known CVEs and zero-days without code changes, downtime, or complex setup.

Why it matters: - Unsafe reflection is a common path to remote code execution and full system compromise. - Waratek is positioning runtime protection as a faster defense than patch-and-wait workflows. - The release targets both known vulnerabilities and zero-days, including issues tied to AI-generated code patterns.

What happened: - Waratek announced a new Reflection Protection rule on August 18, 2026. - The rule is a runtime security feature for blocking exploitation of unsafe reflection and dynamic class-loading vulnerabilities. - The protection is designed to work without code changes, application downtime, or complex configuration. - Waratek said the rule is available now to Waratek RASP customers. - The company said customers can enable the rule in minutes through the Waratek Portal's rule wizard. - Waratek invited users to visit Waratek's announcement to schedule a demonstration.

The details: - The rule tracks untrusted data and hooks into the Reflection API. - Waratek said the protection runs at the JVM layer and applies immediately across protected applications. - The feature is intended to stop attacks regardless of which library, framework, or application introduces the flaw. - Waratek said the rule addresses unsafe reflection attacks tied to both disclosed CVEs and vulnerabilities that have not been disclosed yet. - The company cited a 177.8% year-over-year increase in unsafe reflection vulnerabilities in 2026 versus 2025 so far. - Waratek said that pace points toward more CVEs in this category than the previous three years combined. - The company linked the rise to AI-assisted coding and AI-assisted vulnerability discovery tools. - Unsafe reflection often appears in JSP loading paths and expression language evaluators. - The vulnerability pattern commonly involves attacker-controlled input reaching APIs such as Class.forName(). - CVE-2026-63317 / CVE-2026-42027 involve three code paths that load classes by fully qualified name and invoke no-argument constructors without validating the class name or type. - Waratek said an attacker who can tamper with a model archive or format name could force arbitrary class instantiation in those cases. - CVE-2026-40008 involves a pipe processor that reads a fully qualified class name and instantiates it with Class.forName().newInstance() without validation or allowlisting. - Waratek said that flaw could let an attacker controlling that input load and execute arbitrary code. - Waratek said unsafe reflection vulnerabilities grew by 525% between 2022 and 2026. - The company said the new rule is available without source code modifications, redeployment, or application downtime.

Between the lines: - Waratek is arguing that runtime defenses need to move as fast as AI-assisted vulnerability discovery. - The product pitch is less about one exploit family and more about shutting down an entire class of attacks at the point of execution. - The company is also signaling that patch management alone is too slow for the current disclosure and exploitation cycle.

What's next: - Waratek said security and engineering teams can turn on the rule immediately from the portal. - The company is steering prospects to a live demonstration of the protection. - Broader adoption will likely hinge on whether teams want runtime controls that block reflection-based attacks before patches are available.

The bottom line: - Waratek is betting that zero-config runtime blocking can become a default defense for a vulnerability class that keeps resurfacing.