CVE-2026-26187 in lakeFS
Summary
by MITRE • 02/13/2026
lakeFS is an open-source tool that transforms object storage into a Git-like repositories. Prior to 1.77.0, the local block adapter (pkg/block/local/adapter.go) allows authenticated users to read and write files outside their designated storage boundaries. The verifyRelPath function used strings.HasPrefix() to verify that requested paths fall within the configured storage directory. This check was insufficient because it validated only the path prefix without requiring a path separator, allowing access to sibling directories with similar names. Also, the adapter verified that resolved paths stayed within the adapter's base path, but did not verify that object identifiers stayed within their designated storage namespace. This allowed attackers to use path traversal sequences in the object identifier to access files in other namespaces. Fixed in version v1.77.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/13/2026
The vulnerability described in CVE-2026-26187 affects lakeFS, an open-source platform that enables object storage to function like Git repositories. This security flaw exists in versions prior to 1.77.0 and represents a critical path traversal vulnerability within the local block adapter component. The issue stems from inadequate path validation mechanisms that fail to properly enforce storage boundaries for authenticated users. The local block adapter, located at pkg/block/local/adapter.go, serves as the core component responsible for managing file operations within the configured storage directory, making this vulnerability particularly dangerous as it directly impacts the integrity of the storage system's access controls.
The technical flaw manifests through the insufficient implementation of the verifyRelPath function which relies on strings.HasPrefix() for path validation. This approach is fundamentally flawed because it only checks for a path prefix without requiring the presence of a path separator character, creating a vulnerability that allows attackers to bypass intended access controls. The vulnerability occurs when users provide object identifiers containing path traversal sequences that can navigate to sibling directories with similar naming conventions. This weakness exists because the system validates resolved paths against the base directory but fails to validate that object identifiers themselves remain within their designated storage namespace boundaries. The lack of proper validation allows authenticated users to exploit this weakness and access files outside their intended storage boundaries, effectively breaking the isolation between different storage namespaces.
The operational impact of this vulnerability is significant as it enables authenticated attackers to perform unauthorized file access and potentially write operations across different storage namespaces. This creates a serious risk for multi-tenant deployments where isolation between different users or projects is crucial for security. Attackers can leverage this vulnerability to read sensitive data from other users' storage areas, potentially accessing confidential information, configuration files, or other critical assets. The vulnerability also enables potential write operations that could compromise data integrity and availability. Organizations using lakeFS in production environments may face data leakage, unauthorized modifications, and potential compliance violations depending on the nature of the data stored in different namespaces.
The vulnerability aligns with CWE-22 Path Traversal and CWE-770 Allocation of Resources Without Limits or Throttling, as it allows unauthorized access to resources through improper path validation and inadequate boundary checks. From an ATT&CK perspective, this vulnerability maps to T1078 Valid Accounts and T1566 Phishing, as it requires authentication to exploit but can be leveraged to escalate privileges and access unauthorized data. The fix implemented in version 1.77.0 addresses the core issue by strengthening the path validation logic to properly enforce storage boundaries and ensure that both resolved paths and object identifiers remain within their designated namespaces. Organizations should immediately upgrade to version 1.77.0 or later to remediate this vulnerability and implement proper access controls to prevent unauthorized file system access.