You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by "rdblue (via GitHub)" <gi...@apache.org> on 2026/05/20 21:34:08 UTC
[I] Secret-bearing GET responses remain cacheable and ETag-revalidated [iceberg]
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: issues-unsubscribe@iceberg.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org
Re: [I] Secret-bearing GET responses remain cacheable and ETag-revalidated [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue closed issue #16485: Secret-bearing GET responses remain cacheable and ETag-revalidated
URL: https://github.com/apache/iceberg/issues/16485
--
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: issues-unsubscribe@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org
Re: [I] Secret-bearing GET responses remain cacheable and ETag-revalidated [iceberg]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on issue #16485:
URL: https://github.com/apache/iceberg/issues/16485#issuecomment-4504262052
I don't think this is a security issue. The client is given credentials and may use them for as long as they remain valid. A 304 that reuses an earlier loadTable body is the same idea: this session keeps using credentials it already received, not credentials belonging to someone else. If I write a client that just takes every credential and sends them to all my friends that would also be a problem, but not an Iceberg library or spec problem.
--
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: issues-unsubscribe@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org
Re: [I] Secret-bearing GET responses remain cacheable and ETag-revalidated [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue commented on issue #16485:
URL: https://github.com/apache/iceberg/issues/16485#issuecomment-4509806205
This is not a security issue. The intended behavior of the etag is to cover just the table metadata, which was discussed when introducing the feature. It is also not a problem to use revoked or stale credentials. The services that validate those credentials will enforce security, so at best this could be an inconvenience.
Since this is the intended behavior and refresh happens through a different mechanism, I'm going to close this.
--
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: issues-unsubscribe@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org