PXF 2.0 using Spring-Boot ecosystem component dependencies - Security vulnerability

[NadeemRajput-sys]

@tuhaihe Regarding PXF2.0, seems like using Spring Boot 2.5.12 ecosystem framework:

Is PXF built using Spring Boot 2.5.12 ecosystem components?

If yes, can this be patched to latest version (OR) removed, to make it supported by PXF avoiding vulnerabilities ?

I can see multiple Sprin-boot components:

spring-boot-gradle-plugin-2.5.12.jar
spring-boot-starter-web-2.5.12.jar
spring-boot-starter-tomcat-2.5.12.jar
spring-boot-actuator-2.5.12.jar
spring-boot-autoconfigure-2.5.12.jar

[tuhaihe]

Hi, would like to mention @ostinru @MisterRaindrop on this question. Thanks!

[ostinru]

Hi, @NadeemRajput-sys ! We are doing our best to keep cloudberry-pxf secure.

Spring Boot 2.5.12

It seems that you are using cloudberry-pxf as it was firstly released to opensource. Let's call it cloudberry-pxf 2.0.
We have updated spring-boot to 2.7.18 during cloudberry-pxf 2.1 release. You can update your cloudberry-pxf version to 2.1. It should be compatible.

However, vulnerability scanners will complain about spring-boot vulnerabilities: VMWare provides security patches only in Enterprise Support, that we don't have.

---

Then we should think about security model:

• Hackers can attack HTTP-endpoints (Spring Boot here!)
• Hackers can attack us by placing malicious files on S3 / HDFS / external storage

Keeping this in mind, we can mitigate issues:

• Allow only localhost access to PXF (use firewall or listen only on localhost).
• Use fresh and secure libraries that decodes / parses external sources.

As a result of this 2 actions, we do not expose vulnerable Spring libraries for attacker.

Moreover we still following VMWare changelog and updating 3rd party libraries (e.g. Tomcat like VMWare did in https://enterprise.spring.io/projects/spring-boot/2.7.21 ). However Spring Framework cannot be updated (your security scanner will point this out).

Final notes:
It is clear for the team, that we should update spring-boot to 3.5.x or 4.0.x. However it will force our users updating to Java 17. This is breaking change, that we would like to do in a major cloudberry-pxf 3.0.

[NadeemRajput-sys]

1- For using PXF2.1, do we need to opt minor upgrade CB server from 2.0 to 2.1 ? As we see, pxf2.1 has compatibility issues with CB2.0 server. Is that correct understanding !!
2- We are on KVM and not VMWare, does that still put the Sprin-Boot vulnerable ?
3- Updating Spring-Boot to 3.5.x or 4.0.x, that mean, it would be there with CB3.0 with pxf-3.0 release ?

[adnanhamdussalam]

Hi @ostinru ,

I am facing below error while on update the pxf 2.0 to 2.1 on 2.0.0-incubating build 1

Can you share your expert opinion

gpafiniti=# select version();
version

---

---

PostgreSQL 14.4 (Apache Cloudberry 2.0.0-incubating build 1) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5.0.1), 64-bit compiled on Aug 2
8 2025 15:25:48
(1 row)

gpafiniti=# create extension pxf;
ERROR: incompatible library "/usr/local/cloudberry-pxf-2.1.0/gpextable/pxf.so": version mismatch (dfmgr.c:371)
DETAIL: Server is version Cloudberry 2, library is version Cloudberry 2.1.
gpafiniti=# \q

[ostinru]

1- For using PXF2.1, do we need to opt minor upgrade CB server from 2.0 to 2.1 ? As we see, pxf2.1 has compatibility issues with CB2.0 server. Is that correct understanding !!

cloudberry-pxf 2.1 was first release. We built it with cloudberry 2.1 in mind. And, it seems that cloudberry extensions captures cloudberry version during build, and then asserts at runtime. I have created an issue to keep backward compatibility in next (2.2) versions.
apache/cloudberry-pxf#115

Upgrade CB2.0 -> 2.1 should solve compatibility issues. However please test upgrade on dev cluster before production. I heard that there are minor pg_catalog(?) changes between 2.0 and 2.1, so be careful.

Alternatively - you can build cloudberry-pxf 2.1 with cloudberry 2.0 from sources. It should be compatible. I am not sure that we will rebuild pxf-2.1 for cloudberry-2.0. Apache release process is tricky.

2- We are on KVM and not VMWare, does that still put the Spring-Boot vulnerable ?

Spring Boot is a collection of java libraries created by SpringSource. SpringSource was acquired by VMWare. Then moved to Pivotal. And acquired by VMWare again. So, VMWare (as company) continues Spring Boot development.
So, there is nothing about virtualization, it was about VMWare as company. And yes, it will be vulnerable if you expose PXF port to the public.

3- Updating Spring-Boot to 3.5.x or 4.0.x, that mean, it would be there with CB3.0 with pxf-3.0 release ?

Yes. This is our plan.