CVE-2026-3441

What it actually does

This vulnerability is a heap-based buffer overflow / out-of-bounds read in GNU Binutils' BFD linker handling of XCOFF object files. If a vulnerable Binutils component processes a specially crafted XCOFF object file, it may read memory outside the intended heap buffer. The expected impacts are disclosure of process memory and application-level denial of service through crashes or abnormal termination. The attack requires a user or automated build process to process the malicious object file; it is not a remotely exploitable network service flaw by itself.

Why it matters to the business

Organizations using GNU Binutils directly or through platforms such as Red Hat Enterprise Linux and Red Hat OpenShift Container Platform may be exposed in developer workstations, CI/CD systems, build containers, packaging systems, and software supply-chain workflows. A successful attack could disrupt builds or expose sensitive data present in the linker process memory, such as source paths, build metadata, environment-derived secrets, or adjacent artifact contents. Current public risk indicators are relatively low: EPSS is 0.00183 with no 30-day increase, there is no known CISA KEV listing, no known ransomware association, and no mature public exploit reported. However, because Binutils is widely used in build ecosystems, untrusted object files should still be treated as potentially dangerous input.

How an attack unfolds

An attacker prepares a malformed XCOFF object file designed to trigger an out-of-bounds heap read in the Binutils BFD linker. The attacker then delivers the file through a route likely to be processed by development or build tooling, such as a source repository contribution, dependency package, archive, sample object file, build artifact, or direct file transfer. When a developer, packager, CI job, or automated analysis system invokes a vulnerable Binutils tool that uses BFD to parse or link the file, the malformed structure causes the linker to read beyond the intended heap buffer. Depending on memory layout and runtime behavior, the process may crash, generate diagnostic output, produce a core dump containing process memory, or otherwise expose sensitive information available to the process. The attacker benefits if they can retrieve crash artifacts, logs, generated outputs, or other leaked data, or if they can repeatedly trigger failures to disrupt build and release operations.

How to fix it

Update GNU Binutils packages to a vendor-provided fixed release as soon as available for the affected operating system or platform. Because no exact fixed versions were provided in the input, use the relevant vendor security advisory for GNU Binutils, Red Hat Enterprise Linux, or Red Hat OpenShift Container Platform to identify the corrected package version. Rebuild or refresh container images, CI runners, build images, SDK images, and developer base images that include vulnerable Binutils packages. Until patched, reduce exposure by avoiding processing untrusted XCOFF object files, sandboxing build and binary-analysis jobs, running linkers with least privilege, disabling or restricting core dump generation, separating untrusted artifact processing from privileged build environments, and quarantining unsolicited object files or archives before analysis.

How to confirm the fix worked

Confirm exposure by inventorying installed Binutils packages and versions across servers, developer images, CI runners, build containers, and OpenShift/RHEL base images. On RPM-based systems, check package metadata with commands such as `rpm -q binutils` and compare against the vendor advisory's fixed build. Validate container exposure by scanning image layers for Binutils packages and rebuilding images after patching. Confirm mitigation by ensuring automated jobs no longer use vulnerable images and by verifying that untrusted object-file processing occurs in isolated, non-privileged environments. Where a vendor supplies a regression test or detection signature for the malformed XCOFF parser path, run it in a controlled test environment only; do not use untrusted proof-of-concept files on production systems.

Typical attack path

1. Identify an organization or workflow that processes externally supplied object files, archives, packages, or build artifacts.
2. Create a specially crafted XCOFF object file that exercises the vulnerable BFD linker parsing path.
3. Deliver the file through a pull request, dependency package, uploaded archive, email attachment, shared artifact, or other mechanism likely to reach a developer workstation or CI/CD system.
4. Wait for a vulnerable Binutils tool to process the file during linking, inspection, packaging, or automated analysis.
5. Trigger an out-of-bounds heap read, causing memory disclosure through logs, generated output, crash reports, or core dumps, or causing the tool to terminate unexpectedly.
6. If accessible, collect leaked memory artifacts or use repeated crashes to disrupt build or packaging workflows.

How to detect it

Historical exploitation detection is difficult because this flaw is triggered by local file processing rather than a distinctive network transaction. Focus on build systems, developer workstations, CI/CD runners, package builders, artifact scanners, and container build logs. Review process execution logs for Binutils tools processing newly introduced or untrusted object files, especially XCOFF files. Look for unexplained crashes, segmentation faults, abnormal exits, core dump creation, or sanitizer reports involving Binutils components. Examine recent pull requests, dependency updates, uploaded artifacts, archives, and build inputs for XCOFF object files or unusual binary objects. If core dumps or crash reports exist, handle them as sensitive because they may contain process memory. Correlate suspicious crashes with the introduction of external artifacts and any subsequent access to crash logs, build logs, or core files.

• XCOFF
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: global-buffer-overflow
• AddressSanitizer: SEGV
• Segmentation fault
• core dumped
• ld: internal error
• bfd
• binutils
• /usr/bin/ld
• /usr/bin/objdump
• /usr/bin/readelf
• /usr/bin/nm
• /usr/bin/ar
• /var/lib/systemd/coredump/
• core.ld
• core.objdump
• core.readelf

What your security team should do

• Prioritize patching Binutils on CI/CD runners, build servers, package builders, developer base images, and container images that process third-party code or artifacts.
• Review vendor advisories for GNU Binutils, Red Hat Enterprise Linux, and Red Hat OpenShift Container Platform to identify the exact fixed package versions when available.
• Restrict or sandbox processing of untrusted object files, archives, and binary artifacts, especially files identified as XCOFF.
• Disable or tightly control core dumps from build tools because crash dumps can contain sensitive process memory.
• Add monitoring for unexpected crashes of Binutils tools such as `ld`, `objdump`, `readelf`, `nm`, `ar`, and related build processes after processing newly introduced artifacts.
• Scan source repositories, artifact stores, and upload locations for unexpected XCOFF object files or unusual binary objects submitted from untrusted sources.
• Rebuild affected container and build images after patching to prevent reintroduction through stale base images.
• Treat this as a supply-chain hardening issue despite currently low EPSS and no KEV status, because Binutils is common in build workflows.