[javasecurity:S6096] Zip slip not reported when unzip is done using Java NIO

Make sure to read this post before raising a thread here:

Then tell us:

  • What language is this for?
    • Java
  • Which rule?
    • javasecurity:S6096
  • Why do you believe it’s a false-negative?
    • Files.copy invocation is not detected as writing file outside of destination directory when using Java NIO API when using FileOutputStream as in here it is detected as vulnerable.
  • Are you using
    • SonarQube - Enterprise Edition Version 10.2 (build 77647)
  • How can we reproduce the problem?
import java.io.IOException;
import java.io.InputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardCopyOption;
import java.util.Enumeration;
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;

public class Example {

    private static String targetDirectory = "/example/directory/";

    public void extractEntry(ZipFile zipFile) throws IOException {

        Enumeration<? extends ZipEntry> entries = zipFile.entries();
        while (entries.hasMoreElements()) {
            ZipEntry entry = entries.nextElement();
            String name = entry.getName();
            Path destPath = Path.of(targetDirectory + name);
            try (InputStream zis = zipFile.getInputStream(entry)) {
                Files.copy(zis, destPath, StandardCopyOption.REPLACE_EXISTING);

Hi @Dave562

Thank you for the detailed feedback. I could reproduce the FN.
It’s caused by a gap in our support of the java.nio.file.Path API. I created a ticket to fix our engine.

In the meantime you can ass the following custom configuration to your project setting:

    "common": {
        "passthroughs": [
                "methodId": "java.nio.file.Path#of",
                "isMethodPrefix": true,
                "args": [

This answer was ment to be posted here [javasecurity:S6096] Zip slip reported when prevented using Java NIO - #4

Hi @Dave562

Thanks again for your feedback and for the code example you shared. I confirmed that I could reproduce this FP. It’s caused by a known limitation in our engine.

I can also confirm that the code you shared is not vulnerable to ZipSlip and you can safely change the issue status to Resolved (False-Positive).


Hello @Pierre-Loup_Tristant,

thanks for confirmation. I just linked your answer regarding FP to the other issue, to which I believe your answer belong. Just out of curiosity, is the known limitation you are refering to going to be lifted at some point? And is it also affecting other rules, like for example is it in general ignored as using IO when using NIO?