Critical glibc vulnerability reported, enabling code execution with elevated privileges

A significant security vulnerability has been discovered in the GNU C Library (glibc) that could allow local attackers to execute arbitrary code with elevated privileges. This vulnerability impacts glibc versions 2.27 through 2.38, covering systems deployed between 2017 and early 2025.

The flaw is tracked as CVE-2025-4802, is caused by how statically linked setuid binaries handle library loading. It occurs when statically linked setuid binaries that call dlopen() functionality incorrectly search the LD_LIBRARY_PATH environment variable to determine which libraries to load. Under normal security operations, setuid programs should disregard environment variables that could be manipulated by unprivileged users. However, this vulnerability creates a condition where even statically linked setuid programs may honor the LD_LIBRARY_PATH setting during dynamic library loading operations.

The issue can be triggered when privileged binaries directly call dlopen(), make indirect calls through setlocale() or use Name Service Switch (NSS) functions like getaddrinfo()

The primary attack vector requires local access to the target system. An attacker would need to place a malicious shared library in a location specified by the LD_LIBRARY_PATH environment variable, then execute a vulnerable setuid binary. When the binary attempts to load a dynamic library, it could inadvertently load the attacker's malicious code with elevated privileges

While the glibc advisory notes that no vulnerable setuid programs have been identified at the time of disclosure, the potential risk remains significant, particularly for organizations with custom setuid binaries that perform dynamic library loading operations.

This vulnerability affects multiple major Linux distributions running glibc versions 2.27 through 2.38, including:

• Debian
• Ubuntu
• Rocky Linux
• other Linux distributions using the affected glibc versions

Security researcher Solar Designer has built a small proof-of-concept demonstrating the vulnerability, although it does require that this code be privileged and call a malicious LD_LIBRARY_PATH:

#include <nss.h>
#include <stdio.h>

enum nss_status _nss_myhostname_endhostent(void) {
    puts("intercepted");
    return NSS_STATUS_SUCCESS;
}

There appears to be some uncertainty about the effectiveness of the fix, as a comment from security researcher xuantong shi on May 20, 2025 indicated that even with the patch applied to glibc-2.38, a test case still showed the vulnerability.

System administrators should implement security patches provided by your Linux distribution vendor, and update glibc to version 2.39. In the meantime, isolate and lock down access to systems. 

Organizations using older Linux distributions should check with their vendors for backported patches addressing this vulnerability.