5 ms·
Max severity RCE flaw discovered in widely used Apache Parquet
- gnabgib 2y agoOriginal source: https://www.endorlabs.com/learn/critical-rce-vulnerability-in-apache-parquet-cve-2025-30065---advisory-and-analysis https://www.endorlabs.com/learn/critical-rce-vulnerability-i...
- foolswisdom 2y agoNote that the vulnerability applies to the Java library (or systems that use it, like Spark),as mentioned in the original source.
- formerly_proven 2y agoAs per the PoC, yes — this is the usual Java Deserialization RCE where it’ll instantiate arbitrary classes. Java serialization really is a gift that keeps on giving.
- stefan_ 2y agoI love how these always instantly escalate into trivial code execution / reverse shell. Remember kids, C is the enemy! The "fix" in question also screams "delete this crap immediately": https://github.com/wgtmac/parquet-mr/commit/d185f867c1eb968ac6de5024c70de2aa3b923ec2 https://github.com/wgtmac/parquet-mr/commit/d185f867c1eb968a...
- pclmulqdq 2y agoThis is a bug in Java. Java is considered "memory safe" because of its GC and its VM. This is not a memory safety bug.
- chowells 2y agoIt's true. No memory is being used in contravention of the language semantics. Absolutely memory safe.
- hinkley 2y agoThe fix still loads the class before checking if it’s okay. That’s a smaller attack window but it’s still not zero.
- deleted 2y ago[deleted]
- ustad 2y agoDoes anyone know if pandas is affected? I serialize/deserialize dataframes which pandas uses parquet under the hood.
- natebc 2y agohttps://www.endorlabs.com/learn/critical-rce-vulnerability-in-apache-parquet-cve-2025-30065---advisory-and-analysis https://www.endorlabs.com/learn/critical-rce-vulnerability-i... > Any application or service using Apache Parquet Java library versions 1.15.0 or earlier is believed to be vulnerable (our own data indicates that this was introduced in version 1.8.0; however, current guidance is to review all historical versions). This includes systems that read or import Parquet files using popular big-data frameworks (e.g. Hadoop, Spark, Flink) or custom applications that incorporate the Parquet Java code. If you are unsure whether your software stack uses Parquet, check with your vendors or developers – many data analytics and storage solutions include this library. Seems safe to assume yes, pandas is probably affected by using this library.
- nindalf 2y agoThe paragraph you pasted in states that only applications importing the Java library are vulnerable. Isn’t pandas implemented in Python/C? How would it have been importing the Java library?
- deleted 2y ago[deleted]
- natebc 2y agoI'm sorry. I made a mistake.
- 3eb7988a1663 2y agoThat does not follow for me. Pandas does not utilize Java/JVM.
- deleted 2y ago
- 3eb7988a1663 2y agoMaybe the headline should note that this a parser vulnerability, not the format itself. I suppose that is obvious, but my first knee-jerk thought was, "Am I going to have to re-encode XXX piles of data?"
- brokensegue 2y agoWhat would it mean for the vulnerability to be in the format and not the parser?
- dist-epoch 2y agoMacros in old Microsoft Word documents were quite a popular attack.
- 3eb7988a1663 2y agoI don't know. Something like a Python pickle file where parsing is unavoidable. On a second read, I realized a format problem was unlikely, but the headline just said, "Apache Parquet". My mind might the same conclusion if it said "safetensors" or "PNG".
- jonstewart 2y agoThat data had to be encoded in a certain way which would lead to unavoidable exploitation in every conforming implementation. For example, PDF permits embedded JavaScript and… that has not gone well.
- necubi 2y agoAlso that it's in the Java parquet library, which somehow is nowhere in the article
- nikanj 2y ago"Maximum severity RCE" no longer means "unauthenticated RCE by any actor", it now means "the vulnerability can only be exploited if a malicious file is imported" Grumbling about CVE inflation
- marcusb 2y agoCVSS, at least in its current form, needs to be taken out back and shot. See, for instance, https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/ https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/
- buu700 2y agoI like the idea of CVSS, but it's definitely less precise than I'd like as-is. e.g. I've found that most issues which I would normally think of as low-severity get bumped up to medium by CVSS just for being network-based attack vectors, even if the actual issue is extremely edge case, extremely complex and/or computationally expensive to exploit, or not clearly exploitable at all.
- kevincox 2y agoBut Parquet is intended to be a safe format. So importing a malicious file should still be safe. Like if a browser had a vulnerability parsing HTML of course it is a major concern because very often browsers to parse HTML from untrusted parties.
- mr_mitm 2y agoWhy is "user interaction: none" though? There should be reasoning attached to the CVSS vector in these CVEs.
- StressedDev 2y agoProbably because there are services (AKA web services, software listening on a network port, etc.) out there which accept arbitrary Parquet files. This seems like a safe assumption given lots of organizations use micro-services or cloud venders use the same software on the same machine to process requests from different customers. This is a bad bug and if you use the affected code, you should update immediately.
- g-mork 2y agoWhen did vulnerability reports get so vague? Looks like a classic serialization bug https://github.com/apache/parquet-java/compare/apache-parquet-1.15.0...apache-parquet-1.15.1#diff-843b7d69e1ab11efea5f9cbb3cdef97018962430525040a2a5c3eed0fb5848a3R273 https://github.com/apache/parquet-java/compare/apache-parque...
- amluto 2y agoBetter link: https://github.com/apache/parquet-java/pull/3169 https://github.com/apache/parquet-java/pull/3169 If by “classic” you mean “using a language-dependent deserialization mechanism that is wildly unsafe”, I suppose. The surprising part is that Parquet is a fairly modern format with a real schema that is nominally language-independent. How on Earth did Java class names end up in the file format? Why is the parser willing to parse them at all? At most (at least by default), the parser should treat them as predefined strings that have semantics completely independent of any actual Java class.
- bri3d 2y agoThis seems to come from parquet-avro, which looks to attempt to embed Avro in Parquet files and in the course of doing so, does silly Java reflection gymnastics. I don’t think “normal” parquet is affected.
- amluto 2y agoThe documentation for all of this is atrocious. But if avro-in-parquet is a weird optional feature, it should be off by default! Parquet’s metadata is primarily in Thrift, not Avro, and it seems to me that no Avro should be involved in decoding Parquet files unless explicitly requested.
- bri3d 2y agoTo the sibling comment’s point, I suppose it’s not weird in the Java ecosystem. The parquet-java project has a design where it deserializes Parquet fields into Java representations grabbed from _other_ projects rather than either having some kind of canonical self-representation in memory or acting as just an abstract codec. So, one of the most common things to do is apparently to use the “Avro” flavored serdes to get generic records in memory (note that the actual Avro serialization format is not involved with doing that; parquet-java just uses the classes from Avro as the in memory representations and deserializes Parquet into them). The whole approach seems a bit goofy; I’d expect the library to work as some kind of abstracted codec interface (requiring the in-memory representations to host Parquet, rather than the other way around - like how pandas hosts fastparquet in Python land) or provide a canonical object representation. Instead, it’s this in between where it has a grab bag of converters that transform Parquet to and from random object types pulled from elsewhere in the Java ecosystem.
- TZubiri 2y ago[flagged]
- tptacek 2y agoBroken record, but "has a CVSS score of 10.0" is literally meaningless. In fact, over the last couple years, I've come to take vulnerabilities with very high CVSS scores less seriously. Remember, Heartbleed was a "7.5".
- marcolussetti 2y agoThat's mostly due to the switch from CVSS 2 to CVSS 3
- pclmulqdq 2y agoI am pretty convinced that CVSS has a very significant component of "how enterprise is it." Accepting untrusted parquet files without verification or exposing apache spark directly to users is a very "enterprise" thing to do (alongside having log4j log untrusted user inputs). Heartbleed sounded too technical and not "enterprise" enough.
- positr0n 2y ago> alongside having log4j log untrusted user inputs I'd think logging things like query parameters is extremely common.
- b8 2y agoA new scoring system should be made that is a better signal.
- tptacek 2y agoI think the original one did just fine: "info, low, medium, high, crit". I could even do without "crit".
- worthless-trash 2y agoI believe companies often call that the flaws impact. It is different than the cvss rating.
- lpapez 2y agoSoon to be announced "Quake PAK files identified carrying malware, critical 10/10 vulnerability"
- jtchang 2y agoIt's so dumb to assign it a CVSS score of 10. Unless you are blindly accepting parquet formatted files this really doesn't seem that bad. A vulnerability in parsing images, xml, json, html, css would be way more detrimental. I can't think of many services that accept parquet files directly. And of those usually you are calling it directly via a backend service.
- bigfatkitten 2y agoVendor CVSS scores are always inherently meaningless because they can't take into account the factors specific to the user's environment. Users need to do their own assessments.
- worthless-trash 2y agoThis comment over generalises the problem, but is inherently absurd. There are key indicators in scoring that explain the attack itself which isn't environment specific. I do agree that in most cases the deployment specific configuration affects the ability to be exploited and users or developers should analyse their own configuration.
- jeroenhd 2y agoUnless you're logging user input without proper validation, log4j doesn't really seem that bad. As a library, this is a huge problem. If you're a user of the library, you'll have to decide if your usage of it is problematic or not. Either way, the safe solution is to just update the library. Or, based on the link shared elsewhere (https://github.com/apache/parquet-java/compare/apache-parquet-1.15.0...apache-parquet-1.15.1#diff-843b7d69e1ab11efea5f9cbb3cdef97018962430525040a2a5c3eed0fb5848a3R273 https://github.com/apache/parquet-java/compare/apache-parque...) maybe avoid this library if you can, because the Java-specific code paths seem sketchy as hell to me.
- ajross 2y ago> Unless you're logging user input without proper validation, log4j doesn't really seem that bad. Most systems do log user input though, and "proper validation" is an infamously squishy phrase that mostly acts as an excuse. The bottom line is that the natural/correct/idiomatic use of Log4j exposed the library directly to user-generated data. The similar use of Apache parquet (an obscure tool many of us are learning about for the first time) does not. That doesn't make it secure, but it makes the impact inarguably lower. I mean, come on: the Log4j exploit was a global zero-day!
- rini17 2y agoNever roll your own deserialization :)
- junon 2y agoThat's not the takeaway here.
- marginalia_nu 2y agoI migrated off apache parquet to a very simple columnar format. Cut processing times in half, reduced RAM usage by almost 90%, and (as it turns out) dodged this security vulnerability. I don't want to make too harsh remarks about the project, as it may simply not have been the right tool for my use case, though it sure gave me a lot of issues.
- ryan-duve 2y agoWhat "very simple columnar format" did you switch to?
- marginalia_nu 2y agohttps://github.com/MarginaliaSearch/SlopData https://github.com/MarginaliaSearch/SlopData Writeup about some of the ideas that went into it: https://www.marginalia.nu/log/a_112_slop_ideas/ https://www.marginalia.nu/log/a_112_slop_ideas/
- yencabulator 2y agoIn the parquet-java *Java implementation of Apache Parquet*. Not in the file format.