This is an automated email from the ASF dual-hosted git repository.

rpopma pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-log4j-site.git

commit afff7a9c28bd7937f0e26b4cc5ee6632429c1922
Author: Remko Popma <rem...@yahoo.com>
AuthorDate: Thu Dec 30 15:02:51 2021 +0900

    update email and other links on security page:
    
    * use security@logging email instead of private@logging
    * link to Users mailing list & request that people subscribe
    * add link to existing Log4j 1.x EOL statement
---
 log4j-2.17.1/security.html | 710 +++++++++++++++++++++++----------------------
 1 file changed, 361 insertions(+), 349 deletions(-)

diff --git a/log4j-2.17.1/security.html b/log4j-2.17.1/security.html
index 8af8fab..6935a1e 100644
--- a/log4j-2.17.1/security.html
+++ b/log4j-2.17.1/security.html
@@ -135,355 +135,367 @@
             </div>
           </div>
         </header>
-        <main id="bodyColumn"  class="span10" >
-<!-- vim: set syn=markdown : -->
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
-         http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-<h1>Apache Log4j Security Vulnerabilities</h1>
-<p>This page lists all the security vulnerabilities fixed in released versions 
of Apache Log4j 2. Each vulnerability is given a <a 
href="#Security_Impact_Levels">security impact rating</a> by the <a 
class="externalLink" href="mailto:priv...@logging.apache.org";>Apache Logging 
security team</a>. please note that this rating may vary from platform to 
platform. We also list the versions of Apache Log4j the flaw is known to 
affect, and where a flaw has not been verified list the version with  [...]
-<p>Note: Vulnerabilities that are not Log4j vulnerabilities but have either 
been incorrectly reported against Log4j or where Log4j provides a workaround 
are listed at the end of this page.</p>
-<p>Please note that Log4j 1.x has reached end of life and is no longer 
supported. Vulnerabilities reported after August 2015 against Log4j 1.x were 
not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain 
security fixes.</p>
-<p>Please note that binary patches are never provided. If you need to apply a 
source code patch, use the building instructions for the Apache Log4j version 
that you are using. For Log4j 2 this is BUILDING.md. This file can be found in 
the root subdirectory of a source distributive.</p>
-<p>If you need help on building or configuring Log4j or other help on 
following the instructions to mitigate the known vulnerabilities listed here, 
please send your questions to the public Log4j Users mailing list</p>
-<p>If you have encountered an unlisted security vulnerability or other 
unexpected behaviour that has security impact, or if the descriptions here are 
incomplete, please report them privately to the <a class="externalLink" 
href="mailto:priv...@logging.apache.org";>Log4j Security Team</a>. Thank you.</p>
-<p><a name="CVE-2021-44832"></a><a name="cve-2021-44832"></a></p><section>
-<h2><a 
name="Fixed_in_Log4j_2.17.1_.28Java_8.29.2C_2.12.4_.28Java_7.29_and_2.3.2_.28Java_6.29"></a><a
 name="log4j-2.17.1"></a> Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 
2.3.2 (Java 6)</h2>
-<p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>:
 Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls 
configuration.</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>
 </th>
-<th> Remote Code Execution </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Severity          </td>
-<td> Moderate </td></tr>
-<tr class="a">
-<td> Base CVSS Score   </td>
-<td> 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4 
</td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix 
releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) 
attack where an attacker with permission to modify the logging configuration 
file can construct a malicious configuration using a JDBC Appender with a data 
source referencing a JNDI URI which can execute remote code. This issue is 
fixed by limiting JNDI data source names to the java protocol in Log4j2 
versions 2.17.1, 2.12.4, and 2.3.2.</p> [...]
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>Log4j 1.x is not impacted by this vulnerability.</p></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for 
Java 8 and later).</p>
-<p>In prior releases confirm that if the JDBC Appender is being used it is not 
configured to use any protocol other than Java.</p>
-<p>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.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject 
affected by this vulnerability. Other projects like Log4net and Log4cxx are not 
impacted by this.</p></section></section><section>
-<h3><a name="Release_Details"></a>Release Details</h3>
-<p>From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), the JDBC 
Appender will use JndiManager and will require the log4j2.enableJndiJdbc system 
property to contain a value of true for JNDI to be enabled.</p>
-<p>The property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
log4j2.enableJndiLookup, log4j2.enableJndiJms, and 
log4j2.enableJndiContextSelector.</p>
-<p>JNDI functionality has been hardened in these versions: 2.3.2, 2.12.2, 
2.12.4 or 2.17.0: from these versions onwards, support for the LDAP protocol 
has been removed and only the JAVA protocol is supported in JNDI 
connections.</p></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more 
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>No credit is being awarded for this issue.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-
-<li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a></li>
-</ul>
-<p><a name="CVE-2021-45105"></a><a 
name="cve-2021-45046"></a></p></section></section><section>
-<h2><a 
name="Fixed_in_Log4j_2.17.0_.28Java_8.29.2C_2.12.4_.28Java_7.29_and_2.3.2_.28Java_6.29"></a><a
 name="log4j-2.17.0"></a> Fixed in Log4j 2.17.0 (Java 8), 2.12.4 (Java 7) and 
2.3.2 (Java 6)</h2>
-<p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>:
 Apache Log4j2 does not always protect from infinite recursion in lookup 
evaluation</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>
 </th>
-<th> Denial of Service </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Severity          </td>
-<td> Moderate </td></tr>
-<tr class="a">
-<td> Base CVSS Score   </td>
-<td> 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-beta9 to 2.16.0, excluding 2.12.4 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 2.12.4, did not 
protect from uncontrolled recursion from self-referential lookups. When the 
logging configuration uses a non-default Pattern Layout with a Context Lookup 
(for example, $${ctx:loginId}), attackers with control over Thread Context Map 
(MDC) input data can craft malicious input data that contains a recursive 
lookup, resulting in a StackOverflowError that will terminate the process. This 
is also known as a DOS (De [...]
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>Log4j 1.x is not impacted by this vulnerability.</p></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.0 (for 
Java 8 and later).</p>
-<p>Alternatively, this infinite recursion issue can be mitigated in 
configuration:</p>
-<ul>
-
-<li>In PatternLayout in the logging configuration, replace Context Lookups 
like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, 
%mdc, or %MDC).</li>
-<li>Otherwise, in the 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.</li>
-</ul>
-<p>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.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject 
affected by this vulnerability. Other projects like Log4net and Log4cxx are not 
impacted by this.</p></section></section><section>
-<h3><a name="Release_Details"></a>Release Details</h3>
-<p>From version 2.17.0, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), only 
lookup strings in configuration are expanded recursively; in any other usage, 
only the top-level lookup is resolved, and any nested lookups are not 
resolved.</p>
-<p>The property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
&#x2018;log4j2.enableJndiLookup&#x2019;, &#x2018;log4j2.enableJndiJms&#x2019;, 
and &#x2018;log4j2.enableJndiContextSelector&#x2019;.</p>
-<p>JNDI functionality has been hardened in these versions: 2.3.2, 2.12.2, 
2.12.4 or 2.17.0: from these versions onwards, support for the LDAP protocol 
has been removed and only the JAVA protocol is supported in JNDI 
connections.</p></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more 
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>Independently discovered by Hideki Okamoto of Akamai Technologies, Guy 
Lederfein of Trend Micro Research working with Trend Micro&#x2019;s Zero Day 
Initiative, and another anonymous vulnerability 
researcher.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-
-<li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a></li>
-<li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3230";>LOG4J2-3230</a></li>
-</ul>
-<p><a name="CVE-2021-45046"></a><a 
name="cve-2021-45046"></a></p></section></section><section>
-<h2><a 
name="Fixed_in_Log4j_2.16.0_.28Java_8.29_and_Log4j_2.12.2_.28Java_7.29"></a><a 
name="log4j-2.16.0"></a> Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 
7)</h2>
-<p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>:
 Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code 
