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:
// 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.
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:
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.