`Metrics` performs unsafe Java deserialization on a public serializable type

[rdblue]

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

[rdblue]

I'm going to close this because it is not a security risk to Iceberg. It requires applications to accept and deserialize untrusted Java serialized data, which is already unsafe.