Sorry, Tilman's and my emails crossed in the ether... +1 to what Tilman said.
On Wed, Oct 22, 2025 at 6:39 AM Tilman Hausherr <[email protected]> wrote: > 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]> <[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]> <[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 > > > > > > > > > > > > >
