CVE-2025-54387

What it actually does

The flaw is a path traversal-style authorization bypass in Apache Tomcat path validation logic. A path is considered allowed when its raw string value starts with an allowed directory prefix, but the comparison does not require the prefix to end on a path boundary. If an allowed directory is configured as something like `/allowed/path` rather than `/allowed/path/`, a sibling path such as `/allowed/path-other` may incorrectly pass the check. Depending on how Tomcat or a downstream integration uses this path check, an attacker may be able to access files or directories outside the intended allowlist boundary.

Why it matters to the business

Systems running affected Tomcat 9 packages may expose files that administrators intended to keep inaccessible, potentially including application resources, configuration files, deployment artifacts, or other data located in sibling directories. The CVE is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity, but it has been public for over a year, so unpatched internet-facing deployments should still be treated as hygiene and exposure risks.

How an attack unfolds

An attacker first identifies a Tomcat deployment or application feature that serves or processes files only from configured allowed directories. They then infer or brute-force allowed path prefixes and craft requests for paths that begin with the same raw string but are not actually inside the intended directory, such as using a sibling directory name that shares the same prefix. Because vulnerable versions rely on a simple string prefix comparison rather than canonical path-boundary validation, the malicious path can be accepted as allowed. If the surrounding application exposes the file contents or processes the selected file, the attacker may retrieve unintended files or interact with resources outside the configured directory boundary. Successful exploitation depends on configuration and reachable application functionality; it is not, by itself, a universal remote code execution primitive.

How to fix it

Upgrade affected packages to fixed versions. For Debian 11, Debian 12, and Debian 13 `tomcat9`, update to `9.0.70-2` or later. For source-based Apache Tomcat deployments, ensure the fix corresponding to commit `05ccf0c3e22d388f0cf853e32485d8249d051f2f` or a later fixed release is present. As a compensating control, review file-serving and path-handling configurations to ensure allowed directories are expressed with canonical paths and explicit path separators, avoid raw prefix checks in custom code, normalize and canonicalize paths before authorization decisions, and deny access to sensitive directories such as application configuration, `WEB-INF`, `META-INF`, deployment work directories, logs, and secrets locations.

How to confirm the fix worked

Confirm package versions using the operating system package manager, such as `dpkg -l tomcat9` or `apt-cache policy tomcat9`, and verify the installed version is `9.0.70-2` or later on Debian-based systems. For source builds, verify the fixed commit or a containing release is included. Review application and Tomcat configurations for allowed directory entries that do not end with a path separator and for custom code that uses raw `startsWith`-style path checks. In a controlled test environment, attempt to access a sibling directory whose name shares the allowed directory prefix and confirm the request is denied. Also confirm that requests for protected resources such as `WEB-INF/web.xml`, `META-INF/MANIFEST.MF`, configuration files, logs, and adjacent deployment directories return denial responses rather than file contents.

Typical attack path

1. Identify an affected Tomcat 9 deployment or application feature that accepts a file path, resource name, upload/download location, or static-resource mapping.
2. Determine or guess an allowed directory prefix used by the application or Tomcat configuration.
3. Craft a path that starts with the allowed prefix as a raw string but resolves to a sibling or otherwise unauthorized location because the allowed prefix lacks a trailing path separator.
4. Submit the crafted request to the vulnerable endpoint or resource handler.
5. Use successful responses, differing HTTP status codes, response sizes, or error messages to confirm access outside the intended directory.
6. Retrieve sensitive files or enumerate adjacent directories if the surrounding application behavior permits it.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF events, application logs, and Tomcat logs for requests that target file-serving or resource endpoints with unusual path patterns. Focus on requests containing encoded path separators, traversal sequences, attempts to access protected Tomcat directories, or sibling directory names that share a configured allowed-directory prefix. Investigate successful `200`, `206`, or unusually sized responses for requests that should normally be denied with `403` or `404`. Look for repeated probing of resource paths, changes in response status after slight path mutations, and downloads of configuration, manifest, XML, properties, key, backup, or log files. If exploitation is suspected, preserve relevant access logs, application logs, deployed application directories, Tomcat configuration, and file access timestamps for forensic review.

• ../
• ..\\
• %2e%2e
• %2f%2e%2e
• %5c%2e%2e
• %252e%252e
• /WEB-INF/web.xml
• /WEB-INF/classes/
• /WEB-INF/lib/
• /META-INF/MANIFEST.MF
• /conf/server.xml
• /conf/tomcat-users.xml
• /conf/context.xml
• /conf/web.xml
• .properties
• .bak
• .backup
• .old
• .log
• .key
• .pem

What your security team should do

• Inventory Tomcat 9 deployments, with priority on internet-facing applications and systems that expose file download, static file, document management, upload, or resource browsing functionality.
• Patch Debian `tomcat9` packages to `9.0.70-2` or later, or update source-based deployments to a release containing commit `05ccf0c3e22d388f0cf853e32485d8249d051f2f`.
• Review application-specific path allowlists and replace raw string prefix checks with canonical path validation that enforces directory boundaries.
• Search web access logs for suspicious attempts to access protected Tomcat resources, encoded traversal sequences, or paths that resemble sibling-prefix bypass attempts.
• Restrict file-serving features to least-privilege directories and ensure Tomcat runtime permissions cannot read unnecessary configuration, secrets, backups, logs, or source files.
• Add regression tests for path-boundary checks, including sibling names that share an allowed prefix and encoded or normalized path variants.