CVE-2021-44228

Log4j2 is a piece of software used by many applications to record events in logs. This flaw can trick Log4j2 into trying to “look up” attacker-controlled network addresses when it processes certain log messages, which can then lead to running malicious code on the server.

Think of it like someone writing a dangerous instruction inside a note that your computer later “reads” and follows while trying to save it as a log entry—if the system is set up a certain way, that instruction can take over the machine.

This matters if you run software that includes Apache Log4j2 (log4j-core) or any listed products whose underlying components include vulnerable Log4j2 versions.

It’s a real risk even without any user clicking anything, and without needing login, if the server can be reached from the network and it processes attacker-controlled content that reaches Log4j2 message logging while the relevant message lookup/JNDI behavior is enabled (reachable in default configuration).

This is RED because it has been added to CISA KEV and is known to be used in ransomware campaigns. Attackers do not need you to click anything or log in—they can trigger the behavior by getting malicious text into log messages.

Treat this as an urgent, time-bound patch/remediation project for any affected Log4j2-using systems and any affected firmware/products with available updates.

Confirm whether you’re exposed

1. Inventory: Find every application/server where Apache Log4j2 (log4j-core) is present (including inside packaged apps, containers, and vendor appliances).
2. Version check: Determine the exact Log4j2 version installed on each system.
3. Input paths: Identify whether your apps log untrusted data (for example, web request headers, query strings, usernames, error details, message fields, or other data that an outside party can influence).

Apply the fixed versions

Upgrade to the vendor-provided fixes below (use the exact product and branch your inventory matches):

• apache log4j → fixed in 2.3.1
• 6bk1602-0aa12-0tp0 firmware → fixed in 2.7.0
• 6bk1602-0aa22-0tp0 firmware → fixed in 2.7.0
• 6bk1602-0aa32-0tp0 firmware → fixed in 2.7.0
• 6bk1602-0aa42-0tp0 firmware → fixed in 2.7.0
• 6bk1602-0aa52-0tp0 firmware → fixed in 2.7.0
• capital → fixed in 2019.1
• comos → fixed in 10.4.2
• e-car operation center → fixed in 2021-12-13
• energyip prepay → fixed in 3.8.0.12
• gma-manager → fixed in 8.6.2j-398
• industrial edge management hub → fixed in 2021-12-13

If you can’t update right away (temporary containment)

• CISA KEV guidance: for affected assets where updates exist, the acceptable options are to apply updates or remove affected assets from agency networks. Temporary mitigations from CISA’s recommended measures are only acceptable until updates are available.

What to monitor after patching

• Look for evidence of attempted/successful JNDI/LDAP-related outbound connections from application servers.
• Review application/server logs for lookups and suspicious errors around logging.
• Check for unexpected new processes or unusual child processes spawned by the service that uses Log4j2.

CISA due date reference

• CISA remediation due date for KEV listing: 2021-12-24 (if you still have any affected systems, act immediately now even though this date has passed).

Severity is critical because it enables remote code execution with no authentication and no user interaction when certain Log4j2 features are enabled. The mechanism is: attacker-controlled log message content/parameters are processed by Log4j2 in a way that can trigger JNDI lookups, allowing the attacker to point to attacker-controlled LDAP/other JNDI endpoints that can cause the server to load/execute malicious code.

KEV meaning: Being listed in CISA KEV indicates the vulnerability is confirmed as being exploited in the real world. This CVE is listed in CISA KEV and is described as used in ransomware campaigns.

Fix maturity: Public proof-of-concept exists, and the patch availability is well established with fixed versions provided (e.g., apache log4j fixed in 2.3.1; vulnerable firmware fixed in 2.7.0, etc.). The pulse/press notes indicate the vulnerability continues to attract attention, which aligns with widespread exposure but does not substitute for patching.

Reaching it: Risk is highest when an attacker can influence what gets written to Log4j2 logs and the relevant message lookup/JNDI behavior is enabled in the deployed configuration (reachable in default configuration).