Cloudanix VulnDB

CVE-2026-35373

Low · 3.3

CVSS

3.3

EPSS

0.1%

Published

Apr 22, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some file-linking tasks can fail when they encounter valid filenames with unusual byte characters, potentially disrupting automated jobs that depend on them.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
Application
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw is a local denial-of-service condition in the uutils coreutils implementation of `ln`. Unix filesystems generally treat file names as byte sequences, but the affected `ln` logic rejects source paths containing non-UTF-8 bytes when invoked in target-directory forms such as `ln SOURCE... DIRECTORY`. Instead of correctly resolving and linking the source path, the utility fails to stat the file and exits with a non-zero status. The impact is limited to availability of local file-linking workflows that encounter valid non-UTF-8 file names; it does not provide code execution, privilege escalation, data disclosure, or direct file modification beyond failed operations.

Why it matters to the business

Organizations using uutils coreutils in automation, packaging, backup, migration, build, deployment, archival, or system-maintenance workflows may experience failed jobs when valid Unix filenames contain non-UTF-8 bytes. The operational risk is disruption of dependent tasks rather than compromise of confidentiality or integrity. Public exploitation likelihood is low based on the very low EPSS score, flat EPSS trend, absence from the CISA KEV catalog, and no known exploit maturity, but environments that process legacy, multilingual, externally supplied, or byte-preserving Unix filenames are more exposed to reliability failures.

How an attack unfolds

An attacker or local user with the ability to create or influence filenames can create a valid filesystem entry whose name contains bytes that are not valid UTF-8. They then cause an affected automation path, scheduled task, packaging process, or administrative script to invoke the uutils `ln` command using a target-directory form such as `ln SOURCE... DIRECTORY`. When the affected `ln` implementation attempts to interpret the source path as UTF-8, it rejects the filename, fails to stat the source, and returns a non-zero exit status. If the surrounding workflow treats that failure as fatal, the larger operation may stop, skip required link creation, leave output incomplete, or trigger service degradation. Exploitation requires local access or another path to influence local filenames and does not by itself grant elevated privileges.

How to fix it

Upgrade uutils coreutils to a version that corrects byte-preserving filename handling in `ln` when an upstream fixed release becomes available. No specific fixed version was provided in the input, so track the uutils coreutils advisory, release notes, distribution packages, and downstream vendor updates. As an interim mitigation, use GNU coreutils `ln` for workflows that must safely process arbitrary Unix filename bytes, especially automation that handles external archives, legacy data, backups, packaging artifacts, or user-controlled filenames. Where replacement is not immediately possible, validate or normalize filenames before they reach affected `ln` invocations, avoid target-directory forms that trigger the bug where practical, and harden scripts so a single link failure does not unnecessarily halt critical operations without alerting and recovery.

How to confirm the fix worked

Confirm the installed `ln` implementation and package source; systems using GNU coreutils are not affected by this uutils-specific behavior. On potentially affected systems, create a controlled test file with a non-UTF-8 byte in the filename and run the target-directory form of `ln` against a test directory. A vulnerable implementation will fail to stat or reject the source path and return a non-zero exit code, while a corrected or GNU-compatible implementation should create the link successfully. Also review package manager metadata, container base images, and build/runtime images to verify whether uutils coreutils is present and whether a fixed vendor package has been applied. Validate important automation by running regression tests with byte-preserving filenames and confirming successful link creation and expected exit handling.

Typical attack path

  1. Identify a system or workflow that uses uutils coreutils `ln` rather than GNU coreutils `ln`.
  2. Gain local ability to create files or influence filenames processed by that workflow.
  3. Create a valid filesystem object with a source filename containing non-UTF-8 byte sequences.
  4. Trigger a script, scheduled job, build process, backup task, migration process, or administrative operation that calls `ln SOURCE... DIRECTORY`.
  5. Cause `ln` to reject the source path, fail to stat the file, and exit non-zero.
  6. Rely on the calling workflow to abort, fail partially, or leave required links uncreated, resulting in localized service or operational disruption.

How to detect it

To determine whether this issue has already caused disruption, review logs from local automation that invokes `ln`, including cron logs, systemd journal entries, CI/CD job logs, package/build logs, backup and archival job logs, migration logs, and application task logs that shell out to coreutils. Look for non-zero exits from `ln`, failures mentioning invalid UTF-8 or inability to stat a source path, and job failures correlated with filenames containing escaped octal, hexadecimal, replacement-character, or otherwise unusual byte representations. For forensic review, compare failed job timestamps with filesystem entries created shortly before failure by local users, service accounts, extraction tools, or synchronization jobs. Because this is a local availability flaw rather than a compromise primitive, indicators are primarily operational artifacts: repeated `ln` errors, failed link creation, incomplete output directories, aborted scripts, and suspiciously crafted filenames in directories processed by automated jobs. No public threat actors or ransomware campaigns are known from the provided data.

  • ln: failed to access
  • ln: cannot stat
  • ln: invalid UTF-8
  • invalid UTF-8
  • non-UTF-8
  • failed to stat
  • exit status 1
  • ln SOURCE... DIRECTORY
  • uutils coreutils
  • uu_ln

What your security team should do

  • Inventory systems, containers, CI images, build environments, and scripts that use uutils coreutils `ln`, especially where uutils may replace GNU coreutils.
  • Prioritize remediation for automation that processes externally supplied archives, backups, user uploads, legacy datasets, or filenames that may contain arbitrary bytes.
  • Replace affected `ln` usage with GNU coreutils `ln` or a fixed uutils release once available.
  • Add regression tests for non-UTF-8 filenames in critical file-processing workflows.
  • Update scripts to handle `ln` failures explicitly, alert on unexpected non-zero exits, and avoid leaving partial output silently.
  • Monitor upstream uutils coreutils and downstream distribution advisories because no exact fixed version is currently specified.
  • Treat this as a reliability and local availability issue rather than a high-risk remote compromise, consistent with the low CVSS score, low EPSS, no KEV listing, and no known exploitation maturity.

The record

A logic error in the ln utility of uutils coreutils causes the program to reject source paths containing non-UTF-8 filename bytes when using target-directory forms (e.g., ln SOURCE... DIRECTORY). While GNU ln treats filenames as raw bytes and creates the links correctly, the uutils implementation enforces UTF-8 encoding, resulting in a failure to stat the file and a non-zero exit code. In environments where automated scripts or system tasks process valid but non-UTF-8 filenames common on Unix filesystems, this divergence causes the utility to fail, leading to a local denial of service for those specific operations.

Affected packages

Ecosystem Package Introduced Fixed
crates.io coreutils 0 No fix

Related vulnerabilities