CERN MonALISA CIT

Unauthenticated Path Traversal in CERN’s Monitoring Infrastructure.

MonALISA is a distributed monitoring framework developed at CERN and used across high-energy physics infrastructure worldwide. It has a web interface. That web interface has a shared utility method that opens files. That method never validates the path.

Here is what that means in practice, how I found it, and why it matters that the fix belongs in exactly one place.

The approach

Same as always. Source reading with one question: where does user input touch the filesystem without going through validation first?

MonALISA’s web layer routes HTTP parameters through a set of servlets. Each servlet calls a shared method, Utils.getProperties(), to load configuration. The method takes a filename, builds a path by string concatenation with a base directory, and opens it with FileInputStream. No canonicalization. No confinement check. No rejection of traversal sequences.

The vulnerable line is at Utils.java:313:

String sFullFileName = sConfDir + sFile + ".properties";

try (FileInputStream fis = new FileInputStream(sFullFileName)) {
    pTemp.load(fis);

sFile comes from the HTTP page parameter. There is nothing between the HTTP layer and the file open.

Why the existing checks do not help

Two traversal checks exist in the codebase. I want to be precise about this because it matters for understanding the correct fix.

show.java:63 checks for .. in the page name. It only guards the show servlet. It has no effect on any other caller of getProperties().

display.java:689 checks the image parameter for .., not the page parameter. The page parameter reaches the file open at line 766 with no preceding validation. The presence of this check on a different parameter in the same file tells you that path traversal was understood as a concern. It was fixed in the wrong place.

The dangerous operation is in the shared sink. A fix at an entry point does not protect any other entry point. Seven entry points call getProperties(). Fixing one leaves six exposed.

The include chain

This is the part that makes it more than a simple file read.

getProperties() implements recursive file inclusion. When a loaded file contains an include key, the named files are resolved through the same code path, with the same absence of validation. A single request that loads a file containing include=../../../../../../../../tmp/target causes the server to open a second arbitrary file automatically. Both files are parsed and merged into the HTTP response.

The recursion is not bounded by the base directory. It is not bounded by anything.

What the output looks like

A request to /monalisa/display?page=../../../../../../../../tmp/ml_db resolves to a path well outside the web application root, reads a properties file there, and returns all parsed key-value pairs in the response body. Credentials, connection strings, API keys, whatever the file contains.

Chaining through an include directive works the same way. Stage one loads stage two automatically. Both are returned in a single response.

The full proof of concept, including a verbatim extraction of the vulnerable logic deployed as a standalone servlet, is in the repository.

Remediation

The fix belongs inside Utils.getProperties(), applied before FileInputStream is opened and again before any include value is resolved. Canonical path comparison:

File base   = new File(sConfDir).getCanonicalFile();
File target = new File(sFullFileName).getCanonicalFile();
if (!target.toPath().startsWith(base.toPath())) {
    throw new IOException("path traversal rejected: " + sFullFileName);
}

One fix at the sink. All seven entry points protected.

Response

Reported to the CERN Computer Security Team on March 29, 2026. Patched March 30, 2026. Published with CERN’s knowledge under their coordinated vulnerability disclosure policy.

Full write-up, affected entry points, PoC servlet, and remediation diff: https://github.com/Klaurx/MonALISA-LFI-Path_reversal-