Hi,
Your image isn't displayed here. My guess is that your scanner looks for
the version numbers only instead of looking for weaknesses in the
sources. The CVE doesn't say that it is fixed in 2.9.5 because that
version doesn't exist (as I said, it's unofficial). Yes the fix is there
(the commit id was mentioned in a posting a few weeks ago).
Tilman
Am 22.10.2025 um 08:36 schrieb Saravanan Balakrishnan:
Thanks a lot for your help on this. Yes, we understand that upgrading
the jdk might resolve in our product, but due to high dependency on
the JDK overhead we are not in the position to upgrade JDK and need to
stick with JDK 8 for our older version.
We used to run Open-source scan on checking vulnerable jars in the
shared jar file. while doing so on the 2.9.5 snapshot shared in the
earlier mail and we hit the below vulnerability, need your
clarification on the same to that tika-parser-pdf-module.2.9.4.jar is
the name or shall be 2.9.5 instead, more over it shows the
CVE-2025-54988 ID still persist in the jar file. Can you please check
from your end and confirm that fix is in 2.9.5 snpashot build.
https://repository.apache.org/content/groups/snapshots/org/apache/tika/tika-server-standard/2.9.5-SNAPSHOT/tika-server-standard-2.9.5-20251014.184955-3.jar
Please note that we are insisting our end users to migrate from older
version to newer version as they are running Domino for long time,
they need some time to upgrade to newer versions which support latest
tika 3.2.3, till they migrate to newer version we have to support them
for smooth transition. So kindly understand our situation and help us
and our end users to proceed on this.
Thanks in advance.
Regards,
Saravanan B
----- Original message -----
From: "Tilman Hausherr" <[email protected]>
To: [email protected]
Subject: Re: Tika compilation error branch_2x
Date: Wed, Oct 15, 2025 1:26 PM
* [CAUTION: This email is from outside the organization. Unless
you trust the sender, don't click links or open attachments as
it may be a phishing email, which can steal your information
and compromise your computer.]
Hi,
There's now a jar file + checksum at the address mentioned.
Nevertheless, you'll have to migrate to a more recent version of
jdk and of tika. EOL of Tika was announced a year ago. You need to
track the information of the tools you're using instead of hoping
for help.
Tilman
Am 14.10.2025 um 19:51 schrieb Tilman Hausherr:
Hi,
I think you're confusing something, CVE-2025-54988 is not
because of PDFBox. The problem is in tika itself. You can
download PDFBox from the PDFBox website.
https://pdfbox.apache.org/download.html
I'll try to create a 2x build on the CI. I've never done this
before so this will be ... interesting. Progress will be seen
here:
https://ci-builds.apache.org/job/Tika/job/tika-branch_2x-jdk8/
and the results will be
https://repository.apache.org/content/groups/snapshots/org/apache/tika/tika-server-standard/2.9.5-SNAPSHOT/
(if that is the build you're using)
It might take some time, because the old build configuration
was deleted, I copied another configuration and adjusted the
repository source.
Note that this is unofficial, this is just me. I still run
dependency updates on the 2.* version for the PDFBox
regression tests.
Tilman
Am 14.10.2025 um 19:26 schrieb Saravanan Balakrishnan:
Thanks, Team for your reply.
There are few things that we need your input/suggestion,
1. As you said in the earlier mail that is it possible to
provide the tika-server-standard-2.9.5.jar file
compiled with checksum information which is needed for
us to keep track of the tika jars in our repository as
a private build.
2. If you are building tika 2.9.5 as an un-official
build, is it compiled using Java 1.8 as we have
dependency on that with our old release which support
Java 1.8 only.
3. Is it possible to download pdfbox jar and do a mere
replacement instead of doing the maven build say
replacing only class files that supposed to be needed
for pdfbox code with the newer version. Your
suggestion on this and its feasibility to do so. If
that possible, can you please provide the link to
download pdfbox jar and its checksum details.
4. Can you confirm that pdfbox 2.0.35 as per the recent
code change for the vulnerability fix in 2.x code
stream is that has any dependency on Java version
higher than 1.8.
Please note that we are using the Tika in our Domino
product older versions as well of which it has Java
dependency of 1.8. So, we are looking for one of the best
solutions to address this vulnerability issue fixed to our
customers who are running with Java 1.8 with Tika 2.x in
their environment.
As I mentioned earlier that we cannot compile the Tika
2.9.5 in our build environment and we have to stick to
Tika 2.9.x for our older releases which supports Java 1.8
not higher. So, we are looking for your great support on
this to resolve with best optimal solution.
Thanks & Regards,
Saravanan B
----- Original message -----
From: "Tilman Hausherr" <[email protected]>
<mailto:[email protected]>
To: [email protected]
Subject: Re: Tika compilation error branch_2x
Date: Mon, Oct 13, 2025 12:48 PM
* [CAUTION: This email is from outside the
organization. Unless you trust the sender, don't
click links or open attachments as it may be a
phishing email, which can steal your information
and compromise your computer.]
Hi,
Re (3) no, this isn't possible. Our builds do load
external libraries. Which means that (2) also isn't
possible.
Re (4), what I could do is to set the tika2 build job
on our ci back up so you'd get a snapshot build.
However this would use the latest versions of the
external libraries, and thus you would have to use the
complete server jar. And this isn't something "official".
The better solution would be to update to 3.* instead
of spending work time on such weird workarounds. The
risk of supply chain attacks (indirectly mentioned in
(1)) is the same when we run our builds on our ci
because we still use the external libraries and these
could be "evil" without us noticing. Although I
haven't heard of attacks on java / maven (mostly on js
and python, and the xz attack), the risk will grow in
the future due to people like us getting too old / ill
/ senile / dead. So consider running your server in a
controlled environment so that an "evil" PDF (with an
"evil" XFA in it) won't be able to do anything.
https://tika.apache.org/security-model.html
Tilman
Am 13.10.2025 um 06:33 schrieb Saravanan Balakrishnan:
Hi Tika Team,
I am looking for feasible solution for your
problem as we are trying to compile branch_2x
which has the fix for CVE-2025-54988 PDF XXE,
1. We have few restrictions on compiling in our
build room, we easy way to compile only the
affected class files in that branch to get the
fix into our build.
2. Is there are way to compile only affected
folders alone and use the class files in the
2.9.4 jar file, which is released. All we need
is to get that fix into 2.9.4 without full
compilation.
3. When we compile tika-server-standard does it
download dependent jar/class files while
compiling as our build system doesn't have
external access to download dependent files if
any. If you could provide some light on this
to compile very minimal without downloading
jars/classes.
4. Is it possible to compile from your end and
share it us, I mean branch_2x which creates 2.9.5.
Our customers are very keen to get this fixed
ASAP. Kindly provide best possible solution to get
the vulnerability fix for 2.x release.
We appreciate your valuable time and response.
Regards,
Saravanan B
