Vended ADLS credential selection collapses to storage-account granularity and ignores delegated prefixes

[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

Vended ADLS credentials are resolved per storage account rather than
per delegated prefix, so same-account path boundaries are not enforced
client-side.

Affected Maven coordinates

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

Attacker prerequisites

• control over a path, prefix, batch, or file list that sits adjacent
  to a legitimately scoped prefix
• ability to trigger the credential-selection or cleanup path with
  that crafted input

Impact

• Once a SAS token is selected for a storage account, Iceberg has no
  client-side prefix containment check left inside that account.
• If an upstream catalog or storage-location bug steers requests to
  another path in the same account/container, this client path will
  still attach the same SAS token.
• That makes server-side location mistakes more dangerous and also
  prevents safe use of multiple delegated prefixes within one storage
  account.

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.adlsv2.VendedAdlsCredentialProvider
• org.apache.iceberg.azure.adlsv2.VendedAzureSasCredentialPolicy
• org.apache.iceberg.azure.adlsv2.ADLSFileIO

[rdblue]

Closing this as a duplicate. #13050 is open for supporting multiple prefixes.