CVE-2026-54672

electron-updater allows for automatic updates for Electron apps. Prior to 26.15.0, 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 issue has been fixed in version 26.15.0.

electron-updater allows for automatic updates for Electron apps. Prior to 26.15.0, 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 issue has been fixed in version 26.15.0.

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:

https://github.com/develar/app-builder/blob/7004925f95d8f034fc88d7e782c9aa7583debb8e/pkg/package-format/appimage/templates/AppRun.sh#L27

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.

electron-updater allows for automatic updates for Electron apps. Prior to 26.15.0, 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 issue has been fixed in version 26.15.0.

electron-updater allows for automatic updates for Electron apps. Prior to 26.15.0, 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 issue has been fixed in version 26.15.0.

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:

https://github.com/develar/app-builder/blob/7004925f95d8f034fc88d7e782c9aa7583debb8e/pkg/package-format/appimage/templates/AppRun.sh#L27

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.

These are all security issues fixed in the heroic-games-launcher-2.22.0-4.1 package on the GA media of openSUSE Tumbleweed.