Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Two path traversal vulnerabilities in the local block adapter allow authenticated users to read and write files outside their designated storage boundaries. Details The local block adapter in pkg/block/local/adapter.go had two path traversal vulnerabilities: 1. Prefix Bypass Vulnerability 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. Example: If the adapter is configured with base path /data/lakefs: | Path | Expected | Actual | |------|----------|--------| | /data/lakefs/valid/file.txt | Allowed | Allowed | | /data/lakefsevil/secret.txt | Blocked | Vulnerable | | /data/lakefsbackup/data.db | Blocked | Vulnerable | 2. Namespace Escape via Identifier The adapter verified that resolved paths stayed within the adapter's base path, but…
Recommended action: Upgrade to 1.77.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact LakeFS's S3 gateway does not validate timestamps in authenticated requests, allowing replay attacks. An attacker who captures a valid signed request (e.g., through network interception, logs, or compromised systems) can replay that request until credentials are rotated, even after the request is intended to expire. Patches This issue affects all versions of lakeFS up to and including v1.74.4. The vulnerability has been fixed in version v1.75.0. Users should upgrade to version v1.75.0. Workarounds Until upgraded, implement these mitigations: - Use short-lived credentials - Rotate access keys frequently and deactivate old keys. For regular requests, captured requests only work until rotation. For presigned URLs, they remain valid until the credentials used to create them are deactivated. - Network controls - Restrict S3 gateway access to trusted networks/IPs to limit where replay attacks can originate. Note: These workarounds reduce risk but do not fully eliminate the…
Recommended action: Upgrade to 1.75.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Missing authentication in the /api/v1/usage-report/summary endpoint allows anyone to retrieve aggregate API usage counts. While no sensitive data is disclosed, the endpoint may reveal information about service activity or uptime. Patches Upgrade to v1.70.1 Workarounds Any ONE of these is sufficient to block this reporting: - Disable usage reporting by setting configuration option usagereport.enabled or environment variable LAKEFSUSAGEREPORTENABLED to false. - Using load-balancer or application level firewall - blocking the request route /api/v1/usage-report/summary.
Recommended action: Upgrade to 1.71.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user can crash lakeFS by exhausting server memory. This is an authenticated denial-of-service issue. Patches This problem has been patched and exists in versions 1.49.1 and below Workarounds On S3 backends, configure or set environment variable LAKEFSBLOCKSTORES3DISABLEPRESIGNEDMULTIPART to true. References Are there any links users can visit to find out more?
Recommended action: Upgrade to 1.50.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Existing lakeFS users who have issued credentials to users who have been deleted. Creating a new user with the same username, that user will inherit all of the previous user's credentials lakeFS needs to delete user credentials upon user deletion. Patches Has the problem been patched? What versions should users upgrade to? Workarounds A possible workaround will be not to reuse usernames that were previously deleted References Are there any links users can visit to find out more?
Recommended action: Upgrade to 1.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/treeverse/lakefs >= 0.90.0, <= 1.12.0
Fixed in
1.12.1· Vendor fix available
Issue
Impact A bug in permissions validation allows a user with the ci:ReadAction permission to skip read checks when copying an object. If they additionally have read and write permission to path in the repository, they can copy an otherwise unreadable object and read it. In order to be affected and exploitable, the following conditions must ALL occur on the same user: 1. ci:ReadAction enabled for the repository. Predefined policies RepoManagementRead and RepoManagementFullAccess allow this action. 2. fs:ReadObject and fs:WriteObject enabled for some path. 3. fs:ReadObject not available for some path Such a user can use (1) to copy the unreadable object (3) to a path that they can read and write (2). At that point they can read the object copy. Patches Releases = 1.12.1 fix this issue in lakeFS. Workarounds As a workaround, use RBAC to deny ci: permissions to all users, or to all users who have limited read access. Many installations are unaffected: Installations using ACLs are not…
Recommended action: Upgrade to 1.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact S3 credentials are logged in plain text appears as part of the log message: Discovered when investigating #5862 Patches Has the problem been patched? What versions should users upgrade to? No Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? disable all logging? References Are there any links users can visit to find out more?
Recommended action: Upgrade to 0.101.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When lakeFS is configured with ALL of the following: - Configuration option auth.encrypt.secretkey passed through environment variable - Actions enabled via configuration option actions.enabled (default enabled) then a user who can configure an action can impersonate any other user. Patches Has the problem been patched? What versions should users upgrade to? Workarounds ANY ONE of these is sufficient to prevent the issue: Do not pass auth.encrypt.secretkey through an environment variable. For instance, Kubernetes users can generate the entire configuration as a secret and mount that. This is described here. Disable actions. Limit users allowed to configure actions.
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The browser renders the resulting HTML when opening a direct link to an HTML file via lakeFS. Any JavaScript within that page is executed within the context of the domain lakeFS is running in. An attacker can inject a malicious script inline, download resources from another domain, or make arbitrary HTTP requests. This would allow the attacker to send information to a random domain or carry out lakeFS operations while impersonating the victim. Note that to carry out this attack, an attacker must already have access to upload the malicious HTML file to one or more repositories. It also depends on the victim receiving and opening the link to the malicious HTML file. Patches This is fixed in lakeFS version 0.106.0 Workarounds There are no known workarounds at this time.
Recommended action: Upgrade to 0.106.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated users can send a request to delete-objects through the s3 gateway and delete files they are not authorized to delete. Patches lakeFS v0.82.0 and later Workarounds Drop specific request to the lakeFS listen port. Any request with "Authorization" header and value that starts with "AWS". References advisories/GHSA-28q9-9c3g-v3f9 For more information If you have any questions or comments about this advisory: Ask on the lakeFS Slack #help channel Email us at security@treeverse.io
Recommended action: Upgrade to 0.82.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 1. [medium] A user with write permissions to a portion of a repository may use the S3 gateway to copy any object in the repository if they know its name. 1. [medium] A user with permission to write any one of tags, branches, or commits on a repository may write all of them. 1. [low] A user with permission to read any one of tags, branches, or commits on a repository may read all of them. 1. [low] A user allowed to list objects in a repository or read repository meta-data may retrieve graveler information about the location on underlying storage of all objects stored in any commit that they can view. If the user additionally has the capability to read underlying storage, they will be able to retrieve metadata associated with all objects in that commit. For more information If you have any questions or comments about this advisory please: Email us at security@treeverse.io. Open an issue on https://github.com/treeverse/lakeFS/issues/new.
Recommended action: Upgrade to 0.53.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.