Nom de domaine

We’re here chilling in a good normal day when suddenly International red alertwe learn that there is a CVSS 10 critical flaw in Apache Parquetand that everyone is panic of course !!

You, system admin or developer, you rush to your phone which does not stop ringing while the CERT experts bomb you with alert emails & mldr; And in the middle of this chaos, you scratch your head (or something else) asking yourself: “But am I really concerned, or is it still a storm in a glass of water?»

Well if you are the type to want to be concrete rather than rumor, this article will help you know what it returns to the CVE-2025-30065 flaw that has caused cold sweats to a lot of people in recent days. This is a fairly incredible case where a safety improvement has become a critical vulnerability.

And of course I will show you how to check if your systems are really vulnerable in a few minutes, without spending hours peel your Maven outbuildings.

In short, Apache Parquet, for those who are not familiar with this word, it is a storage format in columns particularly effective for the analytical processing of data. It is used by the Apache Hadoop ecosystem and thousands of open-source projects, especially in all that is data pipelines, AI/ML and Big Data. For example, boxes like Airbnb, Twitter or Netflix use it daily to manage their monstities of data.

Now what is delirious with the CVE-2025-30065 is its completely WTF chronology:

  • May 2, 2024: Apache Avro adds a safety functionality (no cve)
  • August 5, 2024: The functionality is included in Apache Avro 1.11.4
  • March 5, 2025: A developer suggests adding the same functionality to Apache Parquet
  • March 16, 2025: Apache Parquet 1.15.1 is published with the new functionality
  • March 29, 2025: rumors on a serious vulnerability begin to circulate
  • April 1, 2025: Official announcement of CVE-2025-30065 with CVSS 10.0 score (and no, it was not an April Fool!)

And this is how a safety improvement (The addition of an authorization list) has become a critical vulnerability.

And the most ironic in there is that Apache Avro implemented exactly the same thing without receiving a cve. He did not have time since, the “corrective” was already available two weeks before the official announcement. Yes, I told you that the chronology of events was Ouatzefuck!

Technically, the vulnerability is in the Parquet-Avro module which makes it possible to incorporate avro objects into parquet files. For uninitiated, de-eédérilization is the process that transforms data stored into objects that can be used by a program. The problem here is that during this dereialization, it is possible to instantiate arbitrary java classes.

However, unlike conventional Java deialization vulnerabilities, only instantiation via a manufacturer with a single string parameter is possible. This limitation fortunately considerably reduces the actual exploitability of the flaw, as we will see.

A CVSS 10.0 score is, as you know, the maximum level on the gravity scale of vulnerabilities. We generally speak of remote code execution without authentication, of the gender Heartbleed (OpenSSL) or Log4shell who put the Internet on his knees a few years ago.

But in the case of the CVE-2025-30065, the actual limits of the exploitation are much more restrictive than it seems because unlike the classic vulnerabilities of Java dereialization where one can chain “gadgets” (Java objects used as pieces of a malicious puzzle) to execute virtually anything, here the attacker is limited to the instantiation of classes which:

  1. Are already in the classpath of the target
  2. Have a manufacturer accepting a single string parameter
  3. Produce useful side effects during their instantiation

The possible attack scenarios therefore remain limited:

  • Watering Hole: Publish a malicious dataset on a public deposit
  • Social engineering: send the malicious parquet file directly
  • Spear-Phishing: Targeting specific developers

In any case, the attacker must above all convince his victim to process a malicious parquet file, which is not always obvious.

So why be careful?

Well because parquet is omnipresent in data pipelines and AI/ml. Configurations may vary enormously from one environment to another, and some organizations deal with parquet files of undeclaged external sources. The risk is therefore significant in certain contexts, even if it is not universal.

Faced with this situation, F5 Labs has developed a great great tool: the “Canary feat”. Like a courageous little canary in a mine that detects toxic gases, this open-source tool creates a malicious parquet file which tries to make a HTTP request to a URL that you indicate. If your system is vulnerable, it will then try to connect to this URL, confirming the problem.

Technically, the tool generates a parquet file containing a special AV scheme. This diagram indicates that the character string must be interpreted as a Javax.swing.jetorpane object. Thus when a vulnerable system treats this file, it installs this class with the supplied URL, which then tries to connect, confirming the vulnerability.

Do you want to check if you are vulnerable?

So first, make sure you have Java JDK 21+ installed on your machine and follow the following steps on the project’s reader. Be careful, at home, the Curl command did not work so I had to recover the .jar manually.

It’s easy to use, even if you are not a Ninja in a security and it allows you to quickly check if your systems are concerned. And then if you have set up the fix, it allows you to check that it is indeed well in place. This is the kind of tool that allows you to quickly check that everything is OK rather than letting go a manual check in the Maven or Gradle outbuildings. And it works under Linux, MacOS and Windows.

Of course, there are a few limitations:

  • Your system must be able to perform outgoing requests (HTTP/DNS)
  • Restrictive network configurations can lead to false negatives
  • Very specific configurations of serializable_packages could also distort the results
  • This is not a replacement for a complete safety analysis

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

Now, who should really worry about this thing?

Well, all organizations using Apache Parquet Java with the Parquet-Avro module in versions ≤1.15.0and especially those that treat parquet files from external sources. ML/IA/Big Data environments where parquet is commonly used should also be vigilant.

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

  • Upgrade to Apache Parquet ≥1.15.1
  • Properly configure org.apache.parquet.avro.serializable_packages To restrict authorized packages
  • Avoid the generic parameter ” *” which cancels the effect of the authorization list
  • Analyze your dependent tree with Maven or Gradle to detect vulnerable versions

In short, it is potentially dangerous under certain very specific conditions, but far from being the disaster scenario that the CVSS 10.0 score lets imagine. Anyway, now you know.

Source


Source link

Categorized in: