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:33:01 UTC
[I] Metastore-controlled `metadata_location` is trusted without provenance checks [iceberg]
rdblue opened a new issue, #16466:
URL: https://github.com/apache/iceberg/issues/16466
> 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
BigQuery metastore state can point `metadata_location` at arbitrary
Iceberg metadata, and later purge operations will delete files
referenced by that foreign metadata.
Once the catalog trusts that pointer, a routine `loadTable` or
`refresh` reads foreign metadata with the catalog's `FileIO`
credentials. If an operator later runs `dropTable(..., true)`, the
same poisoned pointer drives deletion of whatever files the foreign
metadata references.
# Affected Maven coordinates
* primary shipped client artifact: `org.apache.iceberg:iceberg-bigquery`
# Attacker prerequisites
* ability to create or modify BigQuery table metadata that the Iceberg
BigQuery catalog will trust, especially `metadata_location` and
`table_type`
* catalog `FileIO` credentials that can reach the foreign metadata
location and any files referenced from it
# Impact
* A principal that can create or modify BigQuery metastore table
resources can point a table at any Iceberg metadata JSON reachable by
the catalog's `FileIO` credentials.
* A normal `loadTable` or `refresh` then becomes a read primitive
against that location.
* A later `dropTable(..., true)` becomes a delete primitive for all
files referenced by that foreign metadata.
# 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.gcp.bigquery.BigQueryMetastoreClientImpl
* org.apache.iceberg.gcp.bigquery.BigQueryTableOperations
* org.apache.iceberg.BaseMetastoreTableOperations
* org.apache.iceberg.gcp.bigquery.BigQueryMetastoreCatalog
* org.apache.iceberg.io.ResolvingFileIO
* org.apache.iceberg.CatalogUtil
Current severity assessment [2]: Important
[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] Metastore-controlled `metadata_location` is trusted without provenance checks [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue commented on issue #16466:
URL: https://github.com/apache/iceberg/issues/16466#issuecomment-4503130891
I think that this report relies on an attacker that has the ability to create or modify a table in the BigQuery metastore. Then this will lead to BigQuery vending credentials. The result appears to be either that anyone with the ability to load the table will be able to use the vended credentials, or that dropping the table will cause either the client or BigQuery to delete data.
The attack surface area appears to be entirely within BigQuery, which I would expect to enforce privileges to lock down who can alter `metadata_location` and to validate the metadata that is set. Catalogs also typically associate storage locations with tables and only vend credentials for those locations, which prevents attacks like this from succeeding because the credential doesn't have access to read or delete the arbitrary locations that the attacker pointed metadata to.
There are quite a few concerns over how BigQuery may or may not function, but I don't think any of these are real issues with the Iceberg client. These are design concerns for the catalog. I'm going to close this because Iceberg is not the right place to ask these questions.
--
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] Metastore-controlled `metadata_location` is trusted without provenance checks [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue commented on issue #16466:
URL: https://github.com/apache/iceberg/issues/16466#issuecomment-4511933567
Yeah, it's hard to tell with some of the ones like this exactly what the final problem would be. Either way, I think this is just not a risk.
--
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] Metastore-controlled `metadata_location` is trusted without provenance checks [iceberg]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on issue #16466:
URL: https://github.com/apache/iceberg/issues/16466#issuecomment-4504025509
I took this a bit more generally. This is basically the way Iceberg is expected to act with all catalogs. If a principal in any catalog (hive, JDBC, rest ) or what not can change "metadata_location" they can change the table and thus have write access to the table. So this is completely expected from my view.
--
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] Metastore-controlled `metadata_location` is trusted without provenance checks [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue closed issue #16466: Metastore-controlled `metadata_location` is trusted without provenance checks
URL: https://github.com/apache/iceberg/issues/16466
--
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