CVE-2026-3442

What it actually does

This vulnerability is a heap-based out-of-bounds read in the GNU Binutils BFD linker component when parsing specially crafted XCOFF object files. If a vulnerable Binutils tool such as ld, objdump, readelf, nm, strings, or other BFD-backed utilities processes a malicious XCOFF file, the parser may read beyond the bounds of an allocated heap buffer. The most likely outcomes are process crash and application-level denial of service; because the CVSS assessment includes high confidentiality impact, some crash or diagnostic paths may also expose adjacent memory contents from the affected process. The flaw requires local processing of an attacker-supplied file and user interaction, and it does not provide direct remote code execution or integrity compromise based on the available description.

Why it matters to the business

Organizations that build, inspect, package, reverse engineer, or scan untrusted object files could experience crashes in developer tooling, CI/CD jobs, malware-analysis workflows, package validation systems, or container build pipelines. In limited cases, sensitive data present in the memory of the Binutils process could be disclosed. The current exploitation likelihood appears low: EPSS is 0.00255 and has remained essentially flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. However, because GNU Binutils is widely embedded across Linux distributions and developer ecosystems, exposure may be broad wherever untrusted compiled artifacts are automatically analyzed.

How an attack unfolds

An attacker creates a malformed XCOFF object file designed to trigger an out-of-bounds read in the BFD linker code used by GNU Binutils. The attacker then delivers the file to a target through a source repository, package submission, build dependency, email attachment, shared archive, malware sample feed, support upload, or any workflow where object files are inspected. A user or automated process runs a vulnerable Binutils-based utility against the file, such as during linking, symbol inspection, binary analysis, package scanning, or CI validation. When the vulnerable parser processes the crafted XCOFF structures, it reads beyond the heap buffer boundary. Depending on process behavior, the utility may crash, interrupting the workflow, or it may expose unintended memory content through output, diagnostics, core dumps, or crash artifacts. No named threat actors or active exploitation campaigns are currently associated with this vulnerability in the provided data.

How to fix it

Upgrade GNU Binutils packages to vendor-fixed versions as soon as they are available from the relevant Linux distribution, container base image, or platform vendor. No exact fixed versions were provided in the input, so remediation should follow official advisories for GNU Binutils, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and any downstream images or toolchains that package Binutils. Rebuild container images, developer workstations, CI runners, build agents, and analysis environments after applying updated packages. Where immediate patching is not possible, reduce exposure by preventing automated processing of untrusted XCOFF object files, isolating binary-analysis and build jobs in disposable sandboxes, disabling core dump collection for sensitive environments, limiting access to crash artifacts, and treating object files from external sources as untrusted input.

How to confirm the fix worked

Confirm installed Binutils package versions against the vendor advisory or package changelog for this issue. On Linux systems, inventory packages using distribution tooling such as rpm, dnf, yum, apt, dpkg, or container image scanners, and verify that affected images have been rebuilt from patched base layers. Validate CI/CD runners, build containers, developer images, and security-analysis sandboxes separately, as they often carry independent toolchain copies. As a functional check, process a known benign XCOFF file with the patched tools and verify normal operation; avoid using untrusted proof-of-concept files outside a controlled sandbox. Confirm that vulnerable packages are absent from software bills of materials and container scan results after remediation.

Typical attack path

1. Identify an organization or workflow that processes untrusted or third-party object files using GNU Binutils or BFD-backed tooling.
2. Craft a malicious XCOFF object file that exercises the vulnerable BFD linker parsing path.
3. Deliver the file through a channel likely to be processed, such as a repository pull request, build artifact, package upload, archive, malware sample, or support attachment.
4. Trigger processing by a vulnerable Binutils utility during linking, inspection, scanning, or analysis.
5. Cause the affected utility to crash or potentially disclose heap memory through output, error handling, or crash artifacts.
6. Use the denial of service to disrupt build or analysis operations, or review exposed artifacts for sensitive information if memory disclosure occurs.

How to detect it

Look for evidence that vulnerable Binutils utilities crashed or behaved abnormally while processing XCOFF object files or recently received binary artifacts. Relevant log sources include CI/CD job logs, build system logs, package-ingestion logs, artifact-scanning logs, malware-analysis sandbox logs, Linux system journals, auditd process execution logs, endpoint detection telemetry, kernel crash messages, and core dump managers such as systemd-coredump or ABRT. Investigate crashes involving BFD-backed utilities including ld, objdump, readelf, nm, strings, size, strip, addr2line, ar, ranlib, and related prefixed cross-toolchain variants. Correlate crashes with object files from external repositories, pull requests, package uploads, email attachments, shared archives, or malware feeds. Review generated core dumps, stderr output, and build logs for unintended memory disclosure, but handle crash artifacts as sensitive because they may contain process memory. Since there are no provided actor-specific indicators, detection should focus on behavioral evidence: tool crashes, segmentation faults, heap-buffer-overflow reports from sanitizers, abnormal exits after opening XCOFF files, and repeated failures tied to the same submitted artifact.

• Segmentation fault.*ld
• Segmentation fault.*objdump
• Segmentation fault.*readelf
• Segmentation fault.*nm
• Segmentation fault.*strings
• Segmentation fault.*strip
• Segmentation fault.*addr2line
• Segmentation fault.*bfd
• core dumped.*ld
• core dumped.*objdump
• core dumped.*readelf
• core dumped.*nm
• systemd-coredump.*ld
• systemd-coredump.*objdump
• systemd-coredump.*readelf
• systemd-coredump.*nm
• abrt.*ld
• abrt.*objdump
• abrt.*readelf
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow.*bfd
• out-of-bounds read.*bfd
• bfd.*XCOFF
• xcoff.*Segmentation fault
• BFD:.*xcoff
• ld:.*file format not recognized
• objdump:.*file format not recognized
• readelf:.*Error: Not an ELF file

What your security team should do

• Prioritize patching systems and containers that automatically process externally supplied object files, archives, source packages, or binary samples.
• Inventory GNU Binutils across Linux hosts, developer workstations, CI/CD runners, build images, container base images, and malware-analysis or reverse-engineering environments.
• Track vendor advisories for GNU Binutils, Red Hat Enterprise Linux, and Red Hat OpenShift Container Platform to identify the exact fixed package versions for each platform.
• Apply compensating controls until patched: sandbox file analysis, restrict untrusted artifact ingestion, disable or protect core dumps, and limit access to build and crash logs.
• Add monitoring for repeated crashes of Binutils tools after processing object files, especially files with XCOFF characteristics or files from external contributors.
• Review recent CI, package-ingestion, and analysis failures for abnormal Binutils crashes that coincide with processing newly received object files.
• Treat exploitation urgency as moderate rather than emergency unless the organization routinely processes untrusted binary artifacts; EPSS is low, trend is flat, and there is no KEV or ransomware signal in the provided data.