When a vulnerable, statically linked setuid binary invokes the dlopen() function to load a shared object by name rather than an absolute path, it inadvertently respects the user-controlled LD_LIBRARY_PATH. An attacker can place a malicious shared object with a matching filename in a directory of their choosing, set the environment variable to point to that directory, and achieve arbitrary code execution with root privileges upon execution of the binary. This flaw poses a significant risk to Linux systems utilizing older glibc versions and custom setuid binaries.

Attack Chain

1. Attacker identifies a statically linked setuid-root binary on the target system that utilizes the dlopen() function.
2. Attacker prepares a malicious shared object file (.so) designed to execute a root shell or payload when loaded.
3. Attacker places the malicious shared object into a directory accessible by their low-privileged user account.
4. Attacker sets the LD_LIBRARY_PATH environment variable to point to the directory containing the malicious shared object.
5. Attacker executes the vulnerable setuid binary.
6. The binary fails to sanitize the environment variable due to static linking and searches for the shared object in the attacker's path.
7. The binary loads and executes the attacker's malicious code instead of the legitimate library.
8. Attacker gains full root privileges on the compromised system.

Impact

Successful exploitation of CVE-2025-4802 results in local privilege escalation, allowing an unprivileged user to execute code as root. This vulnerability affects a wide range of Linux distributions utilizing glibc 2.27 through 2.38. If exploited, an attacker could compromise system integrity, access sensitive data, or establish persistence at the highest privilege level on the affected host.

Recommendation

Prioritized actions for security teams:

• Patch glibc on all vulnerable systems to a version greater than 2.38 as a priority.
• Audit custom setuid binaries within the environment to identify those statically linked that utilize dlopen().
• Enforce the use of absolute paths for all calls to dlopen() in existing codebases to prevent library hijacking.
• Refactor applications to drop privileges before calling dynamic loading functions if possible.
• Apply compiler hardening flags and avoid setuid bits on binaries where alternative privilege management (e.g., capabilities) can be used.