The cve is triggered by a PDF with crafted XFA, so the vulnerability is in the PDFParser. However, the fix for that cve went into tika-core. I can confirm via code review just now that our branch_2x has the fix in it. You will likely get complaints from dependency scanners because 2.9.5 is less than the published cve fix version. You should be using only 2.9.5-SNAPSHOT components for all of Tika if you can't move to 3.x.
As we posted in our general email on how to mitigate this CVE, you'll want to test that the fix works with how you're using Tika. Dependencies on your classpath, including woodstox, for example, may change the underlying security behavior of the XML parser. Reference to that email and a POC are available here: https://github.com/jonaslejon/malicious-pdf/issues/22 On Wed, Oct 22, 2025 at 2:37 AM Saravanan Balakrishnan < [email protected]> wrote: > 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]> <[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 > > > > > > > > > > >
