Apache Parquet Vulnerability: How a New Feature Led to a CVSS 10 Security Flaw

On a perfectly normal day, we find ourselves chilling when SUDDENLY — an international alert: there’s a critical CVSS 10 vulnerability in Apache Parquet, and of course, everyone is panicking!!

You, as a system admin or developer, rush to your phone, which won’t stop ringing, while CERT experts bombard you with alert emails… and amidst this chaos, you scratch your head (or something else) wondering: “Am I really affected, or is this just another tempest in a teapot?”

If you’re the type who prefers facts over rumors, this article will help you understand the details of the CVE-2025-30065 vulnerability that has caused panic among many in recent days. This is an incredible case where a security improvement has turned into a critical vulnerability.

I will also show you how to check if your systems are truly vulnerable within minutes, without spending hours sifting through your Maven dependencies.

First, for those unfamiliar, Apache Parquet is a highly efficient columnar storage format used for analytical data processing. It is utilized by the Apache Hadoop ecosystem and thousands of open-source projects, particularly in data pipelines, AI/ML, and big data. Companies like Airbnb, Twitter, and Netflix use it daily to manage their massive amounts of data.

Now, the timeline surrounding CVE-2025-30065 is completely mind-boggling:

• May 2, 2024: Apache Avro adds a security feature (no CVE)
• August 5, 2024: The feature is included in Apache Avro 1.11.4
• March 5, 2025: A developer suggests adding the same feature to Apache Parquet
• March 16, 2025: Apache Parquet 1.15.1 is released with the new feature
• March 29, 2025: Rumors about a serious vulnerability start spreading
• April 1, 2025: Official announcement of CVE-2025-30065 with a CVSS score of 10.0 (and no, it wasn’t an April Fool’s joke!)

Thus, a security enhancement (the addition of a whitelist) has become a critical vulnerability.

The most ironic part is that Apache Avro implemented the exact same feature without receiving a CVE. There wasn’t time because the “fix” was already available two weeks before the official announcement. Yes, I told you this timeline was utterly crazy!

Technically, the vulnerability lies in the parquet-avro module, which allows the incorporation of Avro objects into Parquet files. For the uninitiated, deserialization is the process of converting stored data into objects usable by a program. The issue is that during this deserialization, it is possible to instantiate arbitrary Java classes.

However, unlike classic Java deserialization vulnerabilities, only instantiation via a constructor with a single String parameter is possible. Luckily, this limitation significantly reduces the actual exploitability of the flaw, as we will see.

A CVSS score of 10.0, as you know, is the maximum level on the vulnerability severity scale. Typically, this indicates remote code execution without authentication, like Heartbleed (OpenSSL) or Log4Shell, which brought the internet to its knees a few years ago.

But in the case of CVE-2025-30065, the real-world limits of exploitation are much tighter than they appear, as in classic Java deserialization vulnerabilities where attackers could chain “gadgets” (Java objects used as pieces of a malicious puzzle) to execute virtually anything. Here, the attacker is limited to instantiating classes that:

• Are already in the target’s classpath
• Have a constructor accepting a single String parameter
• Produce useful side effects upon instantiation

Thus, possible attack scenarios remain limited:

• Watering hole: publishing a malicious dataset on a public repository
• Social engineering: directly sending the malicious Parquet file
• Spear-phishing: targeting specific developers

In any case, the attacker must first convince the victim to process a malicious Parquet file, which is not always straightforward.

So why should you still be cautious?

Because Parquet is ubiquitous in data pipelines and AI/ML. Configurations can vary drastically from one environment to another, and some organizations process Parquet files from unverified external sources. The risk is therefore significant in certain contexts, even though it’s not universal.

In light of this situation, F5 Labs has developed a fantastic tool: the “Canary Exploit.” Like a brave little canary in a coal mine detecting toxic gases, this open-source tool creates a malicious Parquet file that attempts to make an HTTP request to a URL of your choosing. If your system is vulnerable, it will try to connect to that URL, confirming the problem.

Technically, the tool generates a Parquet file containing a special Avro schema. This schema indicates that the string should be interpreted as a javax.swing.JEditorPane object. Thus, when a vulnerable system processes this file, it instantiates this class with the provided URL, which then attempts to connect, confirming the vulnerability.

Do you want to check if you’re vulnerable?

First, ensure you have Java JDK 21+ installed on your machine and follow the steps in the project’s README. Note that, on my end, the curl command did not work, so I had to manually retrieve the .jar file.

It’s user-friendly, even if you’re not a security ninja, and allows you to quickly verify if your systems are affected. Plus, if you’ve applied the patch, you can check that it’s actually in place. It’s the type of tool that helps quickly ensure everything is okay rather than slogging through a manual check of Maven or Gradle dependencies. It works on Linux, macOS, and Windows.

Of course, there are a few limitations:

• Your system must be able to make outbound requests (HTTP/DNS)
• Restrictive network configurations can lead to false negatives
• Very specific SERIALIZABLE_PACKAGES configurations could also skew results
• This is not a replacement for a comprehensive security analysis

But frankly, for a quick test, it’s ideal.

Now, who should really worry about this issue?

All organizations using Apache Parquet Java with the parquet-avro module in versions ≤1.15.0, especially those processing Parquet files from external sources. ML/AI/Big Data environments where Parquet is commonly used should also remain vigilant.

And if you are vulnerable, don’t panic! Here are the solutions to protect yourself:

• Upgrade to Apache Parquet ≥1.15.1
• Properly configure org.apache.parquet.avro.SERIALIZABLE_PACKAGES to restrict allowed packages
• Avoid the generic “*” parameter that nullifies the whitelist effect
• Scan your dependency tree with Maven or Gradle to detect vulnerable versions

In summary, it’s potentially dangerous under very specific conditions, but far from the catastrophic scenario that the CVSS 10.0 score might suggest. In any case, now you know.