execution in certain non-default configurations</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>
 </th>
-<th> Remote Code Execution </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Severity          </td>
-<td> Critical </td></tr>
-<tr class="a">
-<td> Base CVSS Score   </td>
-<td> 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>It was found that the fix to address <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. 
When the logging configuration uses a non-default Pattern Layout with a Context 
Lookup (for example, $${ctx:loginId}), attackers with control over Thread 
Context Map (MDC) input data can craft malicious input data using a JNDI Lookup 
pattern, resulting in an info [...]
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>Log4j 1.x is not impacted by this vulnerability.</p></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Implement one of the following mitigation techniques:</p>
-<ul>
-
-<li>Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.0 (for 
Java 8 and later).</li>
-<li>Otherwise, in any release other than 2.16.0, you may remove the JndiLookup 
class from the classpath: zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
-</ul>
-<p>Users are advised not to enable JNDI in Log4j 2.16.0, since it still allows 
LDAP connections. If the JMS Appender is required, use one of these versions: 
2.3.2, 2.12.2, 2.12.4 or 2.17.0: from these versions onwards, only the JAVA 
protocol is supported in JNDI connections.</p>
-<p>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.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject 
affected by this vulnerability. Other projects like Log4net and Log4cxx are not 
impacted by this.</p></section></section><section>
-<h3><a name="History"></a>History</h3>
-<p><b>Severity is now Critical</b></p>
-<p>The original severity of this CVE was rated as Moderate; since this CVE was 
published security experts found additional exploits against the Log4j 2.15.0 
release, that could lead to information leaks, RCE (remote code execution) and 
LCE (local code execution) attacks.</p>
-<p>Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 
9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).</p>
-<p>The title of this CVE was changed from mentioning Denial of Service attacks 
to mentioning Remote Code Execution attacks.</p>
-<p>Only Pattern Layouts with a Context Lookup (for example, $${ctx:loginId}) 
are vulnerable to this. This page previously incorrectly mentioned that Thread 
Context Map pattern (%X, %mdc, or %MDC) in the layout would also allow this 
vulnerability.</p>
-<p>While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP 
lookups to localhost by default, there are ways to bypass this and users should 
not rely on this.</p>
-<p><b>Older (discredited) mitigation measures</b></p>
-<p>This page previously mentioned other mitigation measures, but we discovered 
that these measures only limit exposure while leaving some attack vectors 
open.</p>
-<p>Other insufficient mitigation measures are: setting system property 
log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS 
to true for releases &gt;= 2.10, or modifying the logging configuration to 
disable message lookups with %m{nolookups}, %msg{nolookups} or 
%message{nolookups} for releases &gt;= 2.7 and &lt;= 2.14.1.</p>
-<p>The reason these measures are insufficient is that, in addition to the 
Thread Context attack vector mentioned above, there are still code paths in 
Log4j where message lookups could occur: known examples are applications that 
use Logger.printf(&quot;%s&quot;, userInput), or applications that use a custom 
message factory, where the resulting messages do not implement 
StringBuilderFormattable. There may be other attack vectors.</p>
-<p>The safest thing to do is to upgrade Log4j to a safe version, or remove the 
JndiLookup class from the log4j-core jar.</p></section><section>
-<h3><a name="Release_Details"></a>Release Details</h3>
-<p>From version 2.16.0 (for Java 8), the message lookups feature has been 
completely removed. Lookups in configuration still work. Furthermore, Log4j now 
disables access to JNDI by default. JNDI lookups in configuration now need to 
be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0, 
since it still allows LDAP connections. If the JMS Appender is required, use 
one of these versions: 2.3.2, 2.12.2, 2.12.4 or 2.17.0: from these versions 
onwards, only the JAVA protoco [...]
-<p>From version 2.12.2 (for Java 7) and 2.3.2 (for Java 6), the message 
lookups feature has been completely removed. Lookups in configuration still 
work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups 
in configuration now need to be enabled explicitly. When enabled, JNDI will 
only support the JAVA protocol, support for the LDAP protocol has been 
removed.</p>
-<p>From version 2.17.0 (for Java 8), support for the LDAP protocol has been 
removed and only the JAVA protocol is supported in JNDI connections.</p>
-<p>From version 2.17.0 (for Java 8), 2.12.4 (for Java 7) and 2.3.2 (for Java 
6), the property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
&#x2018;log4j2.enableJndiLookup&#x2019;, &#x2018;log4j2.enableJndiJms&#x2019;, 
and &#x2018;log4j2.enableJndiContextSelector&#x2019;.</p></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more 
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issue was discovered by Kai Mindermann of iC Consult and separately by 
4ra1n.</p>
-<p>Additional vulnerability details discovered independently by Ash Fox of 
Google, Alvaro Mu&#xf1;oz and Tony Torralba from GitHub, Anthony Weems of 
Praetorian, and RyotaK (@ryotkak).</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-
-<li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a></li>
-<li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3221";>LOG4J2-3221</a></li>
-</ul>
-<p><a name="CVE-2021-44228"></a><a 
name="cve-2021-44228"></a></p></section></section><section>
-<h2><a name="Fixed_in_Log4j_2.15.0_.28Java_8.29"></a><a 
name="log4j-2.15.0"></a> Fixed in Log4j 2.15.0 (Java 8)</h2>
-<p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>:
  Apache Log4j2 JNDI features do not protect against attacker controlled LDAP 
