GHSA-9phh-r37v-34wh
MEDIUMlakeFS vulnerable to Arbitrary JavaScript Injection via Direct Link to HTML Files
Blast Radius
github.com/treeverse/lakefsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/treeverse/lakefs | all versions | 0.106.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/treeverse/lakefs. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/treeverse/lakefs to 0.106.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9phh-r37v-34wh is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9phh-r37v-34wh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9phh-r37v-34wh. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9phh-r37v-34wh in your dependencies?
O3 detects GHSA-9phh-r37v-34wh across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.