CVE-2026-35375
Logic Error in uutils coreutils split Causes Filename Corruption
Publication date: 2026-04-22
Last updated on: 2026-05-04
Assigner: Canonical Ltd.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| uutils | coreutils | to 0.8.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-176 | The product does not properly handle when an input contains Unicode encoding. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a logic error in the split utility of uutils coreutils. It occurs when the utility processes non-UTF-8 prefix or suffix inputs for output filenames. The implementation uses to_string_lossy() to construct chunk filenames, which replaces invalid byte sequences with the UTF-8 replacement character (U+FFFD). This differs from GNU split, which preserves the raw pathname bytes without modification.
As a result, in environments that use non-UTF-8 encodings, the output filenames become corrupted. This can cause issues such as filename collisions, broken automation processes, or misdirection of output data.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in the uutils/coreutils split utility causes corruption of output filenames when non-UTF-8 prefix or suffix inputs are used, leading to filename collisions, broken automation, or misdirected output data.
However, there is no information provided in the context or resources about how this vulnerability specifically impacts compliance with common standards and regulations such as GDPR or HIPAA.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking if the uutils/coreutils split utility produces output files with corrupted or replaced characters in filenames when using non-UTF-8 prefix or suffix inputs.
A practical way to detect the issue is to run the split command with non-UTF-8 byte sequences in the prefix or suffix and observe the resulting filenames.
- Create a test file, for example: `echo 'test data' > testfile`
- Run split with a non-UTF-8 prefix or suffix, for example using byte sequences that are invalid in UTF-8: `split --additional-suffix=$'\xFF' testfile output_prefix`
- Check the generated filenames with `ls -b` to see if invalid bytes are replaced by the UTF-8 replacement character (οΏ½) or preserved as raw bytes.
If the filenames contain replacement characters instead of the original bytes, the vulnerable version of split is present.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update the uutils/coreutils package to a version that includes the fix from Pull Request #11397, which preserves non-UTF-8 bytes in output filenames exactly as GNU coreutils does.
If an immediate update is not possible, avoid using non-UTF-8 byte sequences in prefix or suffix parameters when using the split utility to prevent filename corruption.
Additionally, review any automation or scripts relying on split output filenames to ensure they handle or avoid non-UTF-8 encodings.
How can this vulnerability impact me? :
The vulnerability can impact you by causing the creation of files with incorrect or corrupted names when using the split utility with non-UTF-8 encoded inputs.
- Filename collisions, where multiple files may unintentionally share the same name.
- Broken automation, as scripts or processes relying on predictable filenames may fail.
- Misdirection of output data, potentially leading to data being written to unintended files.