GHSA-7g7r-gx96-252g is a high-severity (CVSS 7.8) CWE-427 vulnerability in app-builder-lib. O3 Security confirms whether GHSA-7g7r-gx96-252g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
electron-updater: Uncontrolled search path elements within `AppImage` built by `app-builder-lib`
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
app-builder-libnpmDescription
Summary
AppImage targets built by app-builder-lib could use an empty path component when setting the LD_LIBRARY_PATH environment variable at runtime. This causes the current working directory to be added to the dynamic linker search path, which may allow an attacker to execute arbitrary code by placing a malicious shared library in the directory from which the AppImage is launched.
This vulnerability is the same class as CVE-2024-41817.
Details
The vulnerability existed in two independent code paths within app-builder-lib (toolset 1.0.0) and through upstream dependency app-builder-bin (toolset 0.0.0).
Path 1 — Modern static runtime (AppRun generated by TypeScript)
The AppRun script generated by app-builder-lib contained this line:
export LD_LIBRARY_PATH="${APPDIR}/usr/lib:${LD_LIBRARY_PATH}"
When LD_LIBRARY_PATH is not set in the environment at launch time, this evaluates to:
/path/to/app.AppDir/usr/lib:
The trailing : is treated by the dynamic linker as an empty path component, which resolves to the current working directory. If an attacker can place a malicious shared library (e.g., libfoo.so) in the directory from which the AppImage is executed, that library will be loaded in place of the legitimate one, resulting in arbitrary code execution.
The same issue affected PATH, XDG_DATA_DIRS, and GSETTINGS_SCHEMA_DIR in the same script.
export LD_LIBRARY_PATH="${APPDIR}/usr/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}"
Path 2 — Legacy FUSE2 toolset (app-builder-bin)
AppImage targets built using the legacy FUSE2 toolset (toolsets.appimage = "0.0.0") delegated AppRun script generation to the app-builder-bin Go binary, which contained the same vulnerable template:
Impact
An attacker with the ability to write files to the directory from which a vulnerable AppImage is executed can cause arbitrary shared libraries to be loaded into the application process, resulting in arbitrary code execution with the privileges of the user running the AppImage.
Affected Versions
This was fully resolved in [email protected] (commit 01b8ba979, PR #9829) when app-builder-bin was removed from the dependency tree entirely and all AppImage construction was migrated to the TypeScript implementation.
Workarounds
Set LD_LIBRARY_PATH to a non-empty value before launching the AppImage, so that the concatenation does not produce an empty path component. Alternatively, avoid running AppImage files from world-writable directories such as /tmp.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | app-builder-lib | all versions | 26.15.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for app-builder-lib. 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 app-builder-lib to 26.15.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7g7r-gx96-252g 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-7g7r-gx96-252g 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-7g7r-gx96-252g. 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-7g7r-gx96-252g in your dependencies?
O3 detects GHSA-7g7r-gx96-252g across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.