CVE-2026-26187
Path Traversal in lakeFS Local Block Adapter Allows Unauthorized Access
Publication date: 2026-02-13
Last updated on: 2026-02-18
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| lakefs | lakefs | to 1.77.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-22 | The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-26187 is a path traversal vulnerability in the local block adapter of lakeFS, an open-source tool that turns object storage into Git-like repositories. The vulnerability arises because the function used to verify that requested file paths are within the designated storage directory only checked the path prefix without ensuring a proper path separator, allowing attackers to access sibling directories with similar names.'}, {'type': 'paragraph', 'content': 'Additionally, while the adapter checked that resolved paths stayed within the base path, it did not verify that object identifiers remained confined within their specific storage namespace. Attackers could exploit this by using path traversal sequences (like "../") in object identifiers to access files in other namespaces.'}, {'type': 'paragraph', 'content': 'This means authenticated users could read and write files outside their allowed storage boundaries, including accessing files in sibling directories or other namespaces, which they should not have permission to access.'}] [1, 2]
How can this vulnerability impact me? :
This vulnerability allows authenticated lakeFS users to read and write files outside their designated storage boundaries, including sibling directories and other namespaces.
- Exposure of sensitive data by unauthorized access to files in sibling directories or other namespaces.
- Insertion of malicious files into other namespaces, potentially compromising data integrity.
- Potential privilege escalation if writable directories are used by other services, allowing attackers to affect those services.
The vulnerability only affects deployments using the local block adapter; deployments using other storage backends like S3, GCS, or Azure are not affected.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability involves path traversal in the local block adapter of lakeFS, allowing authenticated users to read and write files outside their designated storage boundaries by exploiting insufficient path prefix checks and namespace escapes.'}, {'type': 'paragraph', 'content': 'Detection involves verifying if your lakeFS deployment uses the local block adapter and if it is running a version prior to 1.77.0.'}, {'type': 'paragraph', 'content': "To detect exploitation attempts or presence of the vulnerability, you can monitor for unusual file access patterns or attempts to access sibling directories or cross-namespace files using path traversal sequences such as '../' in object identifiers."}, {'type': 'paragraph', 'content': 'Suggested commands include searching lakeFS logs or filesystem access logs for suspicious path traversal patterns. For example, using grep to find path traversal attempts in logs:'}, {'type': 'list_item', 'content': "grep -r '\\.\\./' /path/to/lakefs/logs"}, {'type': 'list_item', 'content': "grep -r 'lakefs_evil' /path/to/lakefs/logs"}, {'type': 'paragraph', 'content': 'Additionally, you can check the installed lakeFS version with:'}, {'type': 'list_item', 'content': 'lakectl version'}, {'type': 'paragraph', 'content': 'If the version is older than 1.77.0 and the local block adapter is used, the system is vulnerable.'}] [1, 2]
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade lakeFS to version 1.77.0 or later, where the vulnerability is fixed by enforcing strict two-level path validation to prevent path traversal and namespace escapes.
If immediate upgrade is not possible, consider the following workarounds:
- Configure the storage path with a unique name that is unlikely to be a prefix of other directories to prevent prefix bypass.
- Restrict filesystem permissions for the lakeFS process to limit access to only the designated storage directories.
- Ensure no sensitive data exists in sibling directories that could be accessed via path traversal.
Monitoring and logging suspicious access attempts can also help detect exploitation attempts until the patch is applied.