rdblue opened a new issue, #16473:
URL: https://github.com/apache/iceberg/issues/16473

   > 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
   
   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]

Reply via email to