Make XInclude support in XML configuration opt-in for improved security hardening

## 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.