This is an automated email from the ASF dual-hosted git repository.
github-actions[bot] pushed a commit to branch main-site-pro-out
in repository https://gitbox.apache.org/repos/asf/logging-site.git
The following commit(s) were added to refs/heads/main-site-pro-out by this push:
new 91929a3a Add website content generated from
`f4b1a4ff98374e75b1356882e85adf4111b6454c`
91929a3a is described below
commit 91929a3a737ca462063cd437ca9f5f4418259320
Author: ASF Logging Services RM <[email protected]>
AuthorDate: Mon May 4 20:55:18 2026 +0000
Add website content generated from
`f4b1a4ff98374e75b1356882e85adf4111b6454c`
---
cyclonedx/vdr.xml | 79 +++++++++++++++++++++++++++++++++++++-
security.html | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++++
security/faq.html | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
sitemap.xml | 42 ++++++++++-----------
4 files changed, 319 insertions(+), 22 deletions(-)
diff --git a/cyclonedx/vdr.xml b/cyclonedx/vdr.xml
index 9d92b634..f7f0739a 100644
--- a/cyclonedx/vdr.xml
+++ b/cyclonedx/vdr.xml
@@ -40,7 +40,7 @@
<bom xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns="http://cyclonedx.org/schema/bom/1.6";
xsi:schemaLocation="http://cyclonedx.org/schema/bom/1.6
https://cyclonedx.org/schema/bom-1.6.xsd";
- version="6"
+ version="7"
serialNumber="urn:uuid:dfa35519-9734-4259-bba1-3e825cf4be06">
<metadata>
@@ -1059,6 +1059,83 @@ Alternatively, users can set the
`mail.smtp.ssl.checkserveridentity` system prop
</affects>
</vulnerability>
+ <vulnerability>
+ <id>CVE-2018-1285</id>
+ <source>
+ <name>NVD</name>
+ <url>https://nvd.nist.gov/vuln/detail/CVE-2018-1285</url>
+ </source>
+ <references>
+ <reference>
+ <id>LOG4NET-575</id>
+ <source>
+ <name>Issue tracker</name>
+
<url>https://issues.apache.org/jira/browse/LOG4NET-575</url>
+ </source>
+ </reference>
+ <reference>
+ <id>Security fix commit</id>
+ <source>
+ <name>Source code repository</name>
+
<url>https://github.com/apache/logging-log4net/commit/3242db510c27e825af7164415402f5012df521a2</url>
+ </source>
+ </reference>
+ <reference>
+ <id>Pull request</id>
+ <source>
+ <name>Pull request that fixes the issue</name>
+
<url>https://github.com/apache/logging-log4net/pull/64</url>
+ </source>
+ </reference>
+ </references>
+ <ratings>
+ <rating>
+ <source>
+ <name>NVD</name>
+
<url><![CDATA[https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.1]]></url>
+ </source>
+ <score>9.8</score>
+ <severity>high</severity>
+ <method>CVSSv3</method>
+ <vector>AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</vector>
+ </rating>
+ </ratings>
+ <cwes>
+ <cwe>611</cwe>
+ </cwes>
+ <description><![CDATA[Apache log4net versions before 2.0.10 do not
disable XML external entities
+ when parsing log4net configuration files. This allows for XXE-based
attacks
+ in applications that accept attacker-controlled log4net configuration
files.]]></description>
+ <recommendation><![CDATA[Users are advised to upgrade to Apache
Log4net version `2.0.10`, which fixes this issue.]]></recommendation>
+ <analysis>
+ <state>not_affected</state>
+ <justification>protected_by_mitigating_control</justification>
+ <detail><![CDATA[According to the current threat model, this is no
longer considered a
+ vulnerability. The attack requires an attacker-controlled log4net
configuration
+ file, which is outside the scope of the threat model.]]></detail>
+ </analysis>
+ <created>2020-05-11T00:00:00Z</created>
+ <published>2020-05-11T00:00:00Z</published>
+ <updated>2026-04-17T00:00:00Z</updated>
+ <credits>
+ <individuals>
+ <individual>
+ <name>Karthik Kumar Balasundaram</name>
+ </individual>
+ </individuals>
+ </credits>
+ <affects>
+ <target>
+ <ref>log4net</ref>
+ <versions>
+ <version>
+ <range><![CDATA[vers:nuget/>=0|<2.0.10]]></range>
+ </version>
+ </versions>
+ </target>
+ </affects>
+ </vulnerability>
+
<vulnerability>
<id>CVE-2017-5645</id>
<source>
diff --git a/security.html b/security.html
index 39f6fbb6..71b8d378 100644
--- a/security.html
+++ b/security.html
@@ -483,6 +483,39 @@ See the
</ul>
</div>
</dd>
+<dt class="hdlist1">Deserialization of untrusted data (<a
href="https://cwe.mitre.org/data/definitions/502.html";>CWE-502</a>)</dt>
+<dd>
+<div class="paragraph">
+<p>Log4cxx, Log4j, and Log4net <strong>do not</strong> deserialize data from
any source as part of their normal operation.
+For backward compatibility, several classes in Log4j 2 and Log4net 2 still
implement <code>Serializable</code> (in Java) or carry the
<code>[Serializable]</code> attribute (in .NET); Log4j’s
<code>log4j-api</code> also ships an allowlist-based
<code>FilteredObjectInputStream</code> utility to assist applications that
nonetheless deserialize log event streams.</p>
+</div>
+<div class="openblock">
+<div class="content">
+<div class="paragraph">
+<p>Regarding this threat:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We provide <strong>no guarantee</strong> that deserializing a stream
containing classes from these projects is safe, regardless of the source of the
stream.</p>
+</li>
+<li>
+<p>Filtering such a stream by the <code>org.apache.logging</code> Java
package, the <code>log4net</code> .NET namespace, or any allowlist derived from
project-owned types is <strong>not</strong> sufficient to make deserialization
safe.</p>
+</li>
+<li>
+<p>The hardening utilities we ship are <strong>partial</strong> and
<strong>not exhaustive</strong>; bypasses are treated as opportunities for
further hardening, not as vulnerabilities in the project.</p>
+</li>
+<li>
+<p>The application performing the deserialization is responsible for ensuring
that the byte stream originates from a <strong>trusted source</strong>.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="paragraph">
+<p>See <a href="security/faq.html#deserialization" class="xref page">the FAQ
entry on CWE-502</a> for the recommended alternatives.</p>
+</div>
+</dd>
</dl>
</div>
</div>
@@ -1759,6 +1792,82 @@ Usages of <code>SslConfiguration</code> that are
configured via system propertie
</div>
</div>
<div class="sect2">
+<h3 id="CVE-2018-1285"><a class="anchor" href="#CVE-2018-1285"></a><a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1285";>CVE-2018-1285</a></h3>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 16.6666%;">
+<col style="width: 83.3334%;">
+</colgroup>
+<tbody>
+<tr>
+<th class="tableblock halign-left valign-top"><p
class="tableblock">Summary</p></th>
+<td class="tableblock halign-left valign-top"><p class="tableblock">XXE via
attacker-controlled log4net config files</p></td>
+</tr>
+<tr>
+<th class="tableblock halign-left valign-top"><p class="tableblock">CVSS 3.x
Score & Vector</p></th>
+<td class="tableblock halign-left valign-top"><p class="tableblock">9.8 HIGH
(AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)</p></td>
+</tr>
+<tr>
+<th class="tableblock halign-left valign-top"><p class="tableblock">Components
affected</p></th>
+<td class="tableblock halign-left valign-top"><p
class="tableblock"><code>log4net</code></p></td>
+</tr>
+<tr>
+<th class="tableblock halign-left valign-top"><p class="tableblock">Versions
affected</p></th>
+<td class="tableblock halign-left valign-top"><p
class="tableblock"><code>[0,2.0.10)</code></p></td>
+</tr>
+<tr>
+<th class="tableblock halign-left valign-top"><p class="tableblock">Versions
fixed</p></th>
+<td class="tableblock halign-left valign-top"><p
class="tableblock"><code>2.0.10</code></p></td>
+</tr>
+</tbody>
+</table>
+<div class="sect3">
+<h4 id="CVE-2018-1285-description"><a class="anchor"
href="#CVE-2018-1285-description"></a>Description</h4>
+<div class="paragraph">
+<p>Apache log4net versions before 2.0.10 do not disable XML external entities
when parsing log4net configuration files. This allows for XXE-based attacks in
applications that accept attacker-controlled log4net configuration files.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="CVE-2018-1285-threat-model"><a class="anchor"
href="#CVE-2018-1285-threat-model"></a>Threat Model</h4>
+<div class="paragraph">
+<p>According to the current threat model, this is no longer considered a
+vulnerability. The attack requires an attacker-controlled log4net
+configuration file, which is outside the scope of the threat model.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="CVE-2018-1285-mitigation"><a class="anchor"
href="#CVE-2018-1285-mitigation"></a>Mitigation</h4>
+<div class="paragraph">
+<p>Users are advised to upgrade to Apache Log4net version <code>2.0.10</code>,
which fixes this issue.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="CVE-2018-1285-credits"><a class="anchor"
href="#CVE-2018-1285-credits"></a>Credits</h4>
+<div class="paragraph">
+<p>This issue was discovered by Karthik Kumar Balasundaram.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="CVE-2018-1285-references"><a class="anchor"
href="#CVE-2018-1285-references"></a>References</h4>
+<div class="ulist">
+<ul>
+<li>
+<p><a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1285";>CVE-2018-1285</a></p>
+</li>
+<li>
+<p><a
href="https://issues.apache.org/jira/browse/LOG4NET-575";>LOG4NET-575</a></p>
+</li>
+<li>
+<p><a
href="https://github.com/apache/logging-log4net/commit/3242db510c27e825af7164415402f5012df521a2";>Security
fix commit</a></p>
+</li>
+<li>
+<p><a href="https://github.com/apache/logging-log4net/pull/64";>Pull request
that fixes the issue</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
<h3 id="CVE-2017-5645"><a class="anchor" href="#CVE-2017-5645"></a><a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-5645";>CVE-2017-5645</a></h3>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
diff --git a/security/faq.html b/security/faq.html
index 4e8c730f..5b5218b9 100644
--- a/security/faq.html
+++ b/security/faq.html
@@ -427,6 +427,117 @@ In practice, trustworthiness often varies even at the
per-key level: some contex
</div>
</div>
</div>
+<div class="sect1">
+<h2 id="deserialization"><a class="anchor" href="#deserialization"></a><a
href="https://cwe.mitre.org/data/definitions/502.html";>CWE-502: Deserialization
of Untrusted Data</a> in Log4j</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>A frequently reported issue concerns Log4j’s
<code>Serializable</code> classes and the allowlist-based
<code>FilteredObjectInputStream</code> utility shipped in
<code>log4j-api</code>.
+Reports typically claim that, taken together, these expose Log4j to
deserialization-based remote code execution when an attacker reaches a
deserialization sink.</p>
+</div>
+<div class="paragraph">
+<p><strong>Claim</strong>: Log4j is vulnerable to deserialization of untrusted
data because some of its classes are <code>Serializable</code> without
hardening logic that guarantees secure deserialization, allowing an attacker
who reaches a deserialization sink to construct a gadget chain through them.</p>
+</div>
+<div class="sect2">
+<h3 id="deserialization-why-not"><a class="anchor"
href="#deserialization-why-not"></a>Why this is not a vulnerability</h3>
+<div class="paragraph">
+<p>Log4j Core <strong>does not</strong> deserialize data from any source as
part of its normal operation.
+There is no code path in current Log4j Core production code that reads bytes
from a network socket, a message queue, or any other input and passes them to
<code>ObjectInputStream.readObject()</code>.</p>
+</div>
+<div class="paragraph">
+<p>For a deserialization vulnerability to exist, an application must:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Obtain a stream of bytes from an untrusted source, <em>and</em></p>
+</li>
+<li>
+<p>Pass those bytes to <code>ObjectInputStream.readObject()</code> (or an
equivalent API).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Both of these steps occur <strong>outside</strong> Log4j.
+The fact that Log4j classes happen to appear in such a stream does not make
Log4j the source of the vulnerability, any more than the presence of
<code>java.util.HashMap</code> in a gadget chain makes the JDK responsible for
it.</p>
+</div>
+<div class="paragraph">
+<p>Log4j provides <strong>no guarantee</strong> that deserializing a stream
containing its classes from an untrusted source is safe, and reports premised
on the assumption that such a guarantee exists fall outside our <a
href="../security.html#threat-model" class="xref page">threat model</a>.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="deserialization-historical-context"><a class="anchor"
href="#deserialization-historical-context"></a>Historical context</h3>
+<div class="paragraph">
+<p>Log4j 1 shipped a <code>SocketServer</code> and a
<code>SocketAppender</code> that exchanged log events over the network using
Java serialization.</p>
+</div>
+<div class="paragraph">
+<p>In Log4j 2:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>The <code>SocketServer</code> receiver was never reintroduced into the
production codebase.</p>
+</li>
+<li>
+<p><code>SerializedLayout</code>, originally provided for Log4j 1
compatibility, has been <strong>deprecated since version 2.9</strong> and
should not be used.
+See the <a
href="https://logging.apache.org/log4j/2.x/manual/layouts.html#SerializedLayout";>SerializedLayout
documentation</a> for details.</p>
+</li>
+<li>
+<p>Several Log4j 2 classes, most notably <code>Logger</code>,
<code>Message</code> and <code>LogEvent</code>, remain
<code>Serializable</code> for backward compatibility.
+The <code>Serializable</code> interface cannot be removed in a minor release
without breaking applications that rely on it.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>In Log4j Core 3, the <code>Serializable</code> interface has been removed
from these classes.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="deserialization-filtered-object-input-stream"><a class="anchor"
href="#deserialization-filtered-object-input-stream"></a>About
<code>FilteredObjectInputStream</code></h3>
+<div class="paragraph">
+<p>The Log4j API provides a <code>FilteredObjectInputStream</code> utility
that enforces a class allowlist when deserializing log event streams.
+This class exists as a <strong>defense-in-depth helper</strong> for
applications that, despite the guidance above, still consume serialized log
events.</p>
+</div>
+<div class="paragraph">
+<p><code>FilteredObjectInputStream</code> is <strong>not</strong> a security
boundary, and the project makes no guarantee that its allowlist is exhaustive
or bypass-proof:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Reports of allowlist bypasses are evaluated as <strong>hardening
opportunities</strong>, not as vulnerabilities in Log4j.</p>
+</li>
+<li>
+<p>The underlying unsafe operation, deserializing untrusted bytes against a
classpath that exposes arbitrary <code>Serializable</code> classes, is
performed by the consuming application, not by Log4j.</p>
+</li>
+</ul>
+</div>
+<div class="admonitionblock important">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-important" title="Important"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>If your application deserializes log event streams from any source you do
not fully control, you are performing an operation that the Logging Services
PMC does not endorse and cannot make safe.
+Recommended alternatives include:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Migrating to a structured layout such as JSON or RFC 5424, transported over
TLS.</p>
+</li>
+<li>
+<p>If serialized transport must be retained for legacy reasons, configuring a
JVM-wide serialization filter via <code>jdk.serialFilter</code> and ensuring
the producer and consumer endpoints are mutually authenticated and not exposed
to untrusted networks.</p>
+</li>
+</ul>
+</div>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
</article>
</div>
</main>
diff --git a/sitemap.xml b/sitemap.xml
index d76fd579..a33f4c90 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,86 +2,86 @@
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9";>
<url>
<loc>https://logging.apache.org/blog/20231117-flume-joins-logging-services.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231128-new-pmc-member.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231202-apache-common-logging-1.3.0.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231214-announcing-support-from-the-stf.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231218-20-years-of-innovation.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240725-Log4j-At-Community-Over-Code-2024.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240808-welcome-to-the-pmc-jan.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240812-log4j-bug-bounty.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20250728-introduction-to-vex-files.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/index.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/charter.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/download.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/guidelines.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/index.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/processes.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/security.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/security/faq.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/support.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/team-list.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/what-is-logging.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/xml/ns/index.html</loc>
-<lastmod>2026-04-10T14:36:40.249Z</lastmod>
+<lastmod>2026-05-04T20:55:15.925Z</lastmod>
</url>
</urlset>
