CVE-2026-35348: uutils coreutils sort DOS Vulnerability

CVE-2026-35348 Overview

The sort utility in uutils coreutils contains a Denial of Service vulnerability that causes a process panic when the --files0-from option is used with inputs containing non-UTF-8 filenames. The implementation enforces UTF-8 encoding and utilizes expect(), causing an immediate crash when encountering valid but non-UTF-8 paths. This behavior diverges from GNU sort, which treats filenames as raw bytes. A local attacker can exploit this vulnerability to crash the utility and disrupt automated pipelines.

Critical Impact

Local attackers can trigger a denial of service condition by providing non-UTF-8 filenames, causing immediate process termination and disrupting automated workflows that depend on the sort utility.

Affected Products

• uutils coreutils (sort utility with --files0-from option)

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-35348 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-35348

Vulnerability Analysis

This vulnerability stems from improper handling of file path encoding in the Rust-based uutils coreutils implementation. When the sort utility processes filenames through the --files0-from option, it expects all input to be valid UTF-8 encoded strings. The code uses Rust's expect() method which triggers an immediate panic when this assumption is violated.

In Unix-like systems, filenames are raw byte sequences that don't require any specific encoding. While most modern systems use UTF-8, POSIX allows any byte sequence (except NUL and forward slash) as a valid filename. This creates a compatibility gap between the uutils implementation and the original GNU coreutils, which handles filenames as raw bytes without encoding assumptions.

The vulnerability is classified under CWE-248 (Uncaught Exception), as the application fails to properly handle the exception case of non-UTF-8 filenames, resulting in an uncontrolled termination.

Root Cause

The root cause is the use of expect() for UTF-8 string conversion without proper error handling for non-UTF-8 byte sequences. The Rust implementation assumes all filesystem paths can be losslessly converted to UTF-8 strings, which is incorrect on Unix systems where paths are arbitrary byte sequences. When the UTF-8 conversion fails, expect() triggers a panic rather than gracefully handling the error condition.

Attack Vector

The attack requires local access to the system. An attacker can create files with non-UTF-8 characters in their names and then invoke the sort utility with the --files0-from option pointing to a file listing these malformed paths. This causes an immediate process crash.

The exploitation scenario typically involves:

1. Creating a file with a non-UTF-8 filename (e.g., using raw byte sequences)
2. Generating a NUL-separated list containing this filename
3. Invoking sort --files0-from=<list_file> which triggers the panic

Automated pipelines and scripts that process user-supplied file listings are particularly vulnerable, as attackers could inject malicious filenames to disrupt batch processing operations.

Detection Methods for CVE-2026-35348

Indicators of Compromise

• Unexpected sort process termination with panic messages referencing UTF-8 conversion failures
• Log entries showing Rust panic traces from the uutils sort implementation
• Automated pipelines failing with abnormal exit codes from sort operations
• Presence of files with non-UTF-8 characters in filenames in processing directories

Detection Strategies

• Monitor process exit codes and stderr output from sort utility invocations for panic indicators
• Implement log analysis rules to detect Rust panic messages containing expect() or UTF-8 related errors
• Track unusual patterns of sort utility crashes in automated workflow monitoring systems
• Review pipeline logs for unexpected termination of batch processing jobs involving file sorting

Monitoring Recommendations

• Configure alerting for abnormal termination of sort processes in production environments
• Implement input validation for file listings before passing to sort utility
• Deploy process monitoring to detect repeated crash patterns indicative of exploitation attempts
• Review system logs for evidence of deliberately crafted non-UTF-8 filenames in processing directories

How to Mitigate CVE-2026-35348

Immediate Actions Required

• Switch to GNU coreutils sort utility for processing untrusted file listings
• Validate and sanitize file path inputs before passing to uutils sort
• Implement wrapper scripts that filter non-UTF-8 filenames before processing
• Monitor for updates to uutils coreutils that address this encoding issue

Patch Information

No official patch information is currently available. The vulnerability is tracked in the GitHub Issue Discussion where developers are addressing the improper UTF-8 handling. Users should monitor this issue for updates and apply fixes when released.

Workarounds

• Use GNU coreutils sort instead of uutils sort for processing files with potentially non-UTF-8 names
• Pre-filter file listings to ensure all paths are valid UTF-8 before passing to uutils sort
• Implement error handling in wrapper scripts to gracefully manage sort utility failures
• Consider using alternative file processing tools that handle raw byte filenames correctly

# Workaround: Filter non-UTF-8 filenames before processing
# This script validates UTF-8 encoding before passing to sort

# Option 1: Use GNU sort instead of uutils sort
/usr/bin/sort --files0-from=file_list.txt

# Option 2: Pre-validate filenames for UTF-8 compliance
cat file_list.txt | while IFS= read -r -d '' filename; do
  if echo "$filename" | iconv -f UTF-8 -t UTF-8 > /dev/null 2>&1; then
    printf '%s\0' "$filename"
  else
    echo "Warning: Skipping non-UTF-8 filename" >&2
  fi
done | sort --files0-from=-