Cloudanix VulnDB

CVE-2026-56391

Medium · 6.1

CVSS

6.1

EPSS

0.2%

Published

Jul 24, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A common Linux text-processing tool can be crashed, and may rarely expose small pieces of memory, when it handles specially crafted text in certain modes.

Exploitation
Requires User Interaction
Attacker needs
User Interaction
Complexity
Low
Impact
Denial Of Service
Component
Application
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

GNU coreutils `uniq` contains an out-of-bounds read in multibyte character handling when `uniq` is invoked with `-w` / `--check-chars`. The vulnerable `find_field()` logic incorrectly calculates character byte lengths by repeatedly evaluating a fixed pointer rather than advancing through the input. That inflated length is later passed to `memcmp`, causing `uniq` to read past the end of the allocated input buffer. Practical impact is primarily local process crash and possible disclosure of adjacent heap memory to the command output or error-handling path, depending on allocator layout, locale, input content, and how the invoking application captures `uniq` output.

Why it matters to the business

This is a low-likelihood, local-input vulnerability in a common operating-system utility. The main operational risk is denial of service in scripts, data-processing jobs, CI pipelines, backup workflows, or applications that invoke `uniq` on attacker-controlled multibyte text with `-w` / `--check-chars`. In less common circumstances, adjacent process memory may be exposed, which could reveal fragments of sensitive data handled by the same process. It is not listed in CISA KEV, has no reported ransomware association, has low EPSS, and has no known mature public exploitation, so remediation should be handled through normal Linux package update cycles unless `uniq` is exposed through automated workflows that process untrusted input.

How an attack unfolds

An attacker must be able to influence both the input processed by GNU `uniq` and the way it is invoked, specifically requiring use of the `-w` or `--check-chars` option in a multibyte locale or with multibyte input. The attacker supplies crafted text containing multibyte sequences designed to trigger the faulty length calculation in `find_field()`. As `uniq` compares records, the inflated byte count is used in `memcmp`, which reads beyond the allocated buffer. The most likely result is a crash of the `uniq` process, interrupting the parent script or workflow. If the over-read bytes are incorporated into observable output or diagnostics, the attacker may obtain small fragments of adjacent heap memory. Exploitation is local or workflow-mediated rather than remotely exploitable by default, and there is no current evidence of active exploitation or named threat actor use.

How to fix it

Upgrade affected GNU coreutils packages to a fixed release. For the listed Red Hat package, update `coreutils-main` to `9.11-5.1.hum1` or later as provided by RHSA-2026:46515. Where vendor packages are not yet available, apply the upstream fix containing commit `d64e35a8a4c0e4608321433e0d84d917e4e36371` or use a distribution-supported backport. As a temporary mitigation, avoid invoking `uniq` with `-w` / `--check-chars` on untrusted multibyte input, normalize or validate input before processing, run data-processing jobs with least privilege, and isolate workflows that process untrusted files.

How to confirm the fix worked

Confirm installed package versions using the system package manager and verify that GNU coreutils is at or above the vendor-fixed version. On Red Hat-derived systems, check that the relevant advisory RHSA-2026:46515 has been applied and that `coreutils-main` reports `9.11-5.1.hum1` or later. Review scripts, cron jobs, CI jobs, application wrappers, and data-processing pipelines for `uniq -w` or `uniq --check-chars` usage against untrusted input. Where safe and authorized, run a regression test using representative multibyte input with `uniq -w` under the patched binary and confirm the command exits normally without sanitizer findings, crashes, or abnormal memory-read reports. For source builds, verify the presence of upstream commit `d64e35a8a4c0e4608321433e0d84d917e4e36371` or equivalent patched logic in `find_field()`.

Typical attack path

  1. Identify a script, service, job, or pipeline that invokes GNU `uniq` with `-w` or `--check-chars`.
  2. Confirm the workflow accepts attacker-controlled or externally supplied text input.
  3. Craft input containing multibyte character sequences that trigger incorrect byte-length calculation.
  4. Submit the crafted input to the workflow or execute `uniq` locally with the vulnerable arguments.
  5. Cause `memcmp` to read beyond the allocated input buffer during comparison.
  6. Observe a crash, failed job, abnormal termination, or any leaked adjacent heap bytes in captured output or logs.

How to detect it

Look for evidence that `uniq` was invoked with `-w` or `--check-chars` shortly before crashes, failed jobs, or abnormal terminations. Useful sources include shell history, auditd process execution logs, EDR telemetry, systemd journal entries, cron logs, CI/CD job logs, application worker logs, container logs, and core-dump records. Search for command lines containing `uniq -w` or `uniq --check-chars`, especially when processing files from untrusted sources. Investigate crash artifacts such as systemd-coredump entries, kernel segfault messages, abnormal exit codes, sanitizer reports, or repeated failed batch jobs involving multibyte input. If core dumps are available, preserve them and inspect whether the crashing process was `/usr/bin/uniq` and whether the command line included `-w` / `--check-chars`. Because exploitation does not produce reliable network indicators and no public exploit pattern or threat actor activity is known, detection should focus on local process execution, crashes, and suspicious crafted multibyte input submitted to affected workflows.

  • uniq -w
  • uniq --check-chars
  • /usr/bin/uniq -w
  • /usr/bin/uniq --check-chars
  • comm="uniq"
  • exe="/usr/bin/uniq"
  • COMMAND=/usr/bin/uniq
  • systemd-coredump
  • Process /usr/bin/uniq
  • segfault
  • core dumped
  • AddressSanitizer: heap-buffer-overflow
  • AddressSanitizer: heap-buffer-overread
  • heap-buffer-overflow
  • memcmp
  • find_field
  • d64e35a8a4c0e4608321433e0d84d917e4e36371
  • RHSA-2026:46515
  • coreutils-main-9.11-5.1.hum1

What your security team should do

  • Prioritize routine patching of GNU coreutils across Linux systems, with higher priority for hosts running automated data-processing, CI/CD, file-ingestion, or user-submitted-content workflows.
  • Upgrade Red Hat `coreutils-main` to `9.11-5.1.hum1` or later from RHSA-2026:46515 where applicable.
  • Inventory scripts and application code for `uniq -w` and `uniq --check-chars`, especially where input can originate from users, partners, logs, uploads, email, archives, or external feeds.
  • Temporarily remove `-w` / `--check-chars` usage or pre-validate/normalize multibyte input in workflows that cannot be patched immediately.
  • Monitor for unexpected `uniq` crashes or job failures, but do not treat this as an internet-facing emergency absent a workflow that exposes the vulnerable invocation to untrusted input.
  • Ensure batch-processing services run with least privilege and avoid handling secrets in the same process context as untrusted text-processing operations.

The record

GNU coreutils uniq is vulnerable to an out‑of‑bounds read due to incorrect handling of multibyte input when the -w (--check-chars) option is used. The find_field() function miscalculates the byte length of characters by repeatedly processing a fixed pointer instead of advancing through the input, resulting in an inflated length value. This incorrect length is later used in a memcmp operation, causing reads beyond the allocated buffer when processing crafted multibyte input. When running GNU coreutils uniq with attacker-provided arguments, this behavior leads to a crash and potential adjacent heap memory exposure. This issue has been fixed in the commit d64e35a8a4c0e4608321433e0d84d917e4e36371.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities