Planning handles and idempotency keys are not normatively bound to principal, route, or request body

[rdblue]

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

[RussellSpitzer]

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.

[rdblue]

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.