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:26 UTC
[I] Planning handles and idempotency keys are not normatively bound to principal, route, or request body [iceberg]
rdblue opened a new issue, #16490:
URL: https://github.com/apache/iceberg/issues/16490
> 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 scan-planning API introduces `plan-id` and `plan-task` values for
server-held planning state, and the wider REST spec introduces
`Idempotency-Key` for replay suppression.
All of these values are security-significant handles.
The problem is that the published contract does not require any of
them to be bound to the authenticated principal, request path, or
request body. In a weak implementation, a leaked, guessed, or
accidentally reused handle can therefore cross user boundaries.
# Affected Maven coordinates
* published spec artifact: `org.apache.iceberg:iceberg-open-api`
* sample/reference implementation paths in `org.apache.iceberg:iceberg-core`
# Attacker prerequisites
* ability to obtain, guess, or reuse a `plan-id`, `plan-task`, or
`Idempotency-Key`
* a server implementation that keys planning state or replay state too
broadly, for example only by the presented handle or key value
# Exploit shape
* One user starts a server-side planning request or creates an
idempotent operation.
* Another user reuses or guesses the associated `plan-id`,
`plan-task`, or `Idempotency-Key`.
* If the server does not bind those values to principal, route, and
request body, the second user can fetch or cancel another user's
planning state, or suppress or replay another user's request.
# Impact
* Weak implementations can expose cross-user fetch/cancel or replay behavior.
* A guessed or leaked idempotency key can suppress or replay another
request if the server keys too broadly.
# 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
* open-api/rest-catalog-open-api.yaml
* org.apache.iceberg.rest.CatalogHandlers
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: 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] Planning handles and idempotency keys are not normatively bound to principal, route, or request body [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue commented on issue #16490:
URL: https://github.com/apache/iceberg/issues/16490#issuecomment-4510794876
This is incorrect. The `plan-id` and `plan-task` values used by server-side planning are not server-held planning state, nor are they "security significant". These could be references to server-side state (such as a database ID reference) but they could also be self-contained values to avoid requiring server-side state. For instance, `plan-task` could be a manifest location to produce tasks from. The spec is purposely flexible to allow services to implement this how they choose, but that still means that services are responsible for security. The existence of these values is far from a security issue with the spec or implementation.
For `idempotency-key`, the contract of this field is to retrieve the response for an update that was lost due to some unrelated error. The service is still responsible for identifying and authorizing the client. This is not a vulnerability.
--
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] Planning handles and idempotency keys are not normatively bound to principal, route, or request body [iceberg]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer closed issue #16490: Planning handles and idempotency keys are not normatively bound to principal, route, or request body
URL: https://github.com/apache/iceberg/issues/16490
--
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] Planning handles and idempotency keys are not normatively bound to principal, route, or request body [iceberg]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on issue #16490:
URL: https://github.com/apache/iceberg/issues/16490#issuecomment-4503824365
Not a security issue. Requires
(1) a faulty catalog server implementation (out of scope for the Iceberg library)
(2) the ability to predict or exfiltrate a planning handle. Reference code uses UUID.randomUUID() for plan-ids, so guessing is not realistic; exfiltration from the JVM would expose credentials anyway.
At best here I think we could maybe add a note to the spec, but it still feels to implicit to the feature and how the Catalog decides to handle idempotency requests. We generally leave authentication and authorization to catalog implementations; the REST spec documents bearer/OAuth and 401/403 behavior but does not define principals or require authenticated access on every deployment.
I'm going to close this out, but if anyone is legitimately confused about the contract here feel free to re-open.
--
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