and other JNDI related endpoints.</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
 </th>
-<th> Remote Code Execution </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Severity          </td>
-<td> Critical </td></tr>
-<tr class="a">
-<td> Base CVSS Score   </td>
-<td> 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-beta9 to 2.14.1 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>In Apache Log4j2 versions up to and including 2.14.1 (excluding security 
releases 2.3.2, 2.12.2 and 2.12.4), the JNDI features used in configurations, 
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.</p></section><section>
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>Log4j 1.x does not have Lookups so the risk is lower. Applications using 
Log4j 1.x are only vulnerable to this attack when they use JNDI in their 
configuration. A separate CVE (CVE-2021-4104) has been filed for this 
vulnerability. To mitigate: Audit your logging configuration to ensure it has 
no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not 
impacted by this vulnerability.</p></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Implement one of the following mitigation techniques:</p>
-<ul>
-
-<li>Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.0 (for 
Java 8 and later).</li>
-<li>Otherwise, in any release other than 2.16.0, you may remove the JndiLookup 
class from the classpath: zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
-</ul>
-<p>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.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject 
affected by this vulnerability. Other projects like Log4net and Log4cxx are not 
impacted by this.</p></section></section><section>
-<h3><a name="History"></a>History</h3><section>
-<h4><a name="Older_.28discredited.29_mitigation_measures"></a>Older 
(discredited) mitigation measures</h4>
-<p>This page previously mentioned other mitigation measures, but we discovered 
that these measures only limit exposure while leaving some attack vectors 
open.</p>
-<p>The 2.15.0 release was found to still be vulnerable when the configuration 
has a Pattern Layout containing a Context Lookup (for example, 
$${ctx:loginId}). When an attacker can control Thread Context values, they may 
inject a JNDI Lookup pattern, which will be evaluated and result in a JNDI 
connection. While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI 
connections to localhost by default, there are ways to bypass this and users 
should not rely on this.</p>
-<p>A new CVE (CVE-2021-45046, see above) was raised for this.</p>
-<p>Other insufficient mitigation measures are: setting system property 
log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS 
to true for releases &gt;= 2.10, or modifying the logging configuration to 
disable message lookups with %m{nolookups}, %msg{nolookups} or 
%message{nolookups} for releases &gt;= 2.7 and &lt;= 2.14.1.</p>
-<p>The reason these measures are insufficient is that, in addition to the 
Thread Context attack vector mentioned above, there are still code paths in 
Log4j where message lookups could occur: known examples are applications that 
use Logger.printf(&quot;%s&quot;, userInput), or applications that use a custom 
message factory, where the resulting messages do not implement 
StringBuilderFormattable. There may be other attack vectors.</p>
-<p>The safest thing to do is to upgrade Log4j to a safe version, or remove the 
JndiLookup class from the log4j-core jar.</p></section><section>
-<h4><a name="Release_Details"></a>Release Details</h4>
-<p>As of Log4j 2.15.0 the message lookups feature was disabled by default. 
Lookups in configuration still work. While Log4j 2.15.0 has an option to enable 
Lookups in this fashion, users are strongly discouraged from enabling it. A 
whitelisting mechanism was introduced for JNDI connections, allowing only 
localhost by default. The 2.15.0 release was found to have additional 
vulnerabilities and is not recommended.</p>
-<p>From version 2.16.0 (for Java 8), the message lookups feature has been 
completely removed. Lookups in configuration still work. Furthermore, Log4j now 
disables access to JNDI by default. JNDI lookups in configuration now need to 
be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0, 
since it still allows LDAP connections. If the JMS Appender is required, use 
one of these versions: 2.3.2, 2.12.2, 2.12.4 or 2.17.0: from these versions 
onwards, only the JAVA protoco [...]
-<p>From version 2.12.2 (for Java 7) and 2.3.2 (for Java 6), the message 
lookups feature has been completely removed. Lookups in configuration still 
work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups 
in configuration now need to be enabled explicitly. When enabled, JNDI will 
only support the JAVA protocol, support for the LDAP protocol has been 
removed.</p>
-<p>From version 2.17.0 (for Java 8), support for the LDAP protocol has been 
removed and only the JAVA protocol is supported in JNDI connections.</p>
-<p>From version 2.17.0 (for Java 8), 2.12.4 (for Java 7) and 2.3.2 (for Java 
6), the property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
&#x2018;log4j2.enableJndiLookup&#x2019;, &#x2018;log4j2.enableJndiJms&#x2019;, 
and 
&#x2018;log4j2.enableJndiContextSelector&#x2019;.</p></section></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more 
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issue was discovered by Chen Zhaojun of Alibaba Cloud Security 
Team.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-
-<li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3201";>https://issues.apache.org/jira/browse/LOG4J2-3201</a></li>
-<li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3198";>https://issues.apache.org/jira/browse/LOG4J2-3198</a>.</li>
-</ul></section></section><section>
-<h2><a 
name="Fixed_in_Log4j_2.13.2_.28Java_8.29_and_2.12.4_.28Java_7.29"></a><a 
name="log4j-2.13.2"></a> Fixed in Log4j 2.13.2 (Java 8) and 2.12.4 (Java 7)</h2>
-<p><a name="CVE-2020-9488"></a><a name="cve-2020-9488"></a> <a 
class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>:
  Improper validation of certificate with host mismatch in Apache Log4j SMTP 
appender.</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>
 </th>
-<th> </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Severity          </td>
-<td> Low </td></tr>
-<tr class="a">
-<td> CVSS Base Score   </td>
-<td> 3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-alpha1 to 2.13.1 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>Improper validation of certificate with host mismatch in Log4j2 SMTP 
appender. This could allow an SMTPS connection to be intercepted by a 
man-in-the-middle attack which could leak any log messages sent through that 
appender.</p>
-<p>The reported issue was caused by an error in SslConfiguration. Any element 
using SslConfiguration in the Log4j Configuration is also affected by this 
issue. This includes HttpAppender, SocketAppender, and SyslogAppender. Usages 
of SslConfiguration that are configured via system properties are not 
affected.</p></section><section>
-<h3><a name="Mitigation"></a>Mitigation</h3>
-<p>Users should upgrade to Apache Log4j 2.13.2 which fixed this issue in <a 
class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>https://issues.apache.org/jira/browse/LOG4J2-2819</a>
 by making SSL settings configurable for SMTPS mail sessions. As a workaround 
