CVE-2022-31159: Path Traversal in the AWS SDK for Java

CVE-2022-31159 is a partial path traversal vulnerability in the AWS SDK for Java v1, specifically in the com.amazonaws:aws-java-sdk-s3 artifact, affecting all releases before 1.12.261. If your build pulls in an older aws-java-sdk-s3 and you use the S3 TransferManager.downloadDirectory method, a maliciously named object key can write files partly outside the directory you intended.

The advisory carries a CVSS v3.1 base score of 7.9 (High), with the vector CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:L. It is a supply-chain-adjacent problem: the flaw is in a widely used AWS library, not in your own code, so most teams find it through a dependency scan rather than a code review.

What the flaw actually is

The bug lives in the downloadDirectory method of the S3 TransferManager component. When you call downloadDirectory, you supply a local destinationDirectory and the SDK walks the objects under a prefix, writing each one to a local path derived from its S3 key.

The problem is validation. The method did not fully sanitize UNIX double-dot (..) sequences in object keys. You control the destination directory, but you do not control the object keys — whoever uploaded objects to the bucket does. A crafted key containing .. segments could cause a downloaded file to escape the destination directory partially, landing somewhere the caller never intended.

It is called partial path traversal because the escape is constrained rather than arbitrary. It cannot walk to any absolute path on disk, but it can break out of the sibling directory boundary in specific cases, which is enough to overwrite or plant files where they should not be.

Who is affected

You are exposed if all of the following hold:

• You depend on com.amazonaws:aws-java-sdk-s3 at a version below 1.12.261.
• Your application calls TransferManager.downloadDirectory.
• The S3 bucket you download from can receive objects with attacker-influenced keys (for example, a bucket that accepts user uploads).

If you only use the newer AWS SDK for Java v2 (software.amazon.awssdk), this specific advisory does not apply — it targets the v1 SDK. Many Java projects still carry v1 transitively through older libraries, though, which is exactly why it keeps showing up in scans years later.

Confirming your exposure

Start with the Maven dependency tree so you see transitive pulls, not just direct declarations:

mvn dependency:tree -Dincludes=com.amazonaws:aws-java-sdk-s3

For Gradle:

./gradlew dependencyInsight --dependency aws-java-sdk-s3

If the resolved version is below 1.12.261, you have the vulnerable code on your classpath. Whether it is exploitable depends on whether you call downloadDirectory against a bucket with untrusted keys, but for remediation purposes the version is what a scanner keys on. This kind of transitive exposure is where an SCA tool earns its keep, since it flags the vulnerable artifact even when nothing in your own pom.xml names it directly.

How to fix CVE-2022-31159

The clean fix is to upgrade aws-java-sdk-s3 to 1.12.261 or later. In Maven:

<dependency>
  <groupId>com.amazonaws</groupId>
  <artifactId>aws-java-sdk-s3</artifactId>
  <version>1.12.261</version>
</dependency>

If the dependency arrives transitively, pin it with a BOM or a dependencyManagement block so every AWS artifact resolves to a consistent, patched line:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.amazonaws</groupId>
      <artifactId>aws-java-sdk-bom</artifactId>
      <version>1.12.261</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

If you are on the very old v1 line and want to modernize, moving to AWS SDK for Java v2 is the longer-term answer, but treat that as a separate migration, not an emergency patch.

A workaround when you cannot upgrade immediately

The AWS advisory documents a mitigation for teams that cannot bump the version right away: when calling TransferManager.downloadDirectory, pass a KeyFilter that rejects any S3ObjectSummary whose key contains the substring ...

KeyFilter safeKeys = objectSummary ->
    !objectSummary.getKey().contains("..");

transferManager.downloadDirectory(
    bucketName, keyPrefix, destinationDirectory, safeKeys);

This is a stopgap. It blocks the specific .. payload pattern but does not replace patching, so schedule the upgrade regardless.

Preventing the next one

The pattern behind this CVE — a trusted library method that trusts input it should not — recurs across ecosystems. A few habits keep you ahead of it:

• Pin AWS SDK artifacts through the official BOM so a transitive bump cannot silently downgrade you.
• Run dependency scanning in CI so a vulnerable aws-java-sdk-s3 fails the build instead of shipping.
• Treat object keys, filenames, and archive paths as untrusted input everywhere, not just in this one API. The broader Java scanning workflow applies the same logic to Zip Slip, XXE, and deserialization findings.

FAQ

Is CVE-2022-31159 remotely exploitable?

It requires an attacker to place a crafted object key in a bucket your application downloads from, plus a call to downloadDirectory. The CVSS vector marks attack complexity as high and requires user interaction, so it is not a trivial remote RCE, but it is a real integrity risk for apps that download attacker-influenced content.

Which version fixes CVE-2022-31159?

com.amazonaws:aws-java-sdk-s3 version 1.12.261 or later. Upgrade the artifact, ideally through the aws-java-sdk-bom so all AWS dependencies stay aligned.

Does this affect AWS SDK for Java v2?

No. The advisory targets the v1 SDK (com.amazonaws:aws-java-sdk-s3). The v2 SDK (software.amazon.awssdk) is a separate codebase and is not covered by this CVE.

Can I stay safe without upgrading?

Temporarily, yes, by supplying a KeyFilter to downloadDirectory that drops any key containing ... Treat that as a bridge to patching, not a permanent fix.