RHSA-2022:0203CriticalCVSS 9.8

Red Hat Security Advisory: Red Hat Fuse 7.8-7.10 security update

Published
January 20, 2022
Last Modified
August 4, 2026

🔗 CVE IDs covered (4)

CVE-2021-44228 →CVE-2021-44832 →CVE-2021-45046 →CVE-2021-45105 →

📋 Description

CVE-2021-44228 — log4j-core: Remote code execution in Log4j 2.x when logs contain an attacker-controlled string value CVE-2021-44832 — log4j-core: remote code execution via JDBC Appender CVE-2021-45046 — log4j-core: DoS in log4j 2.x with thread context message pattern and context lookup pattern (incomplete fix for CVE-2021-44228) CVE-2021-45105 — log4j-core: DoS in log4j 2.x with Thread Context Map (MDC) input data contains a recursive lookup and context lookup pattern

🎯 Affected products1

  • Red Hat Fuse 7.8.2, 7.9.1, 7.10.1

✅ Remediation

Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on. Installation instructions are available from the Fuse product documentation pages: Fuse 7.8: https://access.redhat.com/documentation/en-us/red_hat_fuse/7.8/html/installing_on_apache_karaf/apply-hotfix-patch https://access.redhat.com/documentation/en-us/red_hat_fuse/7.8/html/deploying_into_spring_boot/patch-red-hat-fuse-applications Fuse 7.9: https://access.redhat.com/documentation/en-us/red_hat_fuse/7.9/html/installing_on_apache_karaf/apply-hotfix-patch https://access.redhat.com/documentation/en-us/red_hat_fuse/7.9/html/deploying_into_spring_boot/patch-red-hat-fuse-applications Fuse 7.10: https://access.redhat.com/documentation/en-us/red_hat_fuse/7.10/html/installing_on_apache_karaf/apply-hotfix-patch https://access.redhat.com/documentation/en-us/red_hat_fuse/7.10/html/deploying_into_spring_boot/patch-red-hat-fuse-applications Workaround: For Log4j versions >=2.10 set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true For Log4j versions >=2.7 and <=2.14.1 all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m For Log4j versions >=2.0-beta9 and <=2.10.0 remove the JndiLookup class from the classpath. For example: ``` zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ``` On OpenShift 4 and in OpenShift Logging, the above mitigation can be applied by following the steps in this article: https://access.redhat.com/solutions/6578421 On OpenShift 3.11, mitigation to the affected Elasticsearch component can be applied by following the steps in this article: https://access.redhat.com/solutions/6578441 Workaround: As per upstream: - In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java. - Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. Workaround: For Log4j versions up to and including 2.15.0, this issue can be mitigated by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Workaround: For Log4j 2 versions up to and including 2.16.0, this flaw can be mitigated by: - In PatternLayout in the Log4j logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC) like %X{loginId}. - Otherwise, in the Log4j logging configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

🔗 References (11)