Restore/state paths still accept Java object deserialization

[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

Several Flink restore paths still accept Java object deserialization,
keeping savepoint and checkpoint restore tied to gadget-friendly
formats.

Affected Maven coordinates

• versioned integration artifacts:
  org.apache.iceberg:iceberg-flink-1.20,
  org.apache.iceberg:iceberg-flink-2.0,
  org.apache.iceberg:iceberg-flink-2.1

Attacker prerequisites

• a path that delivers untrusted serialized bytes into the affected
  Java deserialization surface
• the affected Iceberg type on the classpath of the target process

Impact

• Restoring from tampered or untrusted savepoints/checkpoints expands
  the attack surface to Java deserialization gadgets and unexpected
  class graphs.
• Even if the deployment treats checkpoint storage as trusted, this
  remains a risky parser choice for a state format boundary.

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.flink.sink.WriteResultSerializer
• org.apache.iceberg.flink.source.split.IcebergSourceSplit
• org.apache.iceberg.flink.source.split.IcebergSourceSplitSerializer

[rdblue]

I don't think it is reasonable to presume attacker-controlled savepoint or checkpoint data. And even then, this is another deserialization problem that allows an attacker to cause a constructor call, but not pass data to it or inject a malicious class. I don't think this is a valid security issue and will close it.

[RussellSpitzer]

I did see some Flink CVES slightly related to this, but i'm going to have to agree that if you can write to savepoint or checkpoint data as an attacker you can do probably much worse things.