for previous releases, users can set the mail.smtp.ssl.checkserveridentity 
system property to true to enable SMTPS hostname verification for all SMTPS 
mail sessions.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issues was discovered by Peter St&#xf6;ckli.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-
-<li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a></li>
-<li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>LOG4J2-2819</a></li>
-</ul></section></section><section>
-<h2><a name="Fixed_in_Log4j_2.8.2_.28Java_7.29"></a><a name="log4j-2.8.2"></a> 
Fixed in Log4j 2.8.2 (Java 7)</h2>
-<p><a name="CVE-2017-5645"></a><a name="cve-2017-5645"></a> <a 
class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>:
 Apache Log4j socket receiver deserialization vulnerability.</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>
 </th>
-<th> </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Severity          </td>
-<td> Moderate </td></tr>
-<tr class="a">
-<td> CVSS Base Score   </td>
-<td> 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-alpha1 to 2.8.1 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>When using the TCP socket server or UDP socket server to receive serialized 
log events from another application, a specially crafted binary payload can be 
sent that, when deserialized, can execute arbitrary code.</p></section><section>
-<h3><a name="Mitigation"></a>Mitigation</h3>
-<p>Java 7 and above users should migrate to version 2.8.2 or avoid using the 
socket server classes. Java 6 users should avoid using the TCP or UDP socket 
server classes, or they can manually backport the <a class="externalLink" 
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>security fix 
commit</a> from 2.8.2.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issue was discovered by Marcio Almeida de Macedo of Red Team at 
Telstra</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-
-<li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a></li>
-<li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-1863";>LOG4J2-1863</a></li>
-<li><a class="externalLink" 
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>Security fix 
commit</a></li>
-</ul></section></section><section>
-<h2><a name="Summary_of_security_impact_levels_for_Apache_Log4j"></a><a 
name="Security_Impact_Levels"></a> Summary of security impact levels for Apache 
Log4j</h2>
-<p>The Apache Log4j Security Team rates the impact of each security flaw that 
affects Log4j. We&#x2019;ve chosen a rating scale quite similar to those used 
by other major vendors in order to be consistent. Basically the goal of the 
rating system is to answer the question &#x201c;How worried should I be about 
this vulnerability?&#x201d;.</p>
-<p>Note that the rating chosen for each flaw is the worst possible case across 
all architectures. To determine the exact impact of a particular vulnerability 
on your own systems you will still need to read the security advisories to find 
out more about the flaw.</p>
-<p>We use the following descriptions to decide on the impact rating to give 
each vulnerability:</p>
-<table border="0" class="table table-striped">
-<thead>
-
-<tr class="a">
-<th> Severity </th>
-<th> CVSS v3 Score Range </th></tr>
-</thead><tbody>
-
-<tr class="b">
-<td> Critical </td>
-<td> 9.0 - 10.0          </td></tr>
-<tr class="a">
-<td> High     </td>
-<td> 7.0 - 8.9           </td></tr>
-<tr class="b">
-<td> Moderate </td>
-<td> 4.0 - 6.9           </td></tr>
-<tr class="a">
-<td> Low      </td>
-<td> 0.1 - 3.9           </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Critical"></a>Critical</h3>
-<p>A vulnerability rated with a Critical impact is one which could potentially 
be exploited by a remote attacker to get Log4j to execute arbitrary code 
(either as the user the server is running as, or root). These are the sorts of 
vulnerabilities that could be exploited automatically by worms. Critical 
vulnerabilities score between 9.0 and 10.0 on the <a class="externalLink" 
href="https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator";>CVSS v3 
calculator</a>.</p></section><section>
-<h3><a name="High"></a>High</h3>
-<p>A vulnerability rated as High impact is one which could result in the 
compromise of data or availability of the server. For Log4j this includes 
issues that allow an easy remote denial of service (something that is out of 
proportion to the attack or with a lasting consequence), access to arbitrary 
files outside of the context root, or access to files that should be otherwise 
prevented by limits or authentication. High vulnerabilities score between 7.0 
and 8.9 on the <a class="externalL [...]
-<h3><a name="Moderate"></a>Moderate</h3>
-<p>A vulnerability is likely to be rated as Moderate if there is significant 
mitigation to make the issue less of an impact. This might be because the flaw 
does not affect likely configurations, or it is a configuration that 
isn&#x2019;t widely used. Moderate vulnerabilities score between 4.0 and 6.9 on 
the <a class="externalLink" 
href="https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator";>CVSS v3 
calculator</a>.</p></section><section>
-<h3><a name="Low"></a>Low</h3>
-<p>All other security flaws are classed as a Low impact. This rating is used 
for issues that are believed to be extremely hard to exploit, or where an 
exploit gives minimal consequences. Low vulnerabilities score between 0.1 and 
3.9 on the <a class="externalLink" 
href="https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator";>CVSS v3 
calculator</a>.</p></section></section>
-        </main>
+
+
+
+          <main id="bodyColumn"  class="span10" >
+              <!-- vim: set syn=markdown : -->
+              <!--
+               Licensed to the Apache Software Foundation (ASF) under one or 
more
+               contributor license agreements. See the NOTICE file distributed 
with
+               this work for additional information regarding copyright 
ownership.
+               The ASF licenses this file to You under the Apache License, 
Version 2.0
+               (the "License"); you may not use this file except in compliance 
with
+               the License. You may obtain a copy of the License at
+
+                       http://www.apache.org/licenses/LICENSE-2.0
+
+               Unless required by applicable law or agreed to in writing, 
software
+               distributed under the License is distributed on an "AS IS" 
BASIS,
+               WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
+               See the License for the specific language governing permissions 
and
+               limitations under the License.
+              -->
+              <h1>Apache Log4j Security Vulnerabilities</h1>
+              <p>This page lists all the security vulnerabilities fixed in 
released versions of Apache Log4j 2. Each vulnerability is given a <a 
href="#Security_Impact_Levels">security impact rating</a> by the <a 
class="externalLink" href="mailto:secur...@logging.apache.org";>Apache Logging 
security team</a>. please note that this rating may vary from platform to 
platform. We also list the versions of Apache Log4j the flaw is known to 
affect, and where a flaw has not been verified list th [...]
+              <p>Note: Vulnerabilities that are not Log4j vulnerabilities but 
have either been incorrectly reported against Log4j or where Log4j provides a 
workaround are listed at the end of this page.</p>
+              <p>Please note that <a class="externalLink" 
href="http://logging.apache.org/log4j/1.2/";>Log4j 1.x</a> has <a 
class="externalLink" 
href="https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces";>reached
 End of Life</a> and is no longer supported. Vulnerabilities reported after 
