CVE-2025-30065 : RCE par désérialisation de schéma dans Apache Parquet

Une vulnérabilité d'exécution de code à distance de sévérité maximale dans la bibliothèque Java d'Apache Parquet permet à des attaquants d'exécuter du code arbitraire sur tout système qui lit un fichier Parquet spécialement conçu. CVSS 10.0. Affecte quasiment tous les pipelines de big data utilisant le format Parquet — Spark, Flink, Hive et les entrepôts de données cloud.

Qu'est-ce que CVE-2025-30065 ?

Apache Parquet est un format de stockage columnaire largement utilisé dans les écosystèmes de big data. Le module parquet-avro dans les versions jusqu'à 1.15.0 contient une vulnérabilité de désérialisation dans le code d'analyse de schéma. Lorsqu'une application Java lit un fichier Parquet contenant un schéma Avro spécialement conçu, l'analyseur désérialise des références de classe contrôlées par l'attaquant, entraînant une exécution de code arbitraire dans le contexte de l'application de lecture.

Ceci est particulièrement dangereux car les pipelines de données ingèrent régulièrement des fichiers Parquet provenant de sources externes : buckets S3, partenaires de données, téléversements utilisateurs, intégrations ETL. Tout pipeline qui traite des fichiers Parquet non fiables est vulnérable.

Systèmes concernés

Détails techniques

La vulnérabilité se situe dans la classe AvroSchemaConverter au sein de parquet-avro. Lors de la conversion du schéma Parquet en schéma Avro, le code traite des métadonnées de schéma pouvant contenir des noms de classe arbitraires. Ces noms de classe sont utilisés dans une instanciation réflective sans validation par liste blanche.

# Conceptual representation of vulnerable code path
public Schema convert(MessageType parquetSchema) {
    // Schema metadata can contain attacker-controlled strings
    String javaClass = parquetSchema.getField("java_class");
    // Dangerous: instantiates arbitrary class from string
    Class  clazz = Class.forName(javaClass);  // RCE here
    return clazz.newInstance();
}

# Crafted Parquet file with malicious schema (conceptual)
{
  "schema": {
    "type": "record",
    "name": "exploit",
    "fields": [],
    "java_class": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
    "avro.java.string": "[base64-encoded malicious bytecode]"
  }
}

Exploitation par chaîne de gadgets

L'attaquant crée un fichier Parquet dont les métadonnées de schéma Avro référencent une chaîne de gadgets Java — une séquence d'instanciations de classes menant finalement à une exécution de code arbitraire. Commons Collections, Spring Framework et d'autres bibliothèques Java courantes fournissent des chaînes de gadgets adaptées à cette attaque.

Qui est exposé

Toute application Java qui :

• Utilise parquet-avro version 1.15.0 ou antérieure
• Lit des fichiers Parquet provenant de sources externes ou potentiellement non fiables
• N'a pas mis en œuvre de validation de la source des fichiers

Les environnements à haut risque incluent :

• Data lakes : Buckets S3/GCS/ADLS ingérant des données de partenaires
• Plateformes analytiques : Fonctionnalités de téléversement de données en libre-service
• Pipelines ETL : Tout pipeline lisant depuis des sources de données externes
• Marketplaces de données : Plateformes distribuant des jeux de données Parquet
• Pipelines d'entraînement ML : Ingestion de données d'entraînement depuis des sources externes

Atténuation

1. Mettre à niveau parquet-java vers 1.15.1+ : Le correctif ajoute une validation par liste blanche pour les noms de classe dans les métadonnées de schéma
2. Auditer les sources de fichiers Parquet : Inventorier tous les emplacements où des fichiers Parquet entrent dans votre environnement
3. Mettre en œuvre une validation de la source des fichiers : Ne traiter que les fichiers Parquet provenant de sources vérifiées cryptographiquement
4. Exécuter les pipelines de données avec des privilèges minimaux : Limiter le rayon d'impact en s'assurant que les rôles d'exécution des pipelines disposent de politiques IAM à moindre privilège
5. Restrictions de sortie réseau : Les clusters de traitement de données devraient avoir un accès Internet sortant restreint afin de limiter l'impact post-exploitation
6. Déployer des protections contre la désérialisation Java : Des outils comme SerialKiller peuvent fournir une défense en profondeur contre les attaques de désérialisation

Capacité de détection de KENSAI

• Analyse des dépendances : Le scanner SCA de KENSAI identifie les versions parquet-avro <= 1.15.0 dans les dépendances des applications Java et les fichiers de build Maven/Gradle
• Analyse des images de conteneurs : Détecte les fichiers JAR vulnérables dans les images Docker et les déploiements Kubernetes
• Évaluation de l'exposition des pipelines : Identifie les pipelines de données dotés de points d'entrée Parquet exposés à l'extérieur
• Inventaire des actifs cloud : Cartographie les clusters EMR, les espaces de travail Databricks et les autres infrastructures de traitement de données pour l'évaluation des versions