How to Fix CVE-2021-44228: Insecure Deserialization in Apache Log4j2

By Sai Kiran Pandrala

Patch immediately. Actively exploited. CISA listed this in the Known Exploited Vulnerabilities catalog on 2021-12-10. Federal due date: 2021-12-24. Treat any internet-exposed instance as a priority patch.

What is CVE-2021-44228?

CVE-2021-44228 is an insecure deserialization issue affecting Apache Log4j2 disclosed on 2021-12-10. An attacker who can send a crafted serialized payload may achieve remote code execution. CISA notes this CVE has been used in real-world attacks.

The technical detail from the advisory: Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Why this matters

CISA added this CVE to the Known Exploited Vulnerabilities catalog on 2021-12-10. That listing exists because at least one confirmed in-the-wild exploitation report was filed. Federal civilian agencies are bound by BOD 22-01 to patch by 2021-12-24, and most enterprises treat that timeline as a practical floor. Opportunistic scanning for known-exploited CVEs runs continuously across the public internet, so any unpatched exposed instance is on borrowed time.

The blast radius depends on how the affected service is exposed. An internet-reachable instance with no compensating controls is the highest-risk configuration. An internal-only instance behind authenticated VPN is lower risk but still requires the patch.

Am I affected?

You are affected if you run a version listed in the Affected row above. Check your installed build of Apache Log4j2 against that list. If your version sits at or below the affected range and you have not applied the vendor patch noted in the Fixed in row, you are vulnerable.

For internet-facing or business-critical instances, treat this as exposure until proven otherwise. Run an asset inventory to find every install of Apache Log4j2, including secondary or dev/test environments that may have been deployed and forgotten.

How to fix CVE-2021-44228

1. Read the official vendor advisory linked in References below. It carries the authoritative list of patched builds and any product-specific upgrade notes.
2. Inventory affected hosts before touching anything. Know how many instances you have, which are exposed, and which are HA-paired.
3. Take a configuration backup of the affected device or application.
4. Apply the patched build named in the Fixed in row. For HA pairs, patch the standby first, fail over, then patch the former primary.
5. Restart the service or device if the vendor procedure requires it.
6. Confirm the new version is running (see verification section).

1. Hunt for prior compromise. Because this CVE is in the CISA KEV catalog, assume opportunistic scanning has already touched any exposed instance. Review authentication logs, look for unfamiliar accounts, and check for unexpected processes or scheduled tasks.

Update the Java dependency

# Vendor advisory: https://logging.apache.org/log4j/2.x/security.html
# Bump to 2.3.1 from the advisory.
# Maven
mvn versions:set -DnewVersion=2.3.1 -DartifactId=<artifact-id>
mvn clean install

# Gradle
./gradlew --refresh-dependencies build

# Verify the runtime version
java -version

# Vendor advisory: https://logging.apache.org/log4j/2.x/security.html
# Restart the affected Windows service after replacing the JAR
Restart-Service -Name "<service-name>"
Get-Service -Name "<service-name>"

Verify the fix landed

# 1. Confirm the running version matches the fixed-in version from the advisory:
#    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
#    Use the platform-specific version probe above.

# 2. Re-scan with your vulnerability scanner (Nessus, Qualys, Tenable, OpenVAS).
#    The scanner should no longer flag CVE-2021-44228 on the patched target.

# 3. Inspect recent service / kernel logs for crash loops or rollback events.
journalctl -u <service> --since "10 minutes ago"
dmesg --since "10 minutes ago"

If you can't patch immediately

Apply vendor-published mitigations only. Common interim steps:

• Restrict network exposure. Place the vulnerable service behind a VPN or block external access at the perimeter firewall.
• Disable the affected feature if the vendor advisory documents a safe way to do so.
• Increase monitoring on the affected service. Alert on any successful authentication or unusual request pattern.

If the vendor advisory does not list a workaround, none has been validated. Patching is the only remediation in that case.

How to verify the fix worked

1. Check the running version of Apache Log4j2 matches a build named in the Fixed in row.
2. Re-run your vulnerability scanner against the host. The CVE should no longer flag.
3. If you applied mitigations instead of a patch, confirm those controls are still in place after the next reboot or configuration change.
4. Review logs from the exposure window. Anything anomalous needs an incident-response review, not a passive note.

Frequently asked questions

Related fixes

Other vulnerabilities in the same area that are worth patching alongside this one:

• How to Fix CVE-2021-40438: Server-Side Request Forgery in Apache HTTP Server — Server-Side Request Forgery in Apache HTTP Server
• How to Fix CVE-2021-41773: Path Traversal in Apache HTTP Server — Path Traversal in Apache HTTP Server
• How to Fix CVE-2021-42013: Path Traversal in Apache HTTP Server , Path Traversal in Apache HTTP Server
• How to Fix CVE-2021-45046: Log4j Lookup RCE and Information Disclosure , Log4j Lookup RCE and Information Disclosure

Is this CVE being exploited in the wild?

Yes. CISA added CVE-2021-44228 to the Known Exploited Vulnerabilities catalog on 2021-12-10, which means at least one confirmed real-world exploitation report exists.

Do I need to take the system offline to patch?

That depends on the vendor's upgrade procedure for Apache Log4j2. For HA-paired devices and clustered software, the standard pattern is to patch the standby instance first, fail over, and then patch the former primary. Read the vendor advisory for the exact steps.

Will my vendor support contract cover the patched build?

If your installation is on a supported release line, the patched build is usually a free upgrade. End-of-life or end-of-support builds may require a paid migration to a supported major version.

References

• Official vendor advisory: https://logging.apache.org/log4j/2.x/security.html
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV entry: "Apache Log4j2 Remote Code Execution Vulnerability" - added 2021-12-10

*Assembled from the official vendor advisory, NVD record, and CISA KEV listing on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.*