August 2015 against Log4j 1.x were not checked and will not be fixed. Users 
should upgrade to Log4j 2 to obtain security fixes.</p>
+              <p>Please note that binary patches are never provided. If you 
need to apply a source code patch, use the building instructions for the Apache 
Log4j version that you are using. For Log4j 2 this is BUILDING.md. This file 
can be found in the root subdirectory of a source distributive.</p>
+              <p>If you need help on building or configuring Log4j or other 
help on following the instructions to mitigate the known vulnerabilities listed 
here, please <a class="externalLink" 
href="mailto:log4j-user-subscr...@logging.apache.org";>subscribe to</a>, and 
send your questions to the public Log4j <a href="mail-lists.html">Users mailing 
list</a>.</p>
+              <p>If you have encountered an unlisted security vulnerability or 
other unexpected behaviour that has security impact, or if the descriptions 
here are incomplete, please report them privately to the <a 
class="externalLink" href="mailto:secur...@logging.apache.org";>Log4j Security 
Team</a>. Thank you.</p>
+              <p><a name="CVE-2021-44832"></a><a 
name="cve-2021-44832"></a></p><section>
+              <h2><a 
name="Fixed_in_Log4j_2.17.1_.28Java_8.29.2C_2.12.4_.28Java_7.29_and_2.3.2_.28Java_6.29"></a><a
 name="log4j-2.17.1"></a> Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 
2.3.2 (Java 6)</h2>
+              <p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>:
 Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls 
configuration.</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>
 </th>
+                      <th> Remote Code Execution </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Severity          </td>
+                  <td> Moderate </td></tr>
+              <tr class="a">
+                  <td> Base CVSS Score   </td>
+                  <td> 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H) </td></tr>
+              <tr class="b">
+                  <td> Versions Affected </td>
+                  <td> All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 
and 2.12.4 </td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Description"></a>Description</h3>
+              <p>Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding 
security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code 
execution (RCE) attack where an attacker with permission to modify the logging 
configuration file can construct a malicious configuration using a JDBC 
Appender with a data source referencing a JNDI URI which can execute remote 
code. This issue is fixed by limiting JNDI data source names to the java 
protocol in Log4j2 versions 2.17.1, 2.12.4,  [...]
+              <h3><a name="Mitigation"></a>Mitigation</h3><section>
+              <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+              <p>Log4j 1.x is not impacted by this 
vulnerability.</p></section><section>
+              <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+              <p>Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 
2.17.1 (for Java 8 and later).</p>
+              <p>In prior releases confirm that if the JDBC Appender is being 
used it is not configured to use any protocol other than Java.</p>
+              <p>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.</p>
+              <p>Also note that Apache Log4j is the only Logging Services 
subproject affected by this vulnerability. Other projects like Log4net and 
Log4cxx are not impacted by this.</p></section></section><section>
+              <h3><a name="Release_Details"></a>Release Details</h3>
+              <p>From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and 
Java 6), the JDBC Appender will use JndiManager and will require the 
log4j2.enableJndiJdbc system property to contain a value of true for JNDI to be 
enabled.</p>
+              <p>The property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
log4j2.enableJndiLookup, log4j2.enableJndiJms, and 
log4j2.enableJndiContextSelector.</p>
+              <p>JNDI functionality has been hardened in these versions: 
2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the 
LDAP protocol has been removed and only the JAVA protocol is supported in JNDI 
connections.</p></section><section>
+              <h3><a name="Work_in_progress"></a>Work in progress</h3>
+              <p>The Log4j team will continue to actively update this page as 
more information becomes known.</p></section><section>
+              <h3><a name="Credit"></a>Credit</h3>
+              <p>No credit is being awarded for this 
issue.</p></section><section>
+              <h3><a name="References"></a>References</h3>
+              <ul>
+
+                  <li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a></li>
+              </ul>
+              <p><a name="CVE-2021-45105"></a><a 
name="cve-2021-45046"></a></p></section></section><section>
+              <h2><a 
name="Fixed_in_Log4j_2.17.0_.28Java_8.29.2C_2.12.3_.28Java_7.29_and_2.3.1_.28Java_6.29"></a><a
 name="log4j-2.17.0"></a> Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 
2.3.1 (Java 6)</h2>
+              <p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>:
 Apache Log4j2 does not always protect from infinite recursion in lookup 
evaluation</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>
 </th>
+                      <th> Denial of Service </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Severity          </td>
+                  <td> Moderate </td></tr>
+              <tr class="a">
+                  <td> Base CVSS Score   </td>
+                  <td> 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) </td></tr>
+              <tr class="b">
+                  <td> Versions Affected </td>
+                  <td> All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3 
</td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Description"></a>Description</h3>
+              <p>Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 
2.12.3, did not protect from uncontrolled recursion from self-referential 
lookups. When the logging configuration uses a non-default Pattern Layout with 
a Context Lookup (for example, $${ctx:loginId}), attackers with control over 
Thread Context Map (MDC) input data can craft malicious input data that 
contains a recursive lookup, resulting in a StackOverflowError that will 
terminate the process. This is also know [...]
+              <h3><a name="Mitigation"></a>Mitigation</h3><section>
+              <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+              <p>Log4j 1.x is not impacted by this 
vulnerability.</p></section><section>
+              <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+              <p>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 
2.17.0 (for Java 8 and later).</p>
+              <p>Alternatively, this infinite recursion issue can be mitigated 
in configuration:</p>
+              <ul>
+
+                  <li>In PatternLayout in the logging configuration, replace 
Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map 
patterns (%X, %mdc, or %MDC).</li>
+                  <li>Otherwise, in the 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.</li>
+              </ul>
+              <p>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.</p>
+              <p>Also note that Apache Log4j is the only Logging Services 
subproject affected by this vulnerability. Other projects like Log4net and 
Log4cxx are not impacted by this.</p></section></section><section>
+              <h3><a name="Release_Details"></a>Release Details</h3>
+              <p>From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and 
Java 6), only lookup strings in configuration are expanded recursively; in any 
other usage, only the top-level lookup is resolved, and any nested lookups are 
not resolved.</p>
+              <p>The property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
&#x2018;log4j2.enableJndiLookup&#x2019;, &#x2018;log4j2.enableJndiJms&#x2019;, 
and &#x2018;log4j2.enableJndiContextSelector&#x2019;.</p>
+              <p>JNDI functionality has been hardened in these versions: 
2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the 
LDAP protocol has been removed and only the JAVA protocol is supported in JNDI 
connections.</p></section><section>
+              <h3><a name="Work_in_progress"></a>Work in progress</h3>
+              <p>The Log4j team will continue to actively update this page as 
more information becomes known.</p></section><section>
+              <h3><a name="Credit"></a>Credit</h3>
+              <p>Independently discovered by Hideki Okamoto of Akamai 
Technologies, Guy Lederfein of Trend Micro Research working with Trend 
Micro&#x2019;s Zero Day Initiative, and another anonymous vulnerability 
researcher.</p></section><section>
+              <h3><a name="References"></a>References</h3>
+              <ul>
+
+                  <li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a></li>
+                  <li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3230";>LOG4J2-3230</a></li>
+              </ul>
+              <p><a name="CVE-2021-45046"></a><a 
name="cve-2021-45046"></a></p></section></section><section>
+              <h2><a 
name="Fixed_in_Log4j_2.16.0_.28Java_8.29_and_Log4j_2.12.2_.28Java_7.29"></a><a 
name="log4j-2.16.0"></a> Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 
7)</h2>
+              <p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>:
 Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code 
