This is an automated email from the ASF dual-hosted git repository.
vy pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/logging-site.git
The following commit(s) were added to refs/heads/main by this push:
new 46b4f97c Improve `security.adoc` formatting
46b4f97c is described below
commit 46b4f97c43a29ec4587bc80e4d1565593e1c12b2
Author: Volkan Yazıcı <[email protected]>
AuthorDate: Tue Apr 23 10:34:30 2024 +0200
Improve `security.adoc` formatting
---
_threat-model-common.adoc | 20 ++-
_threat-model-log4j.adoc | 42 ++++--
security.adoc => _vulnerabilities.adoc | 53 +------
security.adoc | 260 +--------------------------------
4 files changed, 44 insertions(+), 331 deletions(-)
diff --git a/_threat-model-common.adoc b/_threat-model-common.adoc
index f7bf1c8a..1e08f2f5 100644
--- a/_threat-model-common.adoc
+++ b/_threat-model-common.adoc
@@ -15,15 +15,20 @@
limitations under the License.
////
-.Common threat model
-[%collapsible]
-====
-Code signing::
+[#threat-common]
+=== Common threat model
+
+Below we share the threat model shared by all Logging Services projects.
+
+[#threat-common-code-signing]
+==== Code signing
+
All Logging Services software release distributions are signed using GPG using
a key from the Logging Services PMC
https://downloads.apache.org/logging/KEYS[KEYS file].
Information on how to verify releases signatures are explained further in
xref:download.adoc[the Download page].
Thus, GPG signatures should be validated in your build process.
-Configuration sources::
+[#threat-common-config-sources]
+==== Configuration sources
All configuration sources to an application must be trusted by the programmer.
When loading a configuration file from disk (especially when a monitor
interval is configured to reload the file periodically), the location of the
configuration file must be kept safe from unauthorized modifications.
Similarly, when loading a configuration file over the network such as through
HTTP, this should be configured to use TLS or a secure connection in general
with strong authentication guarantees.
@@ -32,7 +37,8 @@ When configurations are modified through JMX, the JMX server
should be safely co
When configurations are provided through JNDI, these should only use the
`java` scheme for sharing configurations in a Java EE or Jakarta EE application
service.
JNDI-sourced configurations should not use other JNDI providers such as LDAP,
DNS, or RMI, as all these providers are difficult to properly secure.
-Java Object Serialization Stream Protocol::
+[#threat-common-java-serialization]
+==== Java Object Serialization Stream Protocol
+
https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html[Java
Object Serialization Stream Protocol] should not be used to deserialize data
from untrusted sources.
See
https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data[the
related OWASP guide] for details.
-====
diff --git a/_threat-model-log4j.adoc b/_threat-model-log4j.adoc
index 376b292a..08a123b9 100644
--- a/_threat-model-log4j.adoc
+++ b/_threat-model-log4j.adoc
@@ -15,22 +15,23 @@
limitations under the License.
////
-.Log4j threat model
-[%collapsible]
-====
-Configuration inputs and the classpath are expected to be controlled by the
programmer.
-Configurations have the ability to execute arbitrary code.
-While specific plugins (such as a JNDI lookup) may use constraint validators
or conditionals to require additional settings to opt in to functionality, this
is not universally required by custom plugins.
-Specific security considerations involved in our threat model are detailed
below.
-
-Parameterized logging::
+[#threat-log4j]
+=== Log4j threat model
+
+Below we share the threat model specific to link:/log4j[Log4j].
+
+[#threat-log4j-parametrized-logging]
+==== Parameterized logging
+
When using a log message containing template parameters like `{}`, only the
format string is evaluated for parameters to be substituted.
The message parameters themselves are not evaluated for parameters; they are
only included in the format string corresponding to their template position.
The conversion of message parameters into a string is done on-demand depending
on the layout being used.
When structure-preserving transformations of log message data are required,
the `Message` API should be used for logging structured data combined with a
structured layout (e.g., `JsonTemplateLayout`).
Format strings should be compile-time constants, and under no circumstances
should format strings be built using user-controlled input data.
-Unstructured logging::
+[#threat-log4j-unstructured-logging]
+==== Unstructured logging
+
When using an unstructured layout such as `PatternLayout`, no guarantees can
be made about the output format.
This layout is mainly useful for development purposes and should not be relied
on in production applications.
For example, if a log message contains new lines, these are not escaped or
encoded specially unless the configured pattern uses the
`%encode\{pattern}\{CRLF}` wrapper pattern converter (which will encode a
carriage return as the string `\r` and a line feed as the string `\n`) or some
other `%encode` option.
@@ -40,31 +41,40 @@ As such, when using unstructured layouts, no
user-controlled input should be inc
It is strongly recommended that a structured layout (e.g.,
`JsonTemplateLayout`) is used instead for these situations.
Note that `StrLookup` plugins (those referenced by `${...}` templates in
configuration files) that contain user-provided input should not be referenced
by layouts.
-Structured logging::
+[#threat-log4j-structured-logging]
+==== Structured logging
+
When using a structured layout (most layouts besides pattern layout), log
messages are encoded according to various output formats.
These safely encode the various fields included in a log message.
For example, the `JsonTemplateLayout` can be configured to output log messages
in various JSON structures where all log data is properly encoded into safely
parseable JSON.
This is the recommended mode of operation for use with log parsing and log
collection tools that rely on log files or arbitrary output streams.
-Java Security Manager::
+[#threat-log4j-java-security-manager]
+==== Java Security Manager
+
Log4j 3 no longer supports running in or using a custom `SecurityManager`.
This Java feature has been deprecated for removal in Java 21.
Log4j 2 includes partial support for running with a Security Manager.
-Log masking::
+[#threat-log4j-log-masking]
+==== Log masking
+
Log4j, like any other generic logging library, cannot generically support log
masking of sensitive data.
While custom plugins may be developed to attempt to mask various regular
expressions (such as a string that looks like a credit card number), the
general problem of log masking is equivalent to the halting problem in computer
science where sensitive data can always be obfuscated in such a way as to avoid
detection by log masking.
As such, it is the responsibility of the developer to properly demarcate
sensitive data such that it can be consistently masked by log masking plugins.
This sort of use case should make use of the `Message` API for better control
over the output of such data.
-Availability::
+[#threat-log4j-availability]
+==== Availability
+
Log4j goes to great lengths to minimize performance overhead along with
options for minimizing latency or maximizing throughput.
However, we cannot guarantee availability of the application if the appenders
cannot keep up with the logs being written.
Synchronous logging can cause applications to block and wait for a log message
to be written.
Asynchronous logging can also cause applications to block and wait depending
on the wait strategy and queue full policy configured.
Configuring too large or too many buffers in an application can also result in
out of memory errors.
-Compressing logs::
+[#threat-log4j-compressing-logs]
+==== Compressing logs
+
If log compression is used along with custom encryption where logs contain
user-controlled input, then this can lead to a
https://en.wikipedia.org/wiki/CRIME[CRIME attack] style vulnerability where a
chosen-plaintext attack is combined with information leakage caused by how the
compression algorithm handles different inputs.
The simplest way to avoid this problem is to never combine compression with
encryption when encoding user-controlled input.
-====
diff --git a/security.adoc b/_vulnerabilities.adoc
similarity index 83%
copy from security.adoc
copy to _vulnerabilities.adoc
index 6cd3dbab..7fb02b69 100644
--- a/security.adoc
+++ b/_vulnerabilities.adoc
@@ -15,57 +15,6 @@
limitations under the License.
////
-:cve-url-prefix: https://nvd.nist.gov/vuln/detail
-
-= Security
-
-The Logging Services Security Team takes security seriously.
-This allows our users to place their trust in Log4j for protecting their
mission-critical data.
-In this page we will help you find guidance on security-related issues and
access to known vulnerabilities.
-
-include::_log4j1-eol.adoc[]
-
-[#support]
-== Getting support
-
-If you need help on building or configuring Logging Services projects or other
help on following the instructions to mitigate the known vulnerabilities listed
here, please use our xref:support.adoc#discussions[user support channels].
-
-[TIP]
-====
-If you need to apply a source code patch, use the building instructions for
the project version that you are using.
-These instructions can be found in `BUILDING.adoc`, `BUILDING.md`, etc. files
distributed with the sources.
-====
-
-[#reporting]
-== Reporting vulnerabilities
-
-If you have encountered an unlisted security vulnerability or other unexpected
behaviour that has a security impact, or if the descriptions here are
incomplete, please report them **privately** to
mailto:[email protected][the Logging Services Security Team].
-
-[WARNING]
-====
-The threat model that Logging Services uses considers configuration files as
safe input controlled by the programmer; **potential vulnerabilities that
require the ability to modify a configuration are not considered
vulnerabilities** as the required access to do so implies the attacker can
execute arbitrary code.
-====
-
-include::_threat-model-common.adoc[]
-
-include::_threat-model-log4j.adoc[]
-
-[#policy]
-== Vulnerability handling policy
-
-The Logging Services Security Team follows the
https://www.apache.org/security/committers.html[ASF Project Security] guide for
handling security vulnerabilities.
-
-Reported security vulnerabilities are subject to voting (by means of
https://logging.apache.org/guidelines.html[_lazy approval_], preferably) in the
private mailto:[email protected][security mailing list] before
creating a CVE and populating its associated content.
-This procedure involves only the creation of CVEs and blocks neither
(vulnerability) fixes, nor releases.
-
-[#vdr]
-== Vulnerability Disclosure Report (VDR)
-
-include::_sbom.adoc[]
-
-[#vulnerabilities]
-== Known vulnerabilities
-
The Logging Services Security Team believes that accuracy, completeness and
availability of security information is essential for our users.
We choose to pool all information on this one page, allowing easy searching
for security vulnerabilities over a range of criteria.
@@ -319,4 +268,4 @@ This issue was discovered by Marcio Almeida de Macedo of
Red Team at Telstra.
- {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645]
- https://issues.apache.org/jira/browse/LOG4J2-1863[LOG4J2-1863]
-- https://github.com/apache/logging-log4j2/commit/5dcc192[Security fix commit]
+- https://github.com/apache/logging-log4j2/commit/5dcc192[Security fix commit]
\ No newline at end of file
diff --git a/security.adoc b/security.adoc
index 6cd3dbab..b0127485 100644
--- a/security.adoc
+++ b/security.adoc
@@ -41,9 +41,10 @@ These instructions can be found in `BUILDING.adoc`,
`BUILDING.md`, etc. files di
If you have encountered an unlisted security vulnerability or other unexpected
behaviour that has a security impact, or if the descriptions here are
incomplete, please report them **privately** to
mailto:[email protected][the Logging Services Security Team].
-[WARNING]
+[IMPORTANT]
====
-The threat model that Logging Services uses considers configuration files as
safe input controlled by the programmer; **potential vulnerabilities that
require the ability to modify a configuration are not considered
vulnerabilities** as the required access to do so implies the attacker can
execute arbitrary code.
+We urge you to **carefully read the threat model** detailed in following
sections before submitting a report.
+It guides users on certain safety instructions while using Logging Services
software and elaborates on what counts as an unexpected behaviour that has a
security impact.
====
include::_threat-model-common.adoc[]
@@ -66,257 +67,4 @@ include::_sbom.adoc[]
[#vulnerabilities]
== Known vulnerabilities
-The Logging Services Security Team believes that accuracy, completeness and
availability of security information is essential for our users.
-We choose to pool all information on this one page, allowing easy searching
for security vulnerabilities over a range of criteria.
-
-[NOTE]
-====
-We adhere to
https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html[the Maven
version range syntax] while sharing versions of affected components.
-We only extend this mathematical notation with set union operator (i.e., `∪`)
to denote union of multiple ranges.
-====
-
-[#CVE-2021-44832]
-=== {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832]
-
-[cols="1h,5"]
-|===
-|Summary |JDBC appender is vulnerable to remote code execution in certain
configurations
-|CVSS 3.x Score & Vector |6.6 MEDIUM
(CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
-|Components affected |`log4j-core`
-|Versions affected |`[2.0-beta7, 2.3.2) ∪ [2.4, 2.12.4) ∪ [2.13.0, 2.17.1)`
-|Versions fixed |`2.3.2` (for Java 6), `2.12.4` (for Java 7), or `2.17.1` (for
Java 8 and later)
-|===
-
-[#CVE-2021-44832-description]
-==== Description
-
-An attacker with write access to the logging configuration 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.
-
-[#CVE-2021-44832-mitigation]
-==== Mitigation
-
-Upgrade to `2.3.2` (for Java 6), `2.12.4` (for Java 7), or `2.17.1` (for Java
8 and later).
-
-In prior releases confirm that if the JDBC Appender is being used it is not
configured to use any protocol other than `java`.
-
-[#CVE-2021-44832-references]
-==== References
-- {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832]
-
-[#CVE-2021-45105]
-=== {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105]
-
-[cols="1h,5"]
-|===
-|Summary |Infinite recursion in lookup evaluation
-|CVSS 3.x Score & Vector |5.9 MEDIUM
(CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
-|Components affected |`log4j-core`
-|Versions affected |`[2.0-alpha1, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)`
-|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0`
(for Java 8 and later)
-|===
-
-[#CVE-2021-45105-description]
-==== Description
-
-Log4j versions `2.0-alpha1` through `2.16.0` (excluding `2.3.1` and `2.12.3`),
did not protect from uncontrolled recursion that can be implemented using
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 (Denial-of-Service)_ attack.
-
-[#CVE-2021-45105-mitigation]
-==== Mitigation
-
-Upgrade to `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java
8 and later).
-
-Alternatively, this infinite recursion issue can be mitigated in configuration:
-
-* In PatternLayout in the logging configuration, replace Context Lookups like
`${ctx:loginId}` or `$${ctx:loginId}` with Thread Context Map patterns (`%X`,
`%mdc`, or `%MDC`).
-* 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.
-Note that this mitigation is insufficient in releases older than `2.12.2` (for
Java 7), and `2.16.0` (for Java 8 and later) as the issues fixed in those
releases will still be present.
-
-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.
-
-[#CVE-2021-45105-credits]
-==== Credits
-
-Independently discovered by Hideki Okamoto of Akamai Technologies, Guy
Lederfein of Trend Micro Research working with Trend Micro's Zero Day
Initiative, and another anonymous vulnerability researcher.
-
-[#CVE-2021-45105-references]
-==== References
-
-- {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105]
-- https://issues.apache.org/jira/browse/LOG4J2-3230[LOG4J2-3230]
-
-[#CVE-2021-45046]
-=== {cve-url-prefix}/CVE-2021-45046[CVE-2021-45046]
-
-[cols="1h,5"]
-|===
-|Summary |Thread Context Lookup is vulnerable to remote code execution in
certain configurations
-|CVSS 3.x Score & Vector |9.0 CRITICAL
(CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
-|Components affected |`log4j-core`
-|Versions affected |`[2.0-beta9, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)`
-|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0`
(for Java 8 and later)
-|===
-
-[#CVE-2021-45046-description]
-==== Description
-
-It was found that the fix to address <<CVE-2021-44228>> in Log4j `2.15.0` was
incomplete in certain non-default configurations.
-When the logging configuration uses a non-default Pattern Layout with a Thread
Context Lookup (for example, `$${ctx:loginId}`), attackers with control over
Thread Context Map (MDC) can craft malicious input data using a JNDI Lookup
pattern, resulting in an information leak and remote code execution in some
environments and local code execution in all environments.
-Remote code execution has been demonstrated on macOS, Fedora, Arch Linux, and
Alpine Linux.
-
-Note that this vulnerability is not limited to just the JNDI lookup.
-Any other Lookup could also be included in a Thread Context Map variable and
possibly have private details exposed to anyone with access to the logs.
-
-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.
-
-[#CVE-2021-45046-mitigation]
-==== Mitigation
-
-Upgrade to Log4j `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for
Java 8 and later).
-
-[#CVE-2021-45046-credits]
-==== Credits
-
-This issue was discovered by Kai Mindermann of iC Consult and separately by
4ra1n.
-
-Additional vulnerability details discovered independently by Ash Fox of
Google, Alvaro Muñoz and Tony Torralba from GitHub, Anthony Weems of
Praetorian, and RyotaK (@ryotkak).
-
-[#CVE-2021-45046-references]
-==== References
-
-- {cve-url-prefix}/CVE-2021-45046[CVE-2021-45046]
-- https://issues.apache.org/jira/browse/LOG4J2-3221[LOG4J2-3221]
-
-[#CVE-2021-44228]
-=== {cve-url-prefix}/CVE-2021-44228[CVE-2021-44228]
-
-[cols="1h,5"]
-|===
-|Summary |JNDI lookup can be exploited to execute arbitrary code loaded from
an LDAP server
-|CVSS 3.x Score & Vector |10.0 CRITICAL
(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
-|Components affected |`log4j-core`
-|Versions affected |`[2.0-beta9, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)`
-|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0`
(for Java 8 and later)
-|===
-
-[#CVE-2021-44228-description]
-==== Description
-
-In Log4j, 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.
-
-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.
-
-[#CVE-2021-44228-mitigation]
-==== Mitigation
-
-[#CVE-2021-44228-mitigation-log4j1]
-===== Log4j 1 mitigation
-
-include::_log4j1-eol.adoc[]
-
-Log4j 1 does not have Lookups, so the risk is lower.
-Applications using Log4j 1 are only vulnerable to this attack when they use
JNDI in their configuration.
-A separate CVE ({cve-url-prefix}/CVE-2021-4104[CVE-2021-4104]) has been filed
for this vulnerability.
-To mitigate, audit your logging configuration to ensure it has no
`JMSAppender` configured.
-Log4j 1 configurations without `JMSAppender` are not impacted by this
vulnerability.
-
-[#CVE-2021-44228-mitigation-log4j2]
-===== Log4j 2 mitigation
-
-Upgrade to Log4j `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for
Java 8 and later).
-
-[#CVE-2021-44228-credits]
-==== Credits
-
-This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
-
-[#CVE-2021-44228-references]
-==== References
-
-- {cve-url-prefix}/CVE-2021-44228[CVE-2021-44228]
-- https://issues.apache.org/jira/browse/LOG4J2-3198[LOG4J2-3198]
-- https://issues.apache.org/jira/browse/LOG4J2-3201[LOG4J2-3201]
-
-[#CVE-2020-9488]
-=== {cve-url-prefix}/CVE-2020-9488[CVE-2020-9488]
-
-[cols="1h,5"]
-|===
-|Summary |Improper validation of certificate with host mismatch in SMTP
appender
-|CVSS 3.x Score & Vector |3.7 LOW
(CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
-|Components affected |`log4j-core`
-|Versions affected |`[2.0-beta1, 2.12.3) ∪ [2.13.1, 2.13.2)`
-|Versions fixed |`2.12.3` (Java 7) and `2.13.2` (Java 8 and later)
-|===
-
-[#CVE-2020-9488-description]
-==== Description
-
-Improper validation of certificate with host mismatch in 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.
-
-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.
-
-[#CVE-2020-9488-mitigation]
-==== Mitigation
-
-Upgrade to `2.12.3` (Java 7) or `2.13.2` (Java 8 and later).
-
-Alternatively, users can set the `mail.smtp.ssl.checkserveridentity` system
property to `true` to enable SMTPS hostname verification for all SMTPS mail
sessions.
-
-[#CVE-2020-9488-credits]
-==== Credits
-
-This issue was discovered by Peter Stöckli.
-
-[#CVE-2020-9488-references]
-==== References
-
-- {cve-url-prefix}/CVE-2020-9488[CVE-2020-9488]
-- https://issues.apache.org/jira/browse/LOG4J2-2819[LOG4J2-2819]
-
-[#CVE-2017-5645]
-=== {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645]
-
-[cols="1h,5"]
-|===
-|Summary |TCP/UDP socket servers can be exploited to execute arbitrary code
-|CVSS 2.0 Score & Vector |7.5 HIGH (AV:N/AC:L/Au:N/C:P/I:P/A:P)
-|Components affected |`log4j-core`
-|Versions affected |`[2.0-alpha1, 2.8.2)`
-|Versions fixed |`2.8.2` (Java 7)
-|===
-
-[#CVE-2017-5645-description]
-==== Description
-
-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.
-
-[#CVE-2017-5645-mitigation]
-==== Mitigation
-
-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
https://github.com/apache/logging-log4j2/commit/5dcc192[the security fix
commit] from `2.8.2`.
-
-[#CVE-2017-5645-credits]
-==== Credits
-
-This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra.
-
-[#CVE-2017-5645-references]
-==== References
-
-- {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645]
-- https://issues.apache.org/jira/browse/LOG4J2-1863[LOG4J2-1863]
-- https://github.com/apache/logging-log4j2/commit/5dcc192[Security fix commit]
+include::_vulnerabilities.adoc[]
