Freshness-aware table caching reuses state across config and credential boundaries

[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

Freshness-aware table caching keys on metadata location instead of the
full secret-bearing table response, so stale table-scoped credentials
and config can persist under 304.

Affected Maven coordinates

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

Attacker prerequisites

• a shared process that talks to more than one catalog or reuses
  cached table state
• ability to trigger the affected initialization or cache-reuse path

Impact

• If a REST server rotates table-scoped credentials or changes
  table-scoped config without changing the metadata location,
  freshness-aware loads can keep reusing stale auth or storage state
  until cache expiry or a metadata change.
• The most likely failure mode is availability: expired or replaced
  credentials can keep causing access failures even though the server
  would have returned fresh credentials on a full load.
• There is also a weaker security angle: revocation or narrowing of
  table-scoped credentials/config is not reflected promptly if the
  server continues to answer 304 from a metadata-only freshness model.

Proof status

Source review only. The issue is visible directly from source.

Key source references

• org.apache.iceberg.rest.RESTSessionCatalog
• org.apache.iceberg.rest.ETagProvider

[rdblue]

This was discussed when we were adding the freshness-aware feature. Only table metadata is covered by the etag. Credentials and other requested table config are not and are included for convenience. For example, to avoid a second per-table request for credentials. These also have their own refresh lifecycle. I don't think that this is a bug or security issue.