Remote and metadata-driven class names reach unsafe constructor loading

[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

Remote config and table metadata can pick client-side class names that
are instantiated before subtype checks, giving malicious catalogs a
client-side constructor execution primitive.

The crucial detail is that class lookup initializes the selected class
before Iceberg verifies that it implements the expected interface. By
the time the bad type is rejected, static initializers and constructor
side effects from the attacker-chosen class have already run.

Affected Maven coordinates

• primary shipped client artifact: org.apache.iceberg:iceberg-core

Attacker prerequisites

• control over a catalog or table property that selects an
  implementation class, such as file-io-impl, metrics-reporter-impl,
  rest.client.tls.configurer-impl, or write.location-provider.impl
• a target Iceberg process whose classpath already contains a gadget
  class with dangerous static-initializer or constructor side effects

Impact

• A malicious or compromised REST catalog can drive client-side
  constructor execution by returning class names such as file-io-impl,
  metrics-reporter-impl, or rest.client.tls.configurer-impl.
• A malicious table owner can do the same for writers via
  write.location-provider.impl.
• Because the chosen class is initialized during lookup and the
  constructor runs before the cast check, this is stronger than a normal
  “bad class name” failure.
  Static initializer side effects and constructor side effects from
  attacker-selected classes already present on the client classpath can
  run first.
• In practical terms, this is a client-side code-execution primitive
  against the Iceberg process when a suitable gadget class is present on
  the classpath.
  It does not load new bytecode from the network, but it can remotely
  trigger execution of existing code in the target process.

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.common.DynConstructors
• org.apache.iceberg.CatalogUtil
• org.apache.iceberg.rest.HTTPClient
• org.apache.iceberg.LocationProviders
• org.apache.iceberg.rest.responses.ConfigResponse
• org.apache.iceberg.rest.RESTSessionCatalog
• org.apache.iceberg.rest.RESTTableOperations

[rdblue]

This requires a malicious catalog or the ability to modify table metadata. The result is that a class can be loaded, but will be rejected by casts immediately. Without being able to control data passed to the constructor, passed to configure the object, or to inject malicious classes, this is not a problem. I'm closing this because this is not a vulnerability and loading custom implementations is the intended behavior.