rdblue opened a new issue, #16471: URL: https://github.com/apache/iceberg/issues/16471
> 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 Path-backed catalogs derive warehouse locations from unsanitized namespace and table names, allowing path escape and destructive operations outside the intended warehouse root. In other words, a caller can choose names containing path separators or dot-segments such as `../` and have Iceberg derive storage paths from those names without first proving that the final location still sits under the configured warehouse root. # Affected Maven coordinates * primary shipped client artifact: `org.apache.iceberg:iceberg-core` # Attacker prerequisites * ability to create namespaces or tables in a path-backed catalog, or to call the equivalent REST APIs against one * a backing catalog implementation that derives storage paths from logical names and later performs create, rename, or delete operations on those derived paths # Impact * In path-backed catalogs, a caller able to create namespaces or tables can choose names containing path separators or dot-segments and thereby escape the intended warehouse root. * In `HadoopCatalog`, this is stronger than a mere placement issue because later operations such as `dropTable(..., true)` and `dropNamespace(...)` act on the derived path and can recursively delete outside the intended warehouse prefix. * In REST deployments, the same issue is remotely reachable through namespace and table creation APIs when the backing catalog is path-derived. * This is the same basic guard gap as slash-derived storage-location collisions more generally, except here it lives in Iceberg's own path derivation and delete behavior rather than only in a server-side catalog. # Proof status Source review only. The issue is visible directly from source. # Key source references * org.apache.iceberg.catalog.Namespace * org.apache.iceberg.catalog.TableIdentifier * org.apache.iceberg.BaseMetastoreCatalog * org.apache.iceberg.hadoop.HadoopCatalog * org.apache.iceberg.jdbc.JdbcCatalog * org.apache.iceberg.inmemory.InMemoryCatalog * org.apache.iceberg.rest.requests.CreateNamespaceRequest * org.apache.iceberg.rest.requests.CreateTableRequest 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: [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]
