CVE-2026-56392

What it actually does

CVE-2026-56392 is a heap-based buffer overflow in GNU coreutils `unexpand`. When `unexpand` processes attacker-controlled, very large tab stop values supplied with the `-t` option, an integer overflow can occur while calculating the heap allocation size. The wrapped allocation is smaller than intended, and later processing can write beyond the allocated heap buffer. The expected impact is local process crash and potential memory corruption; depending on allocator behavior, build hardening, and runtime memory layout, exploitation may provide a limited heap write primitive. The CVSS vector indicates local attack vector, low attack complexity, no privileges required, but user interaction or a calling workflow is required, with limited integrity and availability impact.

Why it matters to the business

This issue can cause tools or automation that invoke `unexpand` on untrusted arguments or files to crash, disrupting text-processing pipelines, package build systems, CI jobs, administrative scripts, and other Unix/Linux workflows that rely on GNU coreutils. Because exploitation is local and requires the vulnerable utility to be invoked with crafted input, broad remote compromise is not expected from the vulnerability alone. The current EPSS score is very low at 0.00149, it is not listed in CISA KEV, no ransomware use is indicated, and exploit maturity is listed as none, so remediation should be handled through normal patch management unless `unexpand` is exposed through automation that accepts untrusted parameters.

How an attack unfolds

An attacker first needs a path to influence how `unexpand` is executed, such as supplying command-line arguments or input to a script, build job, packaging workflow, file-conversion service, or developer toolchain that invokes GNU coreutils `unexpand`. The attacker provides an extremely large tab stop value using the `-t` option. During allocation-size calculation, multiplication overflows the integer type, causing `unexpand` to allocate a heap buffer smaller than required. When crafted input is then processed, the program writes past the end of that heap buffer. In common scenarios this results in a crash and denial of service for the invoking workflow. In more favorable exploitation conditions, such as predictable heap layout or weak runtime hardening, the out-of-bounds write could potentially be shaped into limited memory corruption, though no mature public exploitation is indicated by the provided data.

How to fix it

Upgrade affected GNU coreutils packages to fixed vendor versions or later. For Red Hat Enterprise Linux 8, update `coreutils` to `8.30-20.el8_10` or later as provided in RHBA-2026:47115. For the listed Red Hat `coreutils-main` package, update to `9.11-5.hum1` or later as provided in RHBA-2026:47115. Where source builds are used, ensure the fix containing commit `b60a159fdc5bfcf9988d3a4cb6f53abe8ad5d35d` is included. If immediate patching is not possible, reduce exposure by preventing untrusted users or automation inputs from controlling `unexpand -t` values, validating tab stop arguments against sane numeric limits, avoiding use of `unexpand` in security-sensitive parsing paths, and running text-processing jobs with least privilege and process isolation.

How to confirm the fix worked

Confirm installed package versions using the platform package manager and verify they meet or exceed the fixed versions: for RPM-based systems, use commands such as `rpm -q coreutils` and compare against `8.30-20.el8_10` or the applicable vendor-fixed build. Confirm vendor advisory RHBA-2026:47115 is installed where applicable. For source-based deployments, verify the deployed source or binary includes commit `b60a159fdc5bfcf9988d3a4cb6f53abe8ad5d35d` or an equivalent bounds-checking fix. Review scripts, CI definitions, file-processing services, and build pipelines for invocations of `unexpand` with user-controlled `-t` values. In a controlled non-production environment only, security teams may validate that oversized `-t` values are rejected or handled safely rather than causing a crash. Avoid running proof-of-concept inputs on production systems.

Typical attack path

1. Identify a script, service, build process, or user workflow that invokes GNU coreutils `unexpand` and accepts attacker-influenced arguments or files.
2. Supply a crafted `-t` tab stop argument containing a very large numeric value designed to trigger integer wraparound during allocation-size calculation.
3. Provide accompanying input that causes `unexpand` to process data using the undersized heap allocation.
4. Trigger an out-of-bounds heap write when `unexpand` writes beyond the allocated buffer.
5. Cause the `unexpand` process, and potentially the parent workflow, to crash; in specialized conditions, attempt to use the heap corruption for limited memory manipulation.

How to detect it

Look for evidence that `unexpand` was executed with abnormally large `-t` or `--tabs` values and then crashed. Relevant log sources include Linux auditd process execution logs, EDR command-line telemetry, shell history where appropriate, CI/CD job logs, build-system logs, container runtime logs, systemd journal entries, kernel logs, and crash reporting systems such as ABRT, apport, coredumpctl, or systemd-coredump. Search for process command lines containing `unexpand` together with `-t` or `--tabs` followed by very large numeric values. Correlate these executions with segmentation faults, aborts, heap corruption messages, core dump creation, failed build steps, or service wrapper errors. Useful artifacts include core dumps for `/usr/bin/unexpand`, journal entries showing `unexpand` terminated with `SIGSEGV` or `SIGABRT`, allocator diagnostics such as heap corruption messages, and CI logs showing failures immediately after crafted tab-stop arguments. If named threat actor intelligence is not available, treat suspicious exploitation as opportunistic or local misuse unless correlated with broader intrusion activity.

• /usr/bin/unexpand
• unexpand -t
• unexpand --tabs
• unexpand -t 999999999
• unexpand --tabs=999999999
• unexpand -t 2147483647
• unexpand --tabs=2147483647
• unexpand -t 4294967295
• unexpand --tabs=4294967295
• unexpand -t 9223372036854775807
• unexpand --tabs=9223372036854775807
• segfault at
• comm="unexpand"
• exe="/usr/bin/unexpand"
• systemd-coredump
• Process unexpand dumped core
• unexpand[
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• double free or corruption
• corrupted size vs. prev_size
• Aborted (core dumped)

What your security team should do

• Inventory systems and container images that include GNU coreutils and identify versions of `coreutils` or `coreutils-main` below the vendor-fixed releases.
• Prioritize patching systems where `unexpand` can be invoked through CI/CD jobs, build farms, file-processing workflows, multi-user shell environments, or other paths involving untrusted input.
• Deploy RHBA-2026:47115 or the applicable vendor update, and rebuild golden images, base containers, and developer/toolchain images that bundle vulnerable coreutils versions.
• Search repositories, scripts, job definitions, and service wrappers for `unexpand` usage, especially invocations that pass externally supplied `-t` values.
• Add input validation or argument allowlisting around any workflow that accepts tab stop values before passing them to `unexpand`.
• Monitor for crashes or abnormal terminations of `unexpand`, especially when command lines include unusually large `-t` values.
• Treat urgency as moderate under standard enterprise patch cycles because EPSS is low, KEV status is false, ransomware use is not indicated, and exploit maturity is none; raise priority if local users or external automation can control `unexpand` arguments.