Share
## https://sploitus.com/exploit?id=503FBDF4-90FA-52B3-82F0-E1BB43FC679A
# CVE-2025-30065 Proof of Concept - Apache Parquet RCE

> ⚠️ FOR EDUCATIONAL AND AUTHORIZED SECURITY RESEARCH ONLY ⚠️  
> Do not use in unauthorized environments. This PoC is provided **as-is** and the author is not responsible for misuse.

## Description

This repository demonstrates a **functional exploit** of CVE-2025-30065, a vulnerability in Apache Parquet's Avro schema handling. The PoC includes all components necessary to reproduce code execution through malicious default values in Avro records embedded in Parquet files.

## Structure

- `ParquetExploitGenerator.java` – Generates a malicious Parquet file containing an Avro schema with a record field using a default object, which may trigger class instantiation.
- `PayloadRecord.java` – The class that gets instantiated if present in the classpath. Contains a static block that is executed upon instantiation.
- `ParquetVictim.java` – A simulation of a vulnerable system that reads the malicious Parquet file and unintentionally triggers the payload through deserialization.

## Author

**@h3st4k3r** β€” VM, CTI & researcher  
https://github.com/h3st4k3r

## How It Works

1. The `ParquetExploitGenerator` writes a `.parquet` file with an embedded Avro schema.
2. The schema defines a record field (`trigger`) of type `exploit.PayloadRecord` with a default value `{}`.
3. When the `ParquetVictim` application reads the file using `AvroParquetReader`, it applies the default value.
4. If the class `exploit.PayloadRecord` is available in the classpath, Avro will instantiate it, causing the static block to execute.

## Important

This exploit **will not work** unless the victim application:
- Uses Avro to deserialize schemas and apply default values.
- Has the class `exploit.PayloadRecord` available in the runtime classpath.
- Reads the field that contains the default value.

## Compilation & Execution

1. Compile the payload:
   ```
   javac -d out payload/exploit/PayloadRecord.java
   ```

2. Compile the generator:
   ```
   javac -cp "libs/*" -d out generator/ParquetExploitGenerator.java
   ```

3. Compile the victim:
   ```
   javac -cp "libs/*:out" -d out victim/ParquetVictim.java
   ```

4. Generate the malicious Parquet file:
   ```
   java -cp "libs/*:out" generator.ParquetExploitGenerator
   ```

5. Run the victim app with the payload class in the classpath:
   ```
   java -cp "libs/*:out" victim.ParquetVictim
   ```

## Real-World Implication

In a real-world scenario, an attacker would:
- Generate a malicious `.parquet` file.
- Deliver it to a target system that deserializes Avro schemas.
- Exploit the fact that the target has certain classes already loaded (e.g., internal config classes or forgotten debug code).
- Cause class instantiation and arbitrary code execution through static blocks or constructors.

This PoC is for educational and authorized research purposes only.

## Is This PoC Fake?

No β€” this Proof of Concept is not fake. It demonstrates a real technique to exploit CVE-2025-30065. However, like many deserialization-based exploits, it is not a standalone "one-click" exploit. It requires certain conditions to be met on the victim system in order to work.

## What’s Missing?

This PoC focuses on generating a malicious Parquet file containing a crafted Avro schema. To fully trigger the vulnerability, the following conditions must be met:

1. The victim application must deserialize Avro schemas and apply default values.
2. The class referenced in the schema (e.g., exploit.PayloadRecord) must be present in the classpath.
3. The victim must not implement safeguards that prevent instantiation of arbitrary classes.

If those conditions are met, the deserialization process will instantiate the specified class, which may contain a static block that executes arbitrary code β€” this is where code execution happens.

## Summary

1. The PoC generates a real malicious payload (Parquet with Avro schema).
2. Whether it executes depends on the victim environment.
3. This is typical for exploits involving deserialization or unsafe class instantiation.

This PoC is part of a complete exploit chain β€” it is up to the researcher to simulate or observe the vulnerable behavior in a real or test environment.