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: [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