log4j-script: what about security?

[stechio]

I'm wondering about the security of the library on topic, considering that it allows loading scripts (such as groovy and javascript) from both configuration and external files. I have no experience in scripting within log4j, so my questions herein may be incorrect: I look forward to your guidance, thanks!

Skimming the documentation and peering at its source code, I couldn't find any reference to security assumptions, concerns, warnings, suggestions, etc.; apparently, the only related code is just the very code executing the script, which relies on AccessController.doPrivileged(..) (sic!)...

public Object execute(final String name, final ScriptBindings bindings) {
    final ScriptRunner scriptRunner = scriptRunners.get(name);
    if (scriptRunner == null) {
        logger.warn("No script named {} could be found", name);
        return null;
    }
    return AccessController.doPrivileged((PrivilegedAction<Object>) () -> scriptRunner.execute(bindings));
}

...and calls this:

public Object execute(final ScriptBindings bindings) {
    if (compiledScript != null) {
        try {
            return compiledScript.eval((Bindings) bindings);
        } catch (final ScriptException ex) {
            logger.error("Error running script " + script.getName(), ex);
            return null;
        }
    }
    try {
        return scriptEngine.eval(script.getScriptText(), (Bindings) bindings);
    } catch (final ScriptException ex) {
        logger.error("Error running script " + script.getName(), ex);
        return null;
    }
}

External script files can even be monitored for changes (via isWatched attribute): does this mean they can be hot swapped, potentially with arbitrary code, during the application execution?

Are the implementers of log4j-script relying on the optimistic assumption that users will run only trusted code in those script files? Or that the applications will run in secure environments, such as virtual machines?

Is there any architectural documentation/discussion explaining the rationale behind the design choices of this library and their security assessment?

[ppkarwasz]

Hi @stechio,

Our security model is described on the Log4j security page.

A key point is that Log4j Core is a pluggable logging backend (see plugins). 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. To reduce accidental misuse, some safety switches are built in, for example, disabling scripting unless explicitly enabled with log4j2.scriptEnableLanguages, or disabling JNDI lookups.
• 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).
• 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 in configuration files. Some lookups are safe (e.g., system properties), but others may reference user-supplied data, like Thread Context values, 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.

[stechio]

Thank you, @ppkarwasz, for the clear picture of the overall security assumptions backing the logging framework: so, to my understanding, log4j sensibly demarcates its own responsibility in the handling of log data (messages, string representation of parameters, thread contexts), whilst the safety of the execution environment and its resources is up to the administrators and application developers (trusted users) 👍

My doubts originated from the dated model used by other projects out there, which tends to put on the application level the burden of untrusted code, isolating extensions/plugins in some kind of sandbox, as a complement to the now-deprecated native java security manager.

(I don't have a particular use case to share, I was just contemplating the use of scripting to customize the logging configuration in a generic deployment scenario.)