CVE-2021-4104 identifies a deserialization vulnerability in Apache Log4j 1.2's JMSAppender component that enables remote code execution when attackers gain write access to Log4j configuration files. This vulnerability achieves a CVSS score of 7.5 (High severity) with an EPSS score of 98.7 percentile and 72.2% exploitation probability, indicating significant attack potential for systems using the vulnerable JMSAppender configuration. The vulnerability details reveal that JMSAppender performs unsafe JNDI lookups when configured with attacker-controlled TopicBindingName and TopicConnectionFactoryBindingName parameters, leading to remote code execution similar to the infamous CVE-2021-44228 Log4Shell vulnerability. This creates substantial exploit risk for Java applications using Log4j 1.2 with JMSAppender enabled, particularly affecting IBM Db2, enterprise Java systems, and over 20 other technologies that rely on Log4j's message queuing functionality for distributed logging architectures, though the vulnerability requires specific non-default JMSAppender configuration and configuration file write access for successful exploitation. The technical root cause lies in Log4j 1.2's JMSAppender implementation, which lacks proper validation of JNDI lookup parameters, allowing attackers with configuration access to trigger malicious JNDI requests that can load and execute arbitrary code from remote sources, creating a vector for known exploited vulnerabilities targeting Java logging frameworks. The vulnerability specifically affects the interaction between JMSAppender's configuration processing and JNDI lookup mechanisms, where malicious TopicBindingName and TopicConnectionFactoryBindingName values can redirect JNDI requests to attacker-controlled servers hosting malicious Java classes. With Apache Log4j 1.2 reaching end-of-life in August 2015 and over 50 affected packages including net-wireless/unifi and OpenShift components, this vulnerability highlights the ongoing security risks of using deprecated software versions. Mitigation strategies require upgrading to Log4j 2.x as the primary solution, with immediate workarounds including removing JMSAppender from configurations, deleting the JMSAppender class file (org/apache/log4j/net/JMSAppender.class), and implementing strict access controls to prevent unauthorized Log4j configuration modifications. Organizations should prioritize identifying all applications using Log4j 1.2 with JMSAppender configurations, implement comprehensive configuration file protection, audit logging infrastructure for vulnerable components, and maintain updated CVE database records to track similar JNDI injection vulnerabilities that could compromise Java application security through logging framework exploitation and deserialization attacks.