The Key Vault client trusts any configured vault URL and reuses ambient Azure credentials

[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 Key Vault client accepts any configured vault URL and
authenticates with ambient Azure credentials, turning mis-scoped
config into token exfiltration risk.

Affected Maven coordinates

• primary shipped client artifact: org.apache.iceberg:iceberg-azure
• bundle artifact: org.apache.iceberg:iceberg-azure-bundle

Attacker prerequisites

• control over the affected catalog response, configuration surface,
  or spec-consumed routing value
• a client or service that honors the affected configuration without
  an additional allow-list

Impact

• A malicious or mis-scoped configuration can redirect Key Vault
  authentication traffic to a non-Key-Vault endpoint.
• That can expose bearer tokens or other auth context to an
  attacker-controlled service.
• This is less exposed than the ADLS location issue because it is
  config-driven rather than metadata-driven, but it is still an
  endpoint-trust break.

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

• org.apache.iceberg.azure.AzureProperties
• org.apache.iceberg.azure.keymanagement.AzureKeyManagementClient

[rdblue]

This requires trusting a malicious catalog, so this is not exploitable and urgent.

My understanding is that the Key Vault service uses bearer tokens so this would allow an attacker to exfiltrate the client's ambient authentication token. This doesn't fit with the REST catalog model, where the ability to interact with a table is delegated from the service (which in this case is attacker-controlled) to the client. But in cases where the client has configured credentials for this service, we could address it by configuring the client to use only credentials provided by the catalog.