CVE-2026-6844

What it actually does

This vulnerability affects the GNU binutils `readelf` utility when parsing specially crafted ELF files. A malicious local file can trigger excessive memory consumption, causing an out-of-memory condition, or trigger a null pointer dereference that causes `readelf` to crash with a segmentation fault. The flaw does not provide code execution or data access by itself; its impact is availability loss for processes, scripts, CI/CD jobs, malware scanners, package inspection workflows, or administrative tooling that invoke `readelf` on untrusted ELF files.

Why it matters to the business

Organizations that rely on binutils, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, Red Hat hardened images, or related build and inspection workflows may experience failed scans, interrupted build pipelines, crashed analysis jobs, or degraded host/container availability if malicious ELF files are processed. The CVSS score indicates moderate severity, EPSS is very low, and it is not listed in CISA KEV or known ransomware use, so this is generally a patch-management and hardening issue rather than an emergency internet-facing incident. However, the operational impact can be meaningful in environments that automatically analyze third-party binaries, container images, uploaded executables, firmware, or malware samples.

How an attack unfolds

An attacker first obtains a path for a crafted ELF file to be processed by `readelf`; this may be through a local account, a source repository, package upload, CI artifact, container image, firmware bundle, security scanning queue, or analyst workflow. When a user or automated process invokes `readelf` against the malformed file, vulnerable parsing logic mishandles the input. Depending on the crafted structure, `readelf` either consumes excessive memory until the process or host is constrained, or dereferences a null pointer and terminates with a segmentation fault. The attacker’s practical goal is to disrupt automated analysis, cause build or scan failures, exhaust worker resources, or repeatedly crash tooling that processes untrusted ELF content.

How to fix it

Upgrade GNU binutils packages to the vendor-provided fixed release when available for the affected distribution or product. Because no exact fixed versions were provided in the input, track and apply security advisories from GNU binutils and downstream vendors, especially Red Hat advisories for Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images. Rebuild container images and base images after patched packages are available. Where immediate patching is not possible, reduce exposure by avoiding automated `readelf` processing of untrusted ELF files, running binary-inspection jobs in memory-limited sandboxes or containers, applying process resource limits, and isolating CI/scanning workers from critical services. Use job timeouts, cgroup memory limits, and non-privileged execution for tooling that parses unknown binaries.

How to confirm the fix worked

Confirm remediation by checking the installed binutils package version against the relevant vendor advisory for each operating system, container image, and build/scanning environment. Verify that rebuilt images no longer include vulnerable binutils packages. Run package-manager checks such as `rpm -q binutils`, `dnf updateinfo list --security`, `dnf updateinfo info`, or the equivalent distribution tooling. For containers, inspect image package inventories with an SBOM or image scanner after rebuild. Validate compensating controls by confirming that binary-analysis jobs run with memory limits, timeouts, and non-privileged permissions, and that failures in `readelf` do not affect host availability or critical pipelines.

Typical attack path

1. Prepare a malformed ELF file designed to trigger the resource-exhaustion or null-pointer-dereference condition in vulnerable `readelf` versions.
2. Place or submit the ELF file where it will be inspected, such as a repository, package, container image, upload portal, malware-analysis queue, build artifact, or local filesystem accessible to a user.
3. Wait for a person, script, CI/CD job, scanner, or administrative tool to run `readelf` against the crafted file.
4. Cause `readelf` to crash with a segmentation fault or consume excessive memory until killed or stalled.
5. Use the resulting failure to interrupt analysis, block builds, degrade scanning capacity, or create repeated denial-of-service conditions.

How to detect it

Review endpoint, system, CI/CD, container runtime, and application logs for crashes or abnormal termination of `readelf`, especially after processing newly submitted or untrusted ELF files. Relevant sources include Linux syslog or journald, kernel logs, auditd process-execution logs, CI worker logs, container logs, image-scanning logs, malware-analysis platform logs, package-ingestion logs, and EDR telemetry. Look for `readelf` segmentation faults, core dumps, out-of-memory killer events, repeated job failures involving ELF parsing, or unusually high memory usage by `readelf`. Correlate events with recently introduced files, repositories, packages, container layers, firmware images, or user uploads. If suspicious activity is found, preserve the ELF file, the command line used to invoke `readelf`, job logs, core dumps if available, and surrounding process telemetry. There are no public threat actors or known exploitation campaigns provided for this issue, so detection should focus on behavior rather than actor-specific infrastructure.

• readelf
• segfault at
• comm="readelf"
• Command line: readelf
• Out of memory: Killed process
• Killed process readelf
• Memory cgroup out of memory
• core dumped
• readelf: Segmentation fault
• Segmentation fault (core dumped)
• kernel: readelf
• audit:.*readelf
• /usr/bin/readelf
• /bin/readelf

What your security team should do

• Inventory systems, base images, CI workers, scanning appliances, and containers that include GNU binutils or invoke `readelf`.
• Prioritize patching where `readelf` processes untrusted ELF files, such as CI/CD pipelines, package ingestion, malware analysis, firmware review, container scanning, and upload-processing workflows.
• Apply vendor fixes for binutils as soon as they are released for the affected platforms; rebuild and redeploy dependent container images and hardened images.
• Until patched, sandbox `readelf` execution with strict memory limits, CPU/time limits, non-root users, and isolated worker nodes.
• Add monitoring for repeated `readelf` crashes, segmentation faults, out-of-memory kills, or unusual memory spikes in build and scanning infrastructure.
• Treat repeated malformed-ELF crashes in automated inspection workflows as potentially malicious activity and preserve the triggering files for forensic analysis.
• Because EPSS is currently very low and there is no KEV or ransomware linkage, schedule remediation according to normal vulnerability-management SLAs unless the utility is exposed to untrusted file processing at scale.