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:19 UTC
[I] Path-backed catalogs derive warehouse paths from unsanitized namespace and table names [iceberg]
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: 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] Path-backed catalogs derive warehouse paths from unsanitized namespace and table names [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue commented on issue #16471:
URL: https://github.com/apache/iceberg/issues/16471#issuecomment-4503523080
I think that the scope of this issue is limited. Path-based tables are deprecated in the spec and only left in Iceberg for people who have not been able to move off of them. This also only affects FileIO for file systems that resolve these names. I'm not concerned about the point about REST catalogs backed by FS tables since FS tables are deprecated and that is actually a path to move off of them.
The attacker would need to control the namespace and table name to read or drop, but be able to submit the request to a shared system using a shared identity. If the user were interacting with HDFS or the local FS directly with their own permissions, this would not be a problem because they could directly read or delete files. This also is not a problem in shared systems (like Trino) that assume the user's identity. It isn't a problem when a service identity has access only to the warehouse directory. And the attacker must have access to that shared query engine.
I think there could be a deployment of a shared query engine that uses an over-privileged service identity with a FS-based catalog, so this seems valid. However, I would say that we should not prioritize updating code that is already discouraged and deprecated. This is more reason not to use FS-based catalogs.
--
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] Path-backed catalogs derive warehouse paths from unsanitized namespace and table names [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue closed issue #16471: Path-backed catalogs derive warehouse paths from unsanitized namespace and table names
URL: https://github.com/apache/iceberg/issues/16471
--
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] Path-backed catalogs derive warehouse paths from unsanitized namespace and table names [iceberg]
Posted by "rdblue (via GitHub)" <gi...@apache.org>.
rdblue commented on issue #16471:
URL: https://github.com/apache/iceberg/issues/16471#issuecomment-4511875483
I'll close this for the reasons that @RussellSpitzer gave.
--
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] Path-backed catalogs derive warehouse paths from unsanitized namespace and table names [iceberg]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on issue #16471:
URL: https://github.com/apache/iceberg/issues/16471#issuecomment-4504080572
The same deployment already trusts writers on manifest `file_path` and table `location`, which can do the exact same thing. I would still close this issue: path-based catalogs are deprecated, and I don't think this is meaningfully fixable in isolation. If you're on `HadoopFileIO` (or similar), a writer can already escape the warehouse through manifest entries without needing `..` in namespace or table names.
--
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