Please provide WComponents compatible with Java 8 that removes susceptibility to critical Apache Tika vulnerability CVE-2025-66516

[david-a-campbell-aus]

Please provide WComponents compatible with Java 8 that removes susceptibility to critical vulnerability CVE-2025-66516

WFileWidget and WMultiFileWidget affected through use of class FileUtil which depends on Tika

Critical matter, we need to remediate some immediate vulnerabilities in client-facing systems in relation to uploaded file content.

[jonathanaustin]

WComponents uses Tika core to detect the mime type of an uploaded file. WComponents does not use any of the tika extensions.

As detecting the mime type of a file is supported natively in java there is no need to use tika.

The URLConnection class provides getContentType and guessContentTypeFromStream.

Refer to https://dev.to/excalibra/summary-of-methods-to-obtain-mime-types-of-files-in-java-27l5.

[david-a-campbell-aus]

A tech indicates that that method IS NOT reliable, they had a situation where it was failing to recognise valid JPEG files

[ricksbrown]

A tech indicates that that method IS NOT reliable, they had a situation where it was failiong to recognise valid JPEG files

Unit tests, not anecdotes, will determine the efficacy of this approach.

[david-a-campbell-aus]

Asked google:

is java.nio.file.Files.probeContentType more comprehensive than java.net.URLConnection.guessContentTypeFromStream in its determination of binary content types?

Answer:

Neither java.nio.file.Files.probeContentType(Path) nor java.net.URLConnection.guessContentTypeFromStream(InputStream) are inherently more comprehensive for binary content types, as both rely on highly platform-specific or limited internal mechanisms and often default to examining the file extension.

[ricksbrown]

Asked google:

is java.io.Files.probeContentType more comprehensive than java.net.URLConnection.guessContentTypeFromStream in its determination of binary content types?

Answer:

Neither java.nio.file.Files.probeContentType(Path) nor java.net.URLConnection.guessContentTypeFromStream(InputStream) are inherently more comprehensive for binary content types, as both rely on highly platform-specific or limited internal mechanisms and often default to examining the file extension.

I guess we'll find out when we run our unit tests.

[david-a-campbell-aus]

The issue is that URLConnection.guessContentTypeFromStream has troubles handling JPEG files that are JFIF format.*

URLConnection.guessContentTypeFromStream often fails to recognize JFIF files because its internal logic is limited to identifying common file headers and does not have a specific entry for the JFIF signature (which is essentially a "bare" JPEG stream without standard markers that the method expects). The method relies on a simple, built-in table and doesn't perform a deep content inspection.
(
from
https://www.google.com/search?q=java+URLConnection.guessContentTypeFromStream+can%27t+open+jfif&oq=java+URLConnection.guessContentTypeFromStream+can%27t+open+jfif&gs_lcrp=EgRlZGdlKgYIABBFGDkyBggAEEUYOdIBCTMyMjMwajBqMagCALACAA&sourceid=chrome&ie=UTF-8 )

[david-a-campbell-aus]

The link below contains a valid JPEG JFIF stream image that URLConnection.guessContentTypeFromStream can't identify, I saved the image locally and checked it and URLConnection.guessContentTypeFromStream returns null.

haraldk/TwelveMonkeys#441

Using imagemagick's identify command on the same file:

user@server:/mnt/c/temp$ identify jfif_image.jpg
jfif_image.jpg JPEG 3264x2448 3264x2448+0+0 8-bit sRGB 417629B 0.000u 0:00.000

Using jpeginfo:

user@server:/mnt/c/temp$ jpeginfo jfif_image.jpg
jfif_image.jpg 3264 x 2448 24bit n/a   N  417629

However the same file is successfully identified as jpeg using java.nio.file.Files.probeContentType if you pass in a file with no filename extension, because with filename extensions it wrongly presumes that file extension is correct:

Giving java.nio.file.Files.probeContentType the file with a png extension, it presume it is a png, which is wrong:

user@server:/mnt/c/temp$ cp jfif_image.jpg jfif_image.png
user@server:/mnt/c/temp$ java -classpath ~ FileMimeTypeGuesser3 jfif_image.png
jfif_image.png: image/png

But giving java.nio.file.Files.probeContentType the file with no extension in the filename, it successfully identifies the contents:

user@server:/mnt/c/temp$ cp jfif_image.jpg jfif_image
user@server:/mnt/c/temp$ java -classpath ~ FileMimeTypeGuesser3 jfif_image
jfif_image: image/jpeg

Source to FileMimeTypeGuesser3.java used above:

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URLConnection;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

public class FileMimeTypeGuesser3 {
public static void main(String[] args) throws Exception {
if (args.length == 0) {
System.out.println("Usage: java FileMimeTypeGuesser ...");
return;
}

    for (String filename : args) {
        String mimeType = null;
        Path path = Paths.get(filename);

        // 2. If null, try Files.probeContentType (often more comprehensive based on OS file types)
        if (mimeType == null) {
            mimeType = Files.probeContentType(path);
        }

        // Print the result
        System.out.println(filename + ": " + (mimeType == null ? "Undetermined" : mimeType));
    }
}

}

[jonathanaustin]

Another option we can consider to replace tika is using this mime-type library https://github.com/overview/mime-types

<dependency>
	<groupId>org.overviewproject</groupId>
	<artifactId>mime-types</artifactId>
	<version>2.0.0</version>
</dependency>

[david-a-campbell-aus]

That mime-types library docs say:

  You need two things to detect a file's type:

  The file's name
  The first few bytes of the file's content

how does that library go with JFIF jpegs or xlsx or pptx or xlsx files where the above information is NOT enough for accuracy? The latter *x files are all zips.

[ricksbrown]

Sounds like a case for TDD
i.e. perhaps we need a set of unit tests that need to pass and then see which ways of doing it fit the bill

[ricksbrown]

That mime-types library docs say:

  You need two things to detect a file's type:

  The file's name
  The first few bytes of the file's content

how does that library go with JFIF jpegs or xlsx or pptx or xlsx files where the above information is NOT enough for accuracy? The latter *x files are all zips.

It goes well.

.jfif = image/jpeg
.xlsx = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.docx = application/vnd.openxmlformats-officedocument.wordprocessingml.document
.pptx = application/vnd.openxmlformats-officedocument.presentationml.presentation

Correct according to MDN

[david-a-campbell-aus]

Most files with jfif content have the .jpg extension

what happens if you run the tool in scenarios as below:

1. have a file with jfif content saved with jpg extension
2. rename a .xlsx file as .zip
3. rename a .docx file as .xlsx
4. rename a .pptx file as .docx
5. rename a .jpg file as .png and then run the tool?

Unix file command does a decent job of identifying what files actually are even if they have the wrong file extension... how does this tool fare?

[david-a-campbell-aus]

Interestingly, java.nio.file.Files.probeContentType on linux works, but it is non-portable to Windows in terms of its functionality:

I'm trialling the mime-types library you mentioned in our codebase.

[david-a-campbell-aus]

org.overviewproject mime-types 2.0.0

My tests so far indicate that this library can work pretty well, but you must not run it against a file path that has a filename extension, eg .jpg because if you do, it reports the content type trusting the filename, without even looking at the file binary contents. In fact, if you give it a file path with a .jpg extension where the file path does not even exist, it reports image/jpeg for the file path purely based on the filename in the file path.