ZeroXJacks opened a new issue, #4064:
URL: https://github.com/apache/logging-log4j2/issues/4064
## Background:
Log4j 2 currently enables XInclude Aware processing by default within its
XML configuration parser (XmlConfiguration.java). While this is a documented
feature for modularizing configuration files, it provides powerful
primitives—specifically the ability to fetch external local or remote
resources—that can be leveraged in post-exploitation scenarios.
## The Security Concern:
In modern distributed and cloud environments, the logging configuration
source is often influenced by environment variables (e.g.,
LOG4J_CONFIGURATION_FILE). If an environment is partially compromised, an
attacker can use the default-enabled XInclude feature to perform:
Local File Read: Exfiltrating sensitive system files /etc/passwd, cloud
instance credentials.
SSRF: Pivoting to internal network services or querying cloud metadata
endpoints (169.254.169.254).
Defense in Depth Argument:
While the Log4j threat model considers the configuration file a "trusted
data source," modern security best practices (Secure by Default) suggest that
high-risk features should not be active unless explicitly required.
Other logging frameworks have recently moved towards restricting similar
capabilities in their parsers (e.g., Logback CVE-2025-11226) to mitigate the
risk of configuration-level attacks. Making XInclude an opt-in feature would
significantly reduce the "blast radius" in cases where the configuration path
or environment variables are controlled by an adversary.
Proposed Change:
Modify XmlConfiguration to disable XInclude by default and introduce a
dedicated system property or configuration attribute to enable it.
Suggested Property: log4j2.enableXInclude (defaults to false).
Implementation:
```java
// factory initialization in XmlConfiguration.java
boolean enableXInclude =
PropertiesUtil.getProperties().getBooleanProperty("log4j2.enableXInclude",
false);
factory.setXIncludeAware(enableXInclude);
```
This change ensures that users who do not require modular XML includes are
protected by default, while those who do can easily re-enable the feature.
## Conclusion:
Following private discussions with the Log4j security team, I am opening
this public issue to gather community feedback on aligning Log4j's default XML
parser settings with "Secure by Default" principles without breaking existing
workflows for power users.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