execution in certain non-default configurations</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>
 </th>
+                      <th> Remote Code Execution </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Severity          </td>
+                  <td> Critical </td></tr>
+              <tr class="a">
+                  <td> Base CVSS Score   </td>
+                  <td> 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) </td></tr>
+              <tr class="b">
+                  <td> Versions Affected </td>
+                  <td> All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 
</td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Description"></a>Description</h3>
+              <p>It was found that the fix to address <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. 
When the logging configuration uses a non-default Pattern Layout with a Context 
Lookup (for example, $${ctx:loginId}), attackers with control over Thread 
Context Map (MDC) input data can craft malicious input data using a JNDI Lookup 
pattern, result [...]
+              <h3><a name="Mitigation"></a>Mitigation</h3><section>
+              <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+              <p>Log4j 1.x is not impacted by this 
vulnerability.</p></section><section>
+              <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+              <p>Implement one of the following mitigation techniques:</p>
+              <ul>
+
+                  <li>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 
7), or 2.17.0 (for Java 8 and later).</li>
+                  <li>Otherwise, in any release other than 2.16.0, you may 
remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
+              </ul>
+              <p>Users are advised not to enable JNDI in Log4j 2.16.0, since 
it still allows LDAP connections. If the JMS Appender is required, use one of 
these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, 
only the JAVA protocol is supported in JNDI connections.</p>
+              <p>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.</p>
+              <p>Also note that Apache Log4j is the only Logging Services 
subproject affected by this vulnerability. Other projects like Log4net and 
Log4cxx are not impacted by this.</p></section></section><section>
+              <h3><a name="History"></a>History</h3>
+              <p><b>Severity is now Critical</b></p>
+              <p>The original severity of this CVE was rated as Moderate; 
since this CVE was published security experts found additional exploits against 
the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote 
code execution) and LCE (local code execution) attacks.</p>
+              <p>Base CVSS Score changed from 3.7 
(AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0 
(AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).</p>
+              <p>The title of this CVE was changed from mentioning Denial of 
Service attacks to mentioning Remote Code Execution attacks.</p>
+              <p>Only Pattern Layouts with a Context Lookup (for example, 
$${ctx:loginId}) are vulnerable to this. This page previously incorrectly 
mentioned that Thread Context Map pattern (%X, %mdc, or %MDC) in the layout 
would also allow this vulnerability.</p>
+              <p>While Log4j 2.15.0 makes a best-effort attempt to restrict 
JNDI LDAP lookups to localhost by default, there are ways to bypass this and 
users should not rely on this.</p>
+              <p><b>Older (discredited) mitigation measures</b></p>
+              <p>This page previously mentioned other mitigation measures, but 
we discovered that these measures only limit exposure while leaving some attack 
vectors open.</p>
+              <p>Other insufficient mitigation measures are: setting system 
property log4j2.formatMsgNoLookups or environment variable 
LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases &gt;= 2.10, or modifying the 
logging configuration to disable message lookups with %m{nolookups}, 
%msg{nolookups} or %message{nolookups} for releases &gt;= 2.7 and &lt;= 
2.14.1.</p>
+              <p>The reason these measures are insufficient is that, in 
addition to the Thread Context attack vector mentioned above, there are still 
code paths in Log4j where message lookups could occur: known examples are 
applications that use Logger.printf(&quot;%s&quot;, userInput), or applications 
that use a custom message factory, where the resulting messages do not 
implement StringBuilderFormattable. There may be other attack vectors.</p>
+              <p>The safest thing to do is to upgrade Log4j to a safe version, 
or remove the JndiLookup class from the log4j-core jar.</p></section><section>
+              <h3><a name="Release_Details"></a>Release Details</h3>
+              <p>From version 2.16.0 (for Java 8), the message lookups feature 
has been completely removed. Lookups in configuration still work. Furthermore, 
Log4j now disables access to JNDI by default. JNDI lookups in configuration now 
need to be enabled explicitly. Users are advised not to enable JNDI in Log4j 
2.16.0, since it still allows LDAP connections. If the JMS Appender is 
required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from 
these versions onwards, only th [...]
+              <p>From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), the 
message lookups feature has been completely removed. Lookups in configuration 
still work. Furthermore, Log4j now disables access to JNDI by default. JNDI 
lookups in configuration now need to be enabled explicitly. When enabled, JNDI 
will only support the JAVA protocol, support for the LDAP protocol has been 
removed.</p>
+              <p>From version 2.17.0 (for Java 8), support for the LDAP 
protocol has been removed and only the JAVA protocol is supported in JNDI 
connections.</p>
+              <p>From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and 
2.3.1 (for Java 6), the property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
&#x2018;log4j2.enableJndiLookup&#x2019;, &#x2018;log4j2.enableJndiJms&#x2019;, 
and &#x2018;log4j2.enableJndiContextSelector&#x2019;.</p></section><section>
+              <h3><a name="Work_in_progress"></a>Work in progress</h3>
+              <p>The Log4j team will continue to actively update this page as 
more information becomes known.</p></section><section>
+              <h3><a name="Credit"></a>Credit</h3>
+              <p>This issue was discovered by Kai Mindermann of iC Consult and 
separately by 4ra1n.</p>
+              <p>Additional vulnerability details discovered independently by 
Ash Fox of Google, Alvaro Mu&#xf1;oz and Tony Torralba from GitHub, Anthony 
Weems of Praetorian, and RyotaK (@ryotkak).</p></section><section>
+              <h3><a name="References"></a>References</h3>
+              <ul>
+
+                  <li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a></li>
+                  <li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3221";>LOG4J2-3221</a></li>
+              </ul>
+              <p><a name="CVE-2021-44228"></a><a 
name="cve-2021-44228"></a></p></section></section><section>
+              <h2><a name="Fixed_in_Log4j_2.15.0_.28Java_8.29"></a><a 
name="log4j-2.15.0"></a> Fixed in Log4j 2.15.0 (Java 8)</h2>
+              <p><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>:
  Apache Log4j2 JNDI features do not protect against attacker controlled LDAP 
