A dot in the middle of a filename seems harmless. CWE-44 is the weakness where it is not: a product accepts path input in the form of an internal dot, like file.ordir, without appropriate validation, and that leads to ambiguous path resolution.
Most entries in this family are old. This one has a recent example in its observed list, which makes it worth a close look for anyone running Java servlet based products.
How it happens
Path equivalence, the parent idea in CWE-41, means one object has several valid names and a check covers only some of them. With internal dots, a program may convert a character in a request into a dot, or treat a dot as a separator, or compare names in a way that disagrees with the file system.
The recent record entry is CVE-2025-24813, listed by MITRE as a servlet in a Java based product that allows code execution via a file.Name internal dot. The record does not go further than that, so this post will not either. What it tells us is that a seemingly cosmetic difference in how a name is written can be enough to move a file operation into a place where its content gets executed.
A generic illustration of how a handler can go wrong:
// Vulnerable pattern: a name is derived from a request path by
// swapping a separator for a dot and then used as a file name
String key = request.getPathInfo(); // "/upload/session"
String fileName = key.replace('/', '.'); // ".upload.session"
File out = new File(storeDir, fileName); // attacker controls dot layout
The attacker controls where the dots fall, so they influence which name the file ends up with, and which component later treats it as something to load.
What an attacker gains
MITRE lists read and modify access to files and directories. The CVE in the record shows the worst case in practice, code execution. Code execution is not part of MITRE's generic consequence list for this entry, so treat it as one observed outcome rather than the norm.
How to find it
- Inventory the products and libraries in your build that include a servlet or file handling layer. A software bill of materials makes this fast.
- Check each against the vulnerability database and see whether your code calls the affected function. Reachability analysis does this, and it tells you which findings are urgent.
- In your own code, search for places where request data is converted into file names and review how separators and dots are treated.
Click through it at your own pace, or open it full screen.
How to fix it
- Update the affected product. For a vulnerability in a library or server you did not write, applying the fixed version is the real remedy. Check the vendor advisory for the version.
- Never derive a storage file name directly from request data. Generate it yourself, for instance a random ID, and keep the user supplied name as metadata.
- Canonicalize any path you must accept and confirm containment before use.
- Use an allowlist for characters and keep dots to a minimum. MITRE's guidance for filenames includes allowing only a single dot in the name.
- Store uploads outside any location where they can be loaded or executed, and drop write access for the service account where you can.
String fileName = UUID.randomUUID().toString(); // no input in the name
Path out = storeDir.resolve(fileName).normalize();
if (!out.startsWith(storeDir)) throw new SecurityException();
A free check of your dependency list takes a minute at gold.safeguard.sh/scan. No login, the file stays on your machine, up to 100 dependencies.
Quick check
What does CWE-44 describe?
Path input with an internal dot, like file.ordir, accepted without appropriate validation, leading to ambiguous path resolution.
Is application code the only place to fix this?
No. The recent example in the record is in a servlet in a Java based product, so patching the product is part of the answer. Your own code should also avoid deriving file names from request data.
