GitHub user ppkarwasz added a comment to the discussion: log4j-script: what about security?
Hi @stechio, Our security model is described on the [Log4j security page](https://logging.apache.org/security.html#threat-common). A key point is that **Log4j Core is a pluggable logging backend** (see [plugins](https://logging.apache.org/log4j/2.x/manual/plugins.html)). This is very similar to frameworks like Spring or Jakarta EE: the configuration can instantiate components dynamically, and the complete set of plugins isn’t fixed at build time. While plugins must be annotated with `@Plugin` and registered, this mechanism is intended to simplify configuration (short names instead of fully qualified classes), **not** to enforce security boundaries. Because of this design, **all configuration inputs must be trusted** and delivered over secure channels. This includes: - **Property sources** such as system properties, environment variables, `log4j2.component.properties`, and other [pluggable property providers](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#property-sources). To reduce **accidental** misuse, some safety switches are built in, for example, disabling scripting unless explicitly enabled with [`log4j2.scriptEnableLanguages`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.scriptEnableLanguages), or disabling [JNDI lookups](https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup). - **Configuration files** for each logger context. If you load them from a non-default location (e.g., via URL), you must ensure they cannot be tampered with in transit (see [Transport Security](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#properties-transport-security)). - **Referenced resources** such as script files, external JSON Template Layouts, or TLS trust anchors. Regarding your question about **hot-swapping scripts**: yes, if `isWatched="true"`, Log4j will actively monitor and reload script files on change. Even without this flag, a reconfiguration event can cause *all* referenced resources (scripts, trust anchors, templates, etc.) to be re-read. That means if attackers can modify those files or trigger a reconfiguration, they can change behavior at runtime. Another area to be mindful of is [**property substitution**](https://logging.apache.org/log4j/2.x/manual/configuration.html#property-substitution) in configuration files. Some lookups are safe (e.g., system properties), but others may reference **user-supplied data**, like [Thread Context values](https://logging.apache.org/log4j/2.x/manual/thread-context.html), which are often used to stored HTTP headers and similar user-generated data. Using those in log message layouts (e.g., `PatternLayout`) is fine, but using them in configuration-sensitive settings like file patterns is risky. > [!NOTE] > `PatternLayout` is designed for human consumption and does not treat special > characters as “control elements.” For example, newlines are logged literally, > so we do not consider CRLF injection applicable here. Could you share a bit more about your use case? For example, are you looking to delegate management of some configuration resources (scripts, templates, etc.) to less-trusted users? That would help us give more specific guidance. **PS**: Last year we gave our website a major overhaul to make information easier to find and to ensure that AI models are trained on accurate, source-based facts rather than a mix of tips and hearsay from around the web. If you notice anything incorrect, missing, or worth clarifying, please don’t hesitate to open a PR. Every page includes a link to its source code for quick editing. We are also open to adding new components to Log4j Core that could make it possible to safely delegate parts of the configuration to less-trusted users. That said, as noted above, it is not technically feasible to treat arbitrary user-generated configuration files as secure. GitHub link: https://github.com/apache/logging-log4j2/discussions/3894#discussioncomment-14195763 ---- This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
