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 4fcf533c Add website content generated from
`c3de0700b34b80ead6bae76ca6442c53a3a0fb4a`
4fcf533c is described below
commit 4fcf533cb8805e626730b07be5fb1ea7ca415f28
Author: ASF Logging Services RM <[email protected]>
AuthorDate: Thu Jun 25 19:43:43 2026 +0000
Add website content generated from
`c3de0700b34b80ead6bae76ca6442c53a3a0fb4a`
---
security.html | 118 ++++++++++++++++++++++++++++++++++++++--------------------
sitemap.xml | 42 ++++++++++-----------
2 files changed, 98 insertions(+), 62 deletions(-)
diff --git a/security.html b/security.html
index 5edd0db5..f311b818 100644
--- a/security.html
+++ b/security.html
@@ -271,19 +271,21 @@ They have unrestricted access to all the features of the
logging framework and t
</div>
</div>
<div class="sect2">
-<h3 id="threat-common-sources"><a class="anchor"
href="#threat-common-sources"></a>Data sources</h3>
+<h3 id="threat-common-sources"><a class="anchor"
href="#threat-common-sources"></a>Sources</h3>
<div class="paragraph">
-<p>Logging systems read data from multiple sources that are controlled by both
trusted and untrusted users:</p>
+<p>Logging systems read data from multiple sources.
+Each source is classified by <strong>who controls it</strong>, since that
determines whether the frameworks can trust the data and how they must handle
it.
+The three categories below are defined by their controller: the
<strong>operator</strong> who deploys the application, the
<strong>developer</strong> who writes it, and the <strong>user</strong> whose
data the application processes.</p>
+</div>
+<div class="sect3">
+<h4 id="threat-common-sources-configuration"><a class="anchor"
href="#threat-common-sources-configuration"></a>Configuration
(operator-controlled)</h4>
+<div class="paragraph">
+<p>Configuration is supplied by the <strong>operator</strong> (the deployer or
administrator) and is <strong>trusted</strong>.
+It comprises environment variables, configuration properties, and
configuration files.</p>
+</div>
+<div class="paragraph">
+<p>To maintain security, the following responsibilities fall on the
deployer:</p>
</div>
-<div class="dlist">
-<dl>
-<dt class="hdlist1">Trusted Sources</dt>
-<dd>
-<div class="ulist">
-<ul>
-<li>
-<p>Log4cxx, Log4j, and Log4net <strong>trust</strong> environment variables,
configuration properties, and configuration files.
-To maintain security, the following responsibilities fall on the deployer:</p>
<div class="ulist">
<ul>
<li>
@@ -296,58 +298,89 @@ To maintain security, the following responsibilities fall
on the deployer:</p>
<p>Be aware that <strong>non-confidential</strong> channels such as HTTP or
JMX are <strong>disabled by default</strong> to prevent accidental exposure.</p>
</li>
<li>
-<p>If configuration files use interpolation features (e.g., (<a
href="https://logging.apache.org/log4j/2.x/manual/lookups.html";>Log4j
Lookups</a>)), ensure that only trusted data sources are used.</p>
-</li>
-<li>
-<p>Pay special attention to values stored in the context map (see <a
href="https://logging.apache.org/log4j/2.x/manual/thread-context.html";>Thread
Context in Log4j</a>).
-Although the context map is only accessible by developers, it has been known
to include user-provided data, such as HTTP headers, which can introduce
risks.</p>
+<p>If configuration files use interpolation features (e.g., <a
href="https://logging.apache.org/log4j/2.x/manual/lookups.html";>Log4j
Lookups</a>), ensure that only trusted data sources are used.
+In particular, values read from the context map (see <a
href="https://logging.apache.org/log4j/2.x/manual/thread-context.html";>Thread
Context in Log4j</a>) may contain user-provided data, such as HTTP headers; see
<a href="#threat-common-sources-content">Content (user-controlled)</a>.</p>
</li>
</ul>
</div>
-</li>
-<li>
-<p>The logging frameworks <strong>trust</strong> that the objects passed to
the log statements can be safely converted to strings:</p>
+</div>
+<div class="sect3">
+<h4 id="threat-common-sources-structural"><a class="anchor"
href="#threat-common-sources-structural"></a>Structural identifiers and control
(developer-controlled)</h4>
+<div class="paragraph">
+<p>Structural identifiers and control inputs are supplied by the
<strong>developer</strong> in the application source code and are
<strong>trusted</strong>.
+They are expected to be compile-time constants, or values otherwise chosen by
the developer, rather than data derived from end users.
+Examples include:</p>
+</div>
<div class="ulist">
<ul>
<li>
-<p>These frameworks should not be used to log deserialized data from untrusted
sources.
-See <a
href="https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data";>the
related OWASP guide</a> for details.</p>
-</li>
-</ul>
-</div>
+<p>Logger names, levels, and markers.</p>
</li>
<li>
-<p>If parameterized logging is used, the format string is
<strong>trusted</strong>:</p>
-<div class="ulist">
-<ul>
+<p>The identifiers and field names of a structured log message, such as the
<code>MSGID</code> and <code>SD-ID</code> fields of an RFC 5424 syslog
message.</p>
+</li>
<li>
-<p>Programmers <strong>should</strong> use compile-time constants as format
strings to prevent attackers from tampering messages.
+<p>The format string of a parameterized log statement.
+Programmers <strong>should</strong> use compile-time constants as format
strings to prevent message tampering and log injection.
See <a
href="https://logging.apache.org/log4j/2.x/manual/api.html#best-practice-concat";>Don’t
use string concatenation</a> for an example.</p>
</li>
</ul>
</div>
-</li>
-</ul>
+<div class="paragraph">
+<p>Because these inputs are trusted, the frameworks <strong>may</strong>
reject a malformed value (for example, by throwing an exception) instead of
silently altering it: a malformed structural identifier is a programming error.
+Routing untrusted data into one of these inputs is application misuse and is
<strong>out of scope</strong>.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-common-sources-content"><a class="anchor"
href="#threat-common-sources-content"></a>Content (user-controlled)</h4>
+<div class="paragraph">
+<p>Content is the data an application logs on behalf of its
<strong>users</strong> and is <strong>not trusted</strong>.
+The frameworks accept arbitrary content and <strong>must not</strong> reject
it: rejecting user-controlled input would turn a malicious value into a denial
of service.</p>
</div>
-</dd>
-<dt class="hdlist1">Untrusted Sources</dt>
-<dd>
<div class="ulist">
<ul>
<li>
-<p>Log4cxx, Log4j and Log4net <strong>do not</strong> trust log messages.
+<p>Log4cxx, Log4j, and Log4net <strong>do not</strong> trust log messages.
No particular input validation for log messages is necessary.</p>
</li>
<li>
<p>They <strong>do not</strong> trust the string representation of log
parameters.</p>
</li>
<li>
-<p>The logging frameworks do not trust neither the keys nor the values in the
thread context.</p>
+<p>They <strong>do not</strong> trust the <strong>values</strong> stored in
the thread context.</p>
</li>
</ul>
</div>
-</dd>
-</dl>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-note" title="Note"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>Although the frameworks accept arbitrary content, they
<strong>trust</strong> that the objects passed to a log statement can be safely
converted to strings.
+They <strong>should not</strong> be used to log deserialized data from
untrusted sources; see <a
href="https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data";>the
related OWASP guide</a>.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-note" title="Note"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>The trust level of thread context <strong>keys</strong> is under discussion
in <a
href="https://github.com/apache/logging-log4j2/discussions/4132";>logging-log4j2#4132</a>.
+Until that discussion concludes, this document classifies only thread context
<strong>values</strong> as content; the classification of keys is a
<strong>known open gap</strong>.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
</div>
</div>
<div class="sect2">
@@ -361,13 +394,13 @@ Defining these capabilities clarifies which reports are
in scope: a report that
<dt class="hdlist1">In-scope adversary</dt>
<dd>
<div class="paragraph">
-<p>An in-scope adversary is any party whose data reaches the logging framework
<strong>exclusively</strong> through the untrusted sources described above.
+<p>An in-scope adversary is any party whose data reaches the logging framework
<strong>exclusively</strong> through the user-controlled content described in
<a href="#threat-common-sources-content">Content (user-controlled)</a>.
Such an adversary is assumed to be able to:</p>
</div>
<div class="ulist">
<ul>
<li>
-<p>Submit arbitrary byte sequences, including malformed text encodings and
control characters (such as <code>CR</code>, <code>LF</code> and
<code>NUL</code>), through log messages, the string representation of log
parameters, and the keys and values of the thread context.</p>
+<p>Submit arbitrary byte sequences, including malformed text encodings and
control characters (such as <code>CR</code>, <code>LF</code> and
<code>NUL</code>), through log messages, the string representation of log
parameters, and the values of the thread context.</p>
</li>
<li>
<p>Submit excessively long inputs, within whatever limits the calling
application enforces.</p>
@@ -386,7 +419,10 @@ Such an adversary is assumed to be able to:</p>
<div class="ulist">
<ul>
<li>
-<p>An adversary able to modify environment variables, configuration
properties, or configuration files: these are trusted sources (see <a
href="#threat-common-sources">Data sources</a>).</p>
+<p>An adversary able to modify environment variables, configuration
properties, or configuration files: these are trusted sources (see <a
href="#threat-common-sources-configuration">Configuration
(operator-controlled)</a>).</p>
+</li>
+<li>
+<p>An adversary able to control the structural identifiers or control inputs
of a log statement, such as logger names, levels, markers, structured-message
identifiers, or format strings: these are developer-controlled, trusted inputs
(see <a href="#threat-common-sources-structural">Structural identifiers and
control (developer-controlled)</a>). Populating them from untrusted data is
application misuse.</p>
</li>
<li>
<p>An adversary able to execute arbitrary code in the same process as the
logging framework. Code running in the same process shares the same trust level
as the logging framework itself; there is no boundary to enforce. This includes
code introduced through plugins, custom appenders, or other application
extensions.</p>
@@ -587,7 +623,7 @@ In particular, this document must be revisited when any of
the following becomes
<div class="ulist">
<ul>
<li>
-<p>A new public API is added that accepts a kind of input not yet covered by
<a href="#threat-common-sources">Data sources</a>.</p>
+<p>A new public API is added that accepts a kind of input not yet covered by
<a href="#threat-common-sources">Sources</a>.</p>
</li>
<li>
<p>An existing entry point begins to accept input from a new source, changing
whether that input is trusted or untrusted.</p>
diff --git a/sitemap.xml b/sitemap.xml
index 50ad50b8..b3cf144d 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-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231128-new-pmc-member.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231202-apache-common-logging-1.3.0.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231214-announcing-support-from-the-stf.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20231218-20-years-of-innovation.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240725-Log4j-At-Community-Over-Code-2024.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240808-welcome-to-the-pmc-jan.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20240812-log4j-bug-bounty.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/20250728-introduction-to-vex-files.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/blog/index.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/charter.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/download.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/guidelines.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/index.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/processes.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/security.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/security/faq.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/support.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/team-list.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/what-is-logging.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
<url>
<loc>https://logging.apache.org/xml/ns/index.html</loc>
-<lastmod>2026-06-23T18:53:35.715Z</lastmod>
+<lastmod>2026-06-25T19:43:41.876Z</lastmod>
</url>
</urlset>
