GNU Binutils Vulnerability CVE-2026-18220 Enables Code Execution via Malicious ELF Files

A newly disclosed out-of-bounds write vulnerability in GNU Binutils’ BFD library could allow attackers to achieve arbitrary code execution simply by getting a victim to analyze a malicious binary file.

Tracked as CVE-2026-18220 and rated Important (CVSS v3.1: 7.8), the flaw resides in the DLX ELF backend and affects any tool built on the BFD framework, including staples like objdump, readelf, strip, ld, nm, and objcopy.

The vulnerability was publicly disclosed on July 29, 2026, and documented via Red Hat’s VEX advisory, with the underlying issue tracked in Bugzilla #2507670.

GNU Binutils Vulnerability

At the heart of the flaw is the dlx_rtype_to_howto() function in bfd/elf32-dlx.c, which maps ELF relocation types to internal “howto” structures used during binary processing. The function is supposed to validate relocation type values extracted via ELF32_R_TYPE(r_info) before using them as an index into the dlx_elf_howto_table[] array.

The problem lies in how the DLX relocation type space is organized. Basic types span 0–6, while extended types begin at 0x10000 and above, with a non-contiguous numbering scheme.

The switch statement’s default case fails to reject out-of-range values, allowing an attacker-controlled index to reach the array access unchecked. This is a textbook CWE-787 (Out-of-Bounds Write) condition.What elevates this from a simple crash bug to a serious exploitation vector is the demonstrated attack path.

Researchers have shown the out-of-bounds write can be leveraged through a File Stream Oriented Programming (FSOP) technique targeting glibc’s FILE structures specifically stderr to hijack control flow and ultimately invoke system(), achieving arbitrary command execution.

Because BFD-based tools are ubiquitous in software development and security operations, the attack surface is broad:

CI/CD pipelines that automatically run binary analysis on build artifacts or dependencies
Developer workstations where engineers run objdump or readelf against untrusted or third-party binaries
Automated malware analysis sandboxes that invoke binutils utilities on suspicious samples
Package build systems processing third-party source or object code

In each case, no elevated privileges are needed, just a victim opening a crafted ELF/DLX object file with a vulnerable tool. The CVSS vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates low complexity, no privilege requirement, and mandatory user interaction, consistent with a scenario in which a target must run the analysis tool against the malicious file.

Red Hat’s investigation found that its standard binutils packages across all RHEL versions (6 through 10) are not affected, because they’re compiled with platform-specific target lists rather than the --enable-targets=all flag that pulls in the vulnerable DLX backend. This also clears gdb, mingw-binutils, and current gcc-toolset packages.

However, devtoolset-12-binutils is confirmed vulnerable, since it’s built with --enable-targets=all as part of a legacy build system workaround, inadvertently compiling in the affected DLX code path.

Mitigation

Red Hat has stated that no mitigation currently meets its criteria for ease of deployment and stability. Organizations relying on devtoolset-12-binutils should treat untrusted ELF files with caution, restrict binutils usage on unvetted binaries where possible, and monitor for an upstream patch or updated errata.

Security teams running automated binary triage pipelines should audit which binutils build variant is in use, since exposure hinges entirely on whether the DLX backend was compiled in.