This is an automated email from the ASF dual-hosted git repository.
github-actions[bot] pushed a commit to branch main-site-stg-out
in repository https://gitbox.apache.org/repos/asf/logging-site.git
The following commit(s) were added to refs/heads/main-site-stg-out by this push:
new 33c2a102 Add website content generated from
`f4b1a4ff98374e75b1356882e85adf4111b6454c`
33c2a102 is described below
commit 33c2a102f4f0ea4b37fb85c3078b2888e91bf6dc
Author: ASF Logging Services RM <[email protected]>
AuthorDate: Mon May 4 20:53:10 2026 +0000
Add website content generated from
`f4b1a4ff98374e75b1356882e85adf4111b6454c`
---
security.html | 33 ++++++++++++++++
security/faq.html | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
sitemap.xml | 42 ++++++++++-----------
3 files changed, 165 insertions(+), 21 deletions(-)
diff --git a/security.html b/security.html
index 183bfb99..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>
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 0ca03f80..67c08297 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-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231128-new-pmc-member.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231202-apache-common-logging-1.3.0.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231214-announcing-support-from-the-stf.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231218-20-years-of-innovation.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240725-Log4j-At-Community-Over-Code-2024.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240808-welcome-to-the-pmc-jan.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240812-log4j-bug-bounty.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20250728-introduction-to-vex-files.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/index.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/charter.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/download.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/guidelines.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/index.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/processes.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/security.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/security/faq.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/support.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/team-list.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/what-is-logging.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/xml/ns/index.html</loc>
-<lastmod>2026-05-04T20:51:53.839Z</lastmod>
+<lastmod>2026-05-04T20:53:08.975Z</lastmod>
</url>
</urlset>
