rdblue opened a new issue, #16485: URL: https://github.com/apache/iceberg/issues/16485
> 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 REST spec allows `GET` responses that contain delegated credentials and also permits metadata-only `ETag` and `304` semantics. That creates two related problems: 1. secret-bearing responses are not normatively marked `no-store, private`, and 2. metadata-only revalidation can keep stale delegated credentials alive when table metadata is unchanged. In plain HTTP terms, the strongest path is straightforward: 1. an authenticated caller fetches a secret-bearing `loadTable` response 2. that `200 OK` body is retained by a client or intermediary 3. a later conditional request sends `If-None-Match` 4. the server returns `304 Not Modified` because the table metadata is unchanged 5. the retained secret-bearing body is reused as the current result, even if the delegated credentials should have rotated or been revoked # Why this is in scope This is not limited to the weaker claim that some shared proxy might cache authenticated `GET` responses by default. The stronger issue is that any client, SDK, gateway, ingress, service mesh, proxy, or other intermediary that retains a previous `200 OK` body and later revalidates it can be instructed to keep using that old secret-bearing body via `304`. The separate `loadCredentials` route does not remove that problem, because `loadTable` itself is secret-bearing and `304`-eligible. # Affected Maven coordinates * primary published spec artifact: `org.apache.iceberg:iceberg-open-api` # Attacker prerequisites * an authenticated caller can obtain a prior secret-bearing `loadTable`, `loadCredentials`, or planning response * a client, SDK, gateway, ingress, service mesh, proxy, or another intermediary retains and later revalidates that response, or otherwise stores such secret-bearing `GET` responses unsafely * delegated credentials or token-bearing config are present in the affected response # Impact * Primary impact: stale delegated credentials can remain usable from a retained secret-bearing response when metadata is unchanged but credentials should have rotated or been revoked. * Secondary impact: secret-bearing `GET` responses can be persisted in gateway, proxy, or cache storage and thereby broaden the at-rest exposure of credentials to infrastructure access paths such as operators, dumps, or backups. * Tertiary and weaker impact: a misconfigured or non-compliant intermediary can replay or disclose such responses across security boundaries. # Proof status Source review only. The issue is visible directly in the published spec text. # Key source references * open-api/rest-catalog-open-api.yaml * org.apache.iceberg.rest.HTTPClient * org.apache.iceberg.rest.ETagProvider Current severity assessment [2]: Important [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]
