CVE-2021-29425

What it actually does

Apache Commons IO versions before 2.7 incorrectly normalize certain malformed path strings in FilenameUtils.normalize, including inputs such as "//../foo" and "\\..\foo". Instead of rejecting or safely resolving these paths, the method can return a value that still allows traversal into the immediate parent directory when the calling application trusts the normalized result to construct a filesystem path. The flaw does not, by itself, expose files; impact depends on application code that uses this normalization result for file reads, writes, uploads, downloads, template loading, archive extraction, or other path-based operations. Successful exploitation can allow limited path traversal with potential unauthorized file disclosure or modification within one directory level above the intended base path.

Why it matters to the business

Applications that rely on vulnerable Apache Commons IO path normalization may allow users to access or alter files outside an intended directory boundary. In practical terms, this can expose configuration files, tenant or user-uploaded content, application data, or other adjacent files, and in some workflows may allow overwriting files that affect business operations. The CVSS score is moderate and exploitation is context-dependent, but public exploit knowledge exists and Apache Commons IO is widely embedded in Java applications and downstream vendor products, including multiple Oracle and Debian-distributed packages, which increases the chance that vulnerable code exists indirectly through third-party software.

How an attack unfolds

An attacker first identifies an application feature that accepts a filename or path, such as file download, upload, import, export, attachment retrieval, report generation, archive extraction, or static content access. They then submit a specially crafted path beginning with malformed double separators and parent-directory traversal syntax, such as "//../foo" or a Windows-style variant such as "\\..\foo". If the application uses Apache Commons IO FilenameUtils.normalize from a vulnerable version and then joins the returned value to an allowed base directory without additional canonical path validation, the resulting filesystem operation may resolve to a file in the parent directory of the intended location. The attacker repeats this process to enumerate readable adjacent files, retrieve sensitive content, or, where the application performs writes, modify files outside the expected directory. Exploitation is usually application-specific and requires that the vulnerable library method be reachable through externally controlled path input.

How to fix it

Upgrade Apache Commons IO to version 2.7 or later; where possible, use the latest currently supported 2.x release rather than the minimum fixed version. Because this library is often transitive, review direct and indirect Java dependencies in Maven, Gradle, SBT, Bazel, application server libraries, container images, and vendor-supplied packages. If an affected third-party product embeds Commons IO, apply the vendor-provided security update for that product. As defense in depth, do not rely on string normalization alone for access control: resolve paths using platform filesystem APIs, canonicalize the final path, and verify that the resolved canonical path remains under the intended base directory before reading or writing. Reject absolute paths, UNC-style paths, doubled leading separators, encoded traversal sequences, null bytes, and path separators not expected by the application. Apply least-privilege filesystem permissions so the application process cannot read or write sensitive files outside its required directories.

How to confirm the fix worked

Confirm that no deployed application package contains Apache Commons IO versions earlier than 2.7. For Java applications, inspect dependency manifests and packaged artifacts, including pom.lock or dependency trees, Gradle dependency reports, SBOMs, JAR names such as commons-io-*.jar, and META-INF/MANIFEST.MF or Maven metadata inside shaded JARs. Validate container images and application server shared library directories as well as application-specific WEB-INF/lib directories. After upgrading, run regression tests against all file-handling endpoints using payloads such as "//../testfile", "\\..\testfile", encoded equivalents, and mixed separator variants, and confirm the application rejects them or resolves them to a path strictly within the approved base directory. Where feasible, add unit tests that compare the canonical resolved path against the canonical base directory before any filesystem operation.

Typical attack path

1. Find a web or API feature that accepts user-controlled file or path input.
2. Test common traversal strings and observe differences in errors, response codes, file contents, or timing.
3. Submit malformed traversal payloads such as "//../filename" or Windows-style "\\..\filename" that trigger the vulnerable normalization behavior.
4. Rely on the application using Apache Commons IO before 2.7 to normalize the value and construct a filesystem path.
5. Access or modify a file in the immediate parent directory of the intended base path, depending on the application’s file operation permissions.
6. Iterate through likely filenames such as configuration files, exported data, logs, attachments, or application-managed content to determine impact.

How to detect it

Exploitation evidence is usually application-specific because the vulnerable library does not generate a unique log event. Review web server, reverse proxy, WAF, API gateway, application, file access, auditd, EDR, and object/file storage logs for requests containing malformed traversal sequences with doubled leading separators, backslash traversal, URL-encoded separators, or repeated attempts against file-handling endpoints. Focus on endpoints that accept parameters such as file, filename, path, document, attachment, template, export, import, download, upload, resource, or name. Look for successful HTTP 200 responses, unusual file sizes, content-type mismatches, error messages revealing filesystem paths, or reads/writes of files one directory above expected application storage locations. On hosts, review file access telemetry for the application process touching configuration, log, credential, or data files outside its normal working directories. If available, compare historical access patterns before and after suspicious traversal requests and correlate source IPs, user accounts, session identifiers, and subsequent authentication or data-access anomalies.

• //../
• \\..\
• %2f%2f..%2f
• %5c%5c..%5c
• %2F%2F..%2F
• %5C%5C..%5C
• /%2e%2e/
• \..\
• FilenameUtils.normalize
• commons-io-2.6.jar
• commons-io-2.5.jar
• commons-io-2.4.jar
• commons-io-2.3.jar
• commons-io-2.2.jar
• commons-io-2.1.jar
• commons-io-1.4.jar
• commons-io-1.3.jar
• commons-io-1.2.jar
• commons-io-1.1.jar
• commons-io-1.0.jar

What your security team should do

• Inventory all Java applications and vendor products that include Apache Commons IO, including transitive and shaded copies.
• Prioritize internet-facing applications, file-management workflows, upload/download endpoints, import/export functions, and products listed by vendors as affected.
• Upgrade Apache Commons IO to 2.7 or later, preferably the latest supported release, and apply relevant vendor patches for packaged products.
• Review application code for use of FilenameUtils.normalize or similar string-based path checks on untrusted input.
• Add canonical path containment checks before all file reads, writes, extraction, and deletion operations.
• Search historical access, application, and WAF logs for malformed traversal payloads using doubled leading slashes, Windows UNC-style prefixes, encoded separators, and parent-directory tokens.
• Restrict application filesystem permissions so compromise of a file-handling feature cannot expose secrets, configuration, or unrelated application data.
• Add automated dependency scanning and SBOM checks to prevent reintroduction of Apache Commons IO versions earlier than 2.7.