Add security considerations to the RoutingAppender documentation

[h4xr]

Description

Currently RoutingAppender based on its configuration can materialize an unbounded number of routes. This coupled with a user controlled or high cardinality key can result in File descriptor exhaustion.

Example configuration which can be problematic:

<?xml version="1.0" encoding="UTF-8"?>

<Configuration status="WARN">

    <Appenders>

        <Routing name="Routing">

            <Routes pattern="${ctx:userId}">

                <Route>

                    <File name="File-${ctx:userId}" fileName="logs/user-${ctx:userId}.log">

                        <PatternLayout pattern="%d %p %c{1.} [%t] %m%n"/>

                    </File>

                </Route>

            </Routes>

            <IdlePurgePolicy timeToLive="10" cleanupIntervalMillis="1000"/>

        </Routing>

        <Console name="Console" target="SYSTEM_OUT">

            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>

        </Console>

    </Appenders>

    <Loggers>

        <Root level="info">

            <AppenderRef ref="Routing"/>

            <AppenderRef ref="Console"/>

        </Root>

    </Loggers>

</Configuration>

Configuration

Version: 2.26.3

Operating system: Mac OS 15

JDK: openjdk64-25.0.3

Logs

N/A

Reproduction

log4j config:

<?xml version="1.0" encoding="UTF-8"?>

<Configuration status="WARN">

    <Appenders>

        <Routing name="Routing">

            <Routes pattern="${ctx:userId}">

                <Route>

                    <File name="File-${ctx:userId}" fileName="logs/user-${ctx:userId}.log">

                        <PatternLayout pattern="%d %p %c{1.} [%t] %m%n"/>

                    </File>

                </Route>

            </Routes>

            <IdlePurgePolicy timeToLive="10" cleanupIntervalMillis="1000"/>

        </Routing>

        <Console name="Console" target="SYSTEM_OUT">

            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>

        </Console>

    </Appenders>

    <Loggers>

        <Root level="info">

            <AppenderRef ref="Routing"/>

            <AppenderRef ref="Console"/>

        </Root>

    </Loggers>

</Configuration>

Java Code to Trigger the bug:

import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.Logger;

import org.apache.logging.log4j.ThreadContext;

import java.util.UUID;


public class Harness {

    private static final Logger logger = LogManager.getLogger(Harness.class);


    public static void main(String[] args) {

        System.out.println("Starting DoS harness...");

        for (int i = 0; i < 1000000; i++) {

            String userId = UUID.randomUUID().toString();

            ThreadContext.put("userId", userId);

            [logger.info](http://logger.info/)("Log message for user: " + userId);

            if (i % 10000 == 0) {

                System.out.println("Logged " + i + " unique users...");

            }

        }

        System.out.println("Finished logging.");

    }

}

---

Detected using Decypher

[h4xr]

@ppkarwasz as discussed over the security list, opening an issue here.

I think we can have 2 fixes for this:

• RoutingAppender: We can introduce an option maxRoutes configuration in the RoutingAppender which can be enabled by consumers on need basis. This can help with unbounded growth of file descriptors open at a given moment. This will ensure, for a high cardinality key, the system is not at risk of running out of file descriptors.
• IdlePurgePolicy: While it allows to automatically cleanup appenders which are not in use for a while, having a high cardinality key in a high throughput system can mean, the mitigation may not be enough. We can add a note in the log4j documentation about the same so the users are aware about configuring RoutingAppender with IdlePurgePolicy with keys that are user controlled or high cardinality.

If the designs make sense, I will be happy to contribute the improvements

[ppkarwasz]

Hi @h4xr,

Thank you for opening this public issue.

Since the scenario you describe is theoretical rather than something observed in production, I would rather hold off on adding any new settings until a concrete use case comes along. Capping the number of routes open at any given time would silently break users who have deliberately chosen to create a huge number of appenders and provisioned enough resources to handle that workload. The only related report we have received (#2255) came from a user allocating appenders dynamically, and against our advice they chose to write custom code instead of using RoutingAppender.

What we can usefully do is expand the RoutingAppender documentation to give a fuller picture of the aspects to consider when using the component. It is intentionally powerful, so that users can express a wide range of routing logic, for example:

• creating a separate log file per tenant or long-running job,
• implementing round-robin routing between appenders.

That power comes with responsibilities, and there are a couple of aspects users should review in their configuration:

• Resource allocation. The system must be able to provision enough resources for every appender that can be created. Spinning up a separate appender per web request, for instance, is possible, but it is not a good idea: fish tagging log events and filtering on the tag is a far better use of resources.
• Threat model. RoutingAppender is one of the components where a lookup returning untrusted data can do real damage (path traversal, SSRF, and so on). Other appenders are created to soon for lookups to contain any attacker-controlled data. It is worth pointing users back to our threat model as a reminder that they are responsible for ensuring that appender configuration attributes come from trusted sources. This is something we cannot filter out a priori: only the application developer knows which MDC keys carry validated data and which are entirely attacker-controlled.

If you would like to help, a PR improving the RoutingAppender documentation along these lines would be very welcome.