Waratek ARMR Remediation Patch

Log4Shell Vulnerabilities

Only Waratek provides a fully programmable security platform that can remediate vulnerabilities, including CVE-2021-45046, CVE-2021-4104, CVE-2021-44228, and CVE-2021-45105.

The Log4Shell Problem

Log4Shell is a high severity vulnerability impacting multiple versions of the Apache Log4j utility.

What this Means?

The vulnerability allows for unauthenticated remote code execution or Denial of Service (DoS) attacks, depending on the version of Log4j your code or dependencies depend on.


The severity of the vulnerabilities range from low severity due to requiring a non-standard Log4J configuration to the highest severity score that a vulnerability can have.

What can I do?

Within 12 hours of the Zero Day announcement Waratek delivered our first ARMR Remediation Patch. Waratek’s fully programmable security Platform ARMR enables you to fully remediate the vulnerable Log4j code inside your application’s live executing code in real-time without making changes to your codebase.

When you apply the ARMR Remediation Patch it applies to your entire stack of technologies that your application depends on, including obscure dependencies. To secure your vulnerable application with the ARMR Remediation Patch, click here.

ARMR Remediation Patch

Virtual Patching

Waratek ARMR Remediation Patch


Don’t just find vulnerabilities, fix them.

Apply custom security rules as well as current and historical virtual patches for instant protection.
  • Create and apply custom virtual patches
  • Library of past CPUs
  • Instant protection
  • No downtime
  • No source code changes
  • Functional equivalent physical patches
  • No break / No exploit guarantee

Physically patching known software flaws is time consuming and risky. That’s why traditional virtual patching, also referred to as virtual shielding, is often mentioned as a way to quickly protect applications against known CVEs. But, traditional virtual patches still leave you vulnerable to attack.

Only Waratek can fix the vulnerable code of a CVE with no downtime, no source code changes, and no tuning.

Waratek’s runtime virtual patching is fundamentally different. A runtime virtual patch is the functional equivalent of a physical binary patch that is applied while the application runs with no source code changes and no tuning required.

The known vulnerabilities are remediated, reducing the time-to-patch across an enterprise from weeks, months, or years to a matter of minutes.

Runtime Virtual Patching
Code dependent on vulnerable versions of Log4j enters the Just In Time (JIT) Compiler
Waratek applies rules that apply virtual patches in memory
The application now operates as if the Log4j had been updated with the suppliers patch update
The Management Console advises the operator that the patch has been applied

Customer Advisories


CVE-2021-45105 explains how Log4j versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) allows attackers to cause denial of service when a crafted string is interpreted causing a recursive lookup.


CVE-2021-45046 explains how Log4j version 2.15.0 was incomplete in certain non-default configurations.


Posted in the GitHub Advisory Database, CVE-2021-44228 explains how Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.


CVE-2021-4104 explains how Log4j version 1.2 is vulnerable to deserialization of untrusted data when the attacker causes JMSAppender to perform JNDI requests that result in remote code execution.

Get the Patch