rdblue opened a new issue, #16456: URL: https://github.com/apache/iceberg/issues/16456
> This issue was reported to the private Apache Iceberg security mailing list. The submitter is being kept anonymous because the report was sent to a private list. After review, the issue is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution. > > Note: this submission was generated by AI. Please review its claims and source references carefully before acting on them. # Summary The public `Metrics` type still uses unfiltered Java deserialization and attacker-sized container allocation, so any untrusted serialization boundary reopens gadget and bomb risk. # Affected Maven coordinates * primary shipped client artifact: `org.apache.iceberg:iceberg-api` # Attacker prerequisites * This is not automatically remotely exploitable by Iceberg alone. * It becomes exploitable anywhere an application accepts serialized Java objects from an untrusted peer, cache, queue, RPC layer, or plugin boundary and permits `Metrics` on the classpath. # Impact * If untrusted bytes ever reach a Java deserialization path for `Metrics`, this code will deserialize arbitrary object graphs before type casts occur. * That creates classic Java-deserialization risk: gadget-based code execution where a vulnerable classpath exists, plus deserialization bombs and memory exhaustion. * Even absent gadget chains, `readByteBufferMap` trusts an attacker-controlled `size` and allocates a hash map to match it. # Proof status I reproduced this locally with a targeted reproducer or exploit. The observed result matches the trigger and impact described above. # Key source references * org.apache.iceberg.Metrics Current severity assessment [2]: Moderate [1] https://iceberg.apache.org/security/ [2] https://security.apache.org/blog/severityrating/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