and other JNDI related endpoints.</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
 </th>
+                      <th> Remote Code Execution </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Severity          </td>
+                  <td> Critical </td></tr>
+              <tr class="a">
+                  <td> Base CVSS Score   </td>
+                  <td> 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H 
</td></tr>
+              <tr class="b">
+                  <td> Versions Affected </td>
+                  <td> All versions from 2.0-beta9 to 2.14.1 </td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Description"></a>Description</h3>
+              <p>In Apache Log4j2 versions up to and including 2.14.1 
(excluding security releases 2.3.1, 2.12.2 and 2.12.3), the JNDI features used 
in configurations, 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.</p></section><section>
+              <h3><a name="Mitigation"></a>Mitigation</h3><section>
+              <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+              <p>Log4j 1.x does not have Lookups so the risk is lower. 
Applications using Log4j 1.x are only vulnerable to this attack when they use 
JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for 
this vulnerability. To mitigate: Audit your logging configuration to ensure it 
has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are 
not impacted by this vulnerability.</p></section><section>
+              <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+              <p>Implement one of the following mitigation techniques:</p>
+              <ul>
+
+                  <li>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 
7), or 2.17.0 (for Java 8 and later).</li>
+                  <li>Otherwise, in any release other than 2.16.0, you may 
remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
+              </ul>
+              <p>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.</p>
+              <p>Also note that Apache Log4j is the only Logging Services 
subproject affected by this vulnerability. Other projects like Log4net and 
Log4cxx are not impacted by this.</p></section></section><section>
+              <h3><a name="History"></a>History</h3><section>
+              <h4><a 
name="Older_.28discredited.29_mitigation_measures"></a>Older (discredited) 
mitigation measures</h4>
+              <p>This page previously mentioned other mitigation measures, but 
we discovered that these measures only limit exposure while leaving some attack 
vectors open.</p>
+              <p>The 2.15.0 release was found to still be vulnerable when the 
configuration has a Pattern Layout containing a Context Lookup (for example, 
$${ctx:loginId}). When an attacker can control Thread Context values, they may 
inject a JNDI Lookup pattern, which will be evaluated and result in a JNDI 
connection. While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI 
connections to localhost by default, there are ways to bypass this and users 
should not rely on this.</p>
+              <p>A new CVE (CVE-2021-45046, see above) was raised for this.</p>
+              <p>Other insufficient mitigation measures are: setting system 
property log4j2.formatMsgNoLookups or environment variable 
LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases &gt;= 2.10, or modifying the 
logging configuration to disable message lookups with %m{nolookups}, 
%msg{nolookups} or %message{nolookups} for releases &gt;= 2.7 and &lt;= 
2.14.1.</p>
+              <p>The reason these measures are insufficient is that, in 
addition to the Thread Context attack vector mentioned above, there are still 
code paths in Log4j where message lookups could occur: known examples are 
applications that use Logger.printf(&quot;%s&quot;, userInput), or applications 
that use a custom message factory, where the resulting messages do not 
implement StringBuilderFormattable. There may be other attack vectors.</p>
+              <p>The safest thing to do is to upgrade Log4j to a safe version, 
or remove the JndiLookup class from the log4j-core jar.</p></section><section>
+              <h4><a name="Release_Details"></a>Release Details</h4>
+              <p>As of Log4j 2.15.0 the message lookups feature was disabled 
by default. Lookups in configuration still work. While Log4j 2.15.0 has an 
option to enable Lookups in this fashion, users are strongly discouraged from 
enabling it. A whitelisting mechanism was introduced for JNDI connections, 
allowing only localhost by default. The 2.15.0 release was found to have 
additional vulnerabilities and is not recommended.</p>
+              <p>From version 2.16.0 (for Java 8), the message lookups feature 
has been completely removed. Lookups in configuration still work. Furthermore, 
Log4j now disables access to JNDI by default. JNDI lookups in configuration now 
need to be enabled explicitly. Users are advised not to enable JNDI in Log4j 
2.16.0, since it still allows LDAP connections. If the JMS Appender is 
required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from 
these versions onwards, only th [...]
+              <p>From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), the 
message lookups feature has been completely removed. Lookups in configuration 
still work. Furthermore, Log4j now disables access to JNDI by default. JNDI 
lookups in configuration now need to be enabled explicitly. When enabled, JNDI 
will only support the JAVA protocol, support for the LDAP protocol has been 
removed.</p>
+              <p>From version 2.17.0 (for Java 8), support for the LDAP 
protocol has been removed and only the JAVA protocol is supported in JNDI 
connections.</p>
+              <p>From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and 
2.3.1 (for Java 6), the property to enable JNDI has been renamed from 
&#x2018;log4j2.enableJndi&#x2019; to three separate properties: 
&#x2018;log4j2.enableJndiLookup&#x2019;, &#x2018;log4j2.enableJndiJms&#x2019;, 
and 
&#x2018;log4j2.enableJndiContextSelector&#x2019;.</p></section></section><section>
+              <h3><a name="Work_in_progress"></a>Work in progress</h3>
+              <p>The Log4j team will continue to actively update this page as 
more information becomes known.</p></section><section>
+              <h3><a name="Credit"></a>Credit</h3>
+              <p>This issue was discovered by Chen Zhaojun of Alibaba Cloud 
Security Team.</p></section><section>
+              <h3><a name="References"></a>References</h3>
+              <ul>
+
+                  <li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3201";>https://issues.apache.org/jira/browse/LOG4J2-3201</a></li>
+                  <li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-3198";>https://issues.apache.org/jira/browse/LOG4J2-3198</a>.</li>
+              </ul></section></section><section>
+              <h2><a 
name="Fixed_in_Log4j_2.13.2_.28Java_8.29_and_2.12.3_.28Java_7.29"></a><a 
name="log4j-2.13.2"></a> Fixed in Log4j 2.13.2 (Java 8) and 2.12.3 (Java 7)</h2>
+              <p><a name="CVE-2020-9488"></a><a name="cve-2020-9488"></a> <a 
class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>:
  Improper validation of certificate with host mismatch in Apache Log4j SMTP 
appender.</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>
 </th>
