A continuación, se muestran los CVE en el orden en que aparecieron así como las nuevas vulnerabilidades y actualizaciones.

• CVE-2021-44228 [Crítico, 10.0]: la vulnerabilidad Log4Shell original es unafalla de deserialización. Tiene un puntaje de 10 en la escala CVSS y otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados, lo que permite la toma de control completa del sistema.
  Informado por Chen Zhaojun del equipo de seguridad en la nube de Alibaba a Apache el 24 de noviembre, CVE-2021-44228 afecta las configuraciones predeterminadas de múltiples marcos de Apache, incluidos Apache Struts2, Apache Solr, Apache Druid, Apache Flink y otros.
  Siendo la más peligrosa de todas, esta vulnerabilidad se esconde en el componente log4j-core, limitado a las versiones 2.x: desde la 2.0-beta9 hasta la 2.14.1 inclusive. Se implementó una solución para Log4Shell en la versión 2.15.0, pero se consideró incompleta.
  El analista de inteligencia de amenazas Florian Roth compartió las reglas Sigma [1, 2] que pueden emplearse como una de las defensas en los SIEMs.
• CVE-2021-45046 [Crítico, anteriormente bajo, 9.0]: Este es un defecto de Denegación de Servicio (DoS) con un puntaje de 3.7 9.0. La falla surgió como resultado de una solución incompleta que entró en 2.15.0 para CVE-2021-44228. Si bien la corrección aplicada a 2.15.0 resolvió en gran medida la falla, ese no fue el caso para ciertas configuraciones no predeterminadas.
  Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada. Para aquellos en la rama 2.12.1, una corrección fue retro-portada a 2.12.2.
• CVE-2021-4104 [Alto, 8.1]: Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya o es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza.
  Aunque es una variante menos severa de CVE-2021-44228, no obstante, este CVE afecta todas las versiones de los componentes log4j:log4j y org.apache.log4j:log4j para los cuales solo existen versiones 1.x. Debido a que estas son versiones al final de su vida útil, no existe una solución para la rama 1.x en ninguna parte, y se debe actualizar a Log4j-core 2.16.0 o superior.
• CVE-2021-42550 [Moderado, 6.6]: esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x.
  Hasta la semana pasada, Logback también se jactaba de que “al no estar relacionado con Log4j 2.x, Logback no comparte sus vulnerabilidades”. Esa suposición se desvaneció rápidamente cuando se descubrió que CVE-2021-4104 también afectaba a Log4j 1.x, y se evaluó la posibilidad de un impacto potencial en Logback. Se han lanzadoversiones más recientes de Logback v1.3.0-alpha11 y v1.2.9 que abordan esta vulnerabilidad menos grave.
• CVE-2021-45105 [Alto, 7.5]: Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Desde entonces, Apache ha lanzado una versión log4j 2.17.0 que corrige el CVE. 
• ¿Un CVE más…? Sigue leyendo.

Desde que comenzó la crítica saga de día cero de Log4j la semana pasada, los expertos en seguridad han recomendado una y otra vez la versión 2.16.0 como la versión más segura. Eso cambia hoy con la versión 2.17.0 que corrige una vulnerabilidad de denegación de servicio (DoS) de gravedad aparentemente menor, pero ‘alta’ que afecta a Log4j 2.16.0. Y, sí, este error DoS viene con otro identificador: CVE-2021-45105.

La sospecha de un error DoS que afecta a Log4j 2.16.0 surgió en el proyecto JIRA de Apache hace unos tres días, poco después de que se descubriera que 2.15.0 era vulnerable a una vulnerabilidad DoS menor (CVE-2021-45046).

Fuente: https://blog.segu-info.com.ar/2021/12/resumen-de-todos-los-cve-de-log4j.html