CVE-2026-26187: 
NixOS vulnerability analysis and mitigation

CVE-2026-26187 describes two path traversal vulnerabilities in the lakeFS local block adapter that allow authenticated users to read and write files outside their designated storage boundaries. The vulnerability affects lakeFS versions up to and including 1.76.0, and was disclosed on February 12, 2026, with a patch released the same day in version 1.77.0. It carries a CVSS v3.1 base score of 8.1 (High), reflecting network-accessible exploitation requiring only low-privilege credentials (GitHub Advisory). Only deployments using the local block adapter are affected; S3, GCS, Azure, and other object storage backends are not impacted (GitHub Security Advisory).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), manifesting in two distinct flaws within pkg/block/local/adapter.go. First, the verifyRelPath function used strings.HasPrefix() without appending a path separator, allowing access to sibling directories whose names share a prefix with the storage directory (e.g., /data/lakefs_evil/ bypasses a check for /data/lakefs). Second, the extractParamsFromObj function validated that resolved paths stayed within the adapter's base path but did not verify that object identifiers remained within their designated storage namespace, enabling ../-style traversal in object identifiers (e.g., identifier ../../other-repo/data.txt with namespace local://repo1/userdata resolves outside the namespace). The vulnerability was discovered via CodeQL static analysis (GitHub Advisory, Patch Commit).

Successful exploitation allows authenticated attackers to read sensitive data from other repositories and namespaces within the same lakeFS deployment, write malicious files to other namespaces or adjacent directories outside lakeFS storage, and potentially escalate privileges if writable directories are used by other services on the host. Both confidentiality and integrity are rated High, as an attacker can exfiltrate data from sibling repositories and inject arbitrary content into other namespaces. Availability is not directly impacted (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.047% (21st percentile), indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires valid lakeFS credentials (low privilege), network access, and a deployment using the local block adapter.

1. Reconnaissance: Identify a lakeFS deployment configured with the local block adapter (not S3/GCS/Azure). Obtain valid lakeFS credentials with at least low-privilege access to one repository/namespace.
2. Exploit Vulnerability 1 (Prefix Bypass): Craft a storage namespace path that shares a prefix with the configured base path but targets a sibling directory (e.g., if base is /data/lakefs, target local://../lakefs_backup/ to access /data/lakefs_backup/). Submit object read/write requests using this namespace.
3. Exploit Vulnerability 2 (Namespace Escape via Identifier): Using a legitimate namespace (e.g., local://repo1/userdata), craft an object identifier containing ../ sequences to escape the namespace (e.g., identifier ../../other-repo/secret.txt resolves to /data/lakefs/other-repo/secret.txt, outside the user's namespace).
4. Read Sensitive Data: Issue a GET object request with the traversal identifier to read files from other namespaces or sibling directories, including data from other repositories or host filesystem paths accessible to the lakeFS process.
5. Write Malicious Files: Issue a PUT object request with a traversal identifier to write attacker-controlled content into other namespaces or adjacent directories, potentially overwriting configuration files or injecting malicious payloads used by other services (GitHub Advisory, Patch Commit).

• Logs: lakeFS API access logs showing object GET/PUT requests with identifiers containing ../ sequences or URL-encoded equivalents (%2e%2e%2f); requests referencing namespaces with path prefixes matching but not equal to the configured storage base path.
• File System: Unexpected files appearing in sibling directories adjacent to the lakeFS storage base path (e.g., directories named similarly to the storage path but with different suffixes); new or modified files in namespaces not associated with the requesting user's repository.
• Network: Authenticated API calls to lakeFS object endpoints (e.g., /api/v1/repositories/{repo}/refs/{ref}/objects) with anomalous object key parameters containing traversal sequences from low-privilege accounts accessing multiple repositories.

Upgrade lakeFS to version 1.77.0 or later, which fixes both vulnerabilities by appending a path separator to prefix checks and adding two-level path validation (namespace within adapter base path, and resolved path within namespace) (lakeFS v1.77.0 Release). For deployments unable to patch immediately, switch to S3, GCS, Azure, or another object storage backend, as the vulnerability exclusively affects the local block adapter. Additional workarounds include configuring the storage path with a unique name unlikely to be a prefix of other directories, restricting filesystem permissions for the lakeFS process, and ensuring no sensitive data exists in sibling directories (GitHub Security Advisory).

The vulnerability was discovered via CodeQL static analysis and reported by researcher nopcoder, with the advisory published by N-o-Z on February 12, 2026 (GitHub Advisory). Community coverage appeared on security aggregation sites and blogs shortly after disclosure, including a write-up titled "Escaping the Lake with a Path Traversal Two-Step" on dev.to. No major vendor statements beyond the official GitHub advisory have been identified.