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]>
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