+                      <th> </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Severity          </td>
+                  <td> Low </td></tr>
+              <tr class="a">
+                  <td> CVSS Base Score   </td>
+                  <td> 3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N 
</td></tr>
+              <tr class="b">
+                  <td> Versions Affected </td>
+                  <td> All versions from 2.0-alpha1 to 2.13.1 </td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Description"></a>Description</h3>
+              <p>Improper validation of certificate with host mismatch in 
Log4j2 SMTP appender. This could allow an SMTPS connection to be intercepted by 
a man-in-the-middle attack which could leak any log messages sent through that 
appender.</p>
+              <p>The reported issue was caused by an error in 
SslConfiguration. Any element using SslConfiguration in the Log4j Configuration 
is also affected by this issue. This includes HttpAppender, SocketAppender, and 
SyslogAppender. Usages of SslConfiguration that are configured via system 
properties are not affected.</p></section><section>
+              <h3><a name="Mitigation"></a>Mitigation</h3>
+              <p>Users should upgrade to Apache Log4j 2.13.2 which fixed this 
issue in <a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>https://issues.apache.org/jira/browse/LOG4J2-2819</a>
 by making SSL settings configurable for SMTPS mail sessions. As a workaround 
for previous releases, users can set the mail.smtp.ssl.checkserveridentity 
system property to true to enable SMTPS hostname verification for all SMTPS 
mail sessions.</p></section><section>
+              <h3><a name="Credit"></a>Credit</h3>
+              <p>This issues was discovered by Peter 
St&#xf6;ckli.</p></section><section>
+              <h3><a name="References"></a>References</h3>
+              <ul>
+
+                  <li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a></li>
+                  <li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>LOG4J2-2819</a></li>
+              </ul></section></section><section>
+              <h2><a name="Fixed_in_Log4j_2.8.2_.28Java_7.29"></a><a 
name="log4j-2.8.2"></a> Fixed in Log4j 2.8.2 (Java 7)</h2>
+              <p><a name="CVE-2017-5645"></a><a name="cve-2017-5645"></a> <a 
class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>:
 Apache Log4j socket receiver deserialization vulnerability.</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th> <a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>
 </th>
+                      <th> </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Severity          </td>
+                  <td> Moderate </td></tr>
+              <tr class="a">
+                  <td> CVSS Base Score   </td>
+                  <td> 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) </td></tr>
+              <tr class="b">
+                  <td> Versions Affected </td>
+                  <td> All versions from 2.0-alpha1 to 2.8.1 </td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Description"></a>Description</h3>
+              <p>When using the TCP socket server or UDP socket server to 
receive serialized log events from another application, a specially crafted 
binary payload can be sent that, when deserialized, can execute arbitrary 
code.</p></section><section>
+              <h3><a name="Mitigation"></a>Mitigation</h3>
+              <p>Java 7 and above users should migrate to version 2.8.2 or 
avoid using the socket server classes. Java 6 users should avoid using the TCP 
or UDP socket server classes, or they can manually backport the <a 
class="externalLink" 
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>security fix 
commit</a> from 2.8.2.</p></section><section>
+              <h3><a name="Credit"></a>Credit</h3>
+              <p>This issue was discovered by Marcio Almeida de Macedo of Red 
Team at Telstra</p></section><section>
+              <h3><a name="References"></a>References</h3>
+              <ul>
+
+                  <li><a class="externalLink" 
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a></li>
+                  <li><a class="externalLink" 
href="https://issues.apache.org/jira/browse/LOG4J2-1863";>LOG4J2-1863</a></li>
+                  <li><a class="externalLink" 
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>Security fix 
commit</a></li>
+              </ul></section></section><section>
+              <h2><a 
name="Summary_of_security_impact_levels_for_Apache_Log4j"></a><a 
name="Security_Impact_Levels"></a> Summary of security impact levels for Apache 
Log4j</h2>
+              <p>The Apache Log4j Security Team rates the impact of each 
security flaw that affects Log4j. We&#x2019;ve chosen a rating scale quite 
similar to those used by other major vendors in order to be consistent. 
Basically the goal of the rating system is to answer the question &#x201c;How 
worried should I be about this vulnerability?&#x201d;.</p>
+              <p>Note that the rating chosen for each flaw is the worst 
possible case across all architectures. To determine the exact impact of a 
particular vulnerability on your own systems you will still need to read the 
security advisories to find out more about the flaw.</p>
+              <p>We use the following descriptions to decide on the impact 
rating to give each vulnerability:</p>
+              <table border="0" class="table table-striped">
+                  <thead>
+
+                  <tr class="a">
+                      <th> Severity </th>
+                      <th> CVSS v3 Score Range </th></tr>
+                  </thead><tbody>
+
+              <tr class="b">
+                  <td> Critical </td>
+                  <td> 9.0 - 10.0          </td></tr>
+              <tr class="a">
+                  <td> High     </td>
+                  <td> 7.0 - 8.9           </td></tr>
+              <tr class="b">
+                  <td> Moderate </td>
+                  <td> 4.0 - 6.9           </td></tr>
+              <tr class="a">
+                  <td> Low      </td>
+                  <td> 0.1 - 3.9           </td></tr>
+              </tbody>
+              </table><section>
+              <h3><a name="Critical"></a>Critical</h3>
+              <p>A vulnerability rated with a Critical impact is one which 
could potentially be exploited by a remote attacker to get Log4j to execute 
arbitrary code (either as the user the server is running as, or root). These 
are the sorts of vulnerabilities that could be exploited automatically by 
worms. Critical vulnerabilities score between 9.0 and 10.0 on the <a 
class="externalLink" 
href="https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator";>CVSS v3 
calculator</a>.</p></section><section>
+              <h3><a name="High"></a>High</h3>
+              <p>A vulnerability rated as High impact is one which could 
result in the compromise of data or availability of the server. For Log4j this 
includes issues that allow an easy remote denial of service (something that is 
out of proportion to the attack or with a lasting consequence), access to 
arbitrary files outside of the context root, or access to files that should be 
otherwise prevented by limits or authentication. High vulnerabilities score 
between 7.0 and 8.9 on the <a cl [...]
+              <h3><a name="Moderate"></a>Moderate</h3>
+              <p>A vulnerability is likely to be rated as Moderate if there is 
significant mitigation to make the issue less of an impact. This might be 
because the flaw does not affect likely configurations, or it is a 
configuration that isn&#x2019;t widely used. Moderate vulnerabilities score 
between 4.0 and 6.9 on the <a class="externalLink" 
href="https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator";>CVSS v3 
calculator</a>.</p></section><section>
+              <h3><a name="Low"></a>Low</h3>
+              <p>All other security flaws are classed as a Low impact. This 
rating is used for issues that are believed to be extremely hard to exploit, or 
where an exploit gives minimal consequences. Low vulnerabilities score between 
0.1 and 3.9 on the <a class="externalLink" 
href="https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator";>CVSS v3 
calculator</a>.</p></section></section>
+          </main>
+
+
+
+
+
+
+
+
+
       </div>
     </div>
     <hr/>

Reply via email to