Dado que está utilizando log4j 1, la vulnerabilidad específica no está presente allí. Sin embargo, tenga en cuenta lo siguiente de http://slf4j.org/log4shell.html :

¿Es log4j 1.x vulnerable? Dado que la versión 1.x de log4j todavía se implementa ampliamente, quizás 10 veces más que la versión 2.x de log4j, hemos recibido un flujo constante de preguntas sobre la vulnerabilidad de la versión 1.x de log4j.

Como log4j 1.x NO ofrece un mecanismo de búsqueda JNDI a nivel de mensaje, NO sufre de CVE-2021-44228.

Sin embargo, log4j 1.x viene con JMSAppender que realizará una búsqueda JNDI si está habilitado en el archivo de configuración de log4j, es decir, log4j.properties o log4j.xml .

Un atacante que YA tiene acceso de escritura al archivo de configuración log4j deberá agregar JMSAppender a la configuración envenenada con parámetros de conexión maliciosos. Tenga en cuenta que el uso legítimo anterior de JMSAppender es irrelevante para la capacidad del atacante de montar un ataque exitoso.

También tenga en cuenta que envenenar el archivo de configuración no es suficiente. El atacante también necesita forzar a log4j a recargar su archivo de configuración con los parámetros envenenados. Dado que log4j 1.x no ofrece recarga automática, el archivo de configuración envenenado normalmente solo se hará efectivo al reiniciar la aplicación.

Sin embargo, aunque no es fácil, tal ataque no es imposible. Por lo tanto, tiene sentido dificultar aún más el trabajo del atacante eliminando JMSAppender por completo de log4j-1.2.17.jar.

En ausencia de una nueva versión de log4j 1.x, usted mismo puede eliminar JMSAppender del artefacto log4j-1.2.17.jar. Aquí está el comando:

 zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

Si no tiene acceso a 'zip', también puede usar el comando 'jar'.

 #assuming log4j-1.2.17.jar exists in current directory mkdir tmp cd tmp jar xvf ../log4j-1.2.17.jar rm org/apache/log4j/net/JMSAppender.class jar cvf ../log4j-1.2.17-patched.jar .

No hace falta decir que una vez que log4j-1.2.17.jar esté parcheado, deberá implementarlo.

La otra respuesta no es correcta. También existe una vulnerabilidad para la versión 1.x. CVE-2021-4104 https://access.redhat.com/security/cve/CVE-2021-4104 :

Se encontró una falla en la biblioteca de registro de Java Apache Log4j en la versión 1.x. JMSAppender en Log4j 1.x es vulnerable a la deserialización de datos que no son de confianza. Esto permite que un atacante remoto ejecute código en el servidor si la aplicación implementada está configurada para usar JMSAppender y para el JMS Broker del atacante.

Para la mitigación de esta vulnerabilidad:

Estas son las posibles mitigaciones de esta falla para los lanzamientos de la versión 1.x:

• Comente o elimine JMSAppender en la configuración de Log4j si se usa
• Elimine la clase JMSAppender del classpath. Por ejemplo:

zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class

• Restrinja el acceso para el usuario del sistema operativo en la plataforma que ejecuta la aplicación para evitar que el atacante modifique la configuración de Log4j.