The comm utility in uutils coreutils silently corrupts data by performing lossy UTF-8 conversion on all…

CVE-2026-35346 affects the comm utility in uutils coreutils before 0.6.0. Instead of writing raw bytes back out like GNU comm, vulnerable builds run output through a lossy UTF-8 conversion path, replacing invalid bytes with U+FFFD and silently corrupting results when input contains binary data or legacy non-UTF-8 text.

The vendor's LOW 3.3 is already generous from an enterprise patch-priority perspective. In the real world this requires the attacker to already have local code execution or a way to steer a victim's local batch job into using uutils comm on specially chosen non-UTF-8 data, and the blast radius is usually confined to the one script or pipeline consuming that output.

Why this verdict

• Downward pressure: requires local execution or local workflow control — AV:L is not a footnote here; it means the attacker is already on the host or already steering the job.
• Downward pressure: affected population is narrow — only fleets that actually deployed uutils coreutils and specifically invoke comm are in scope; large GNU-based Linux estates are unaffected.
• Downward pressure: trigger condition is specialized — you need non-UTF-8 or binary-like input to hit the corruption path, which excludes the majority of everyday UTF-8 text workflows.
• Downward pressure: blast radius is small — impact is usually confined to one script, one reconciliation job, or one data-processing path rather than enabling privilege escalation or remote compromise.
• No amplifier from threat intel — no KEV listing, no active exploitation evidence, and an effectively negligible EPSS score.

Why not higher?

There is no remote reachability, no privilege gain, and no direct path to code execution. Even if the integrity consequence is real, every prerequisite narrows the exposed population: local foothold, affected package choice, use of comm, and non-UTF-8 inputs.

Why not lower?

I am not calling this 'not a bug' because the corruption is silent and byte-exactness matters in some pipelines. If your environment uses uutils in CI, build, migration, or reconciliation jobs that compare binary or legacy-encoded data, this can create real integrity mistakes even though it is still a poor security-priority candidate.

1. Document the exception — Because noisgate rates this IGNORE, there is no action required under the SLA; document that the issue is local-only, post-compromise, and only relevant to byte-sensitive comm workflows. Use this rationale to keep it out of emergency patch queues.
2. Pin GNU coreutils for byte-sensitive jobs — If you do have scripts comparing binary blobs or legacy-encoded text, explicitly invoke GNU comm or route those jobs to hosts without uutils. Since there is no noisgate mitigation SLA for IGNORE, do this through normal change management where testing shows business impact.
3. Add regression tests for raw-byte fidelity — In CI or packaging validation, compare comm output against known byte sequences and fail builds if invalid UTF-8 bytes are rewritten. This is the right long-term guardrail for distributions experimenting with uutils substitutions.

Run this on the target Linux/macOS host you want to assess, not from an auditor workstation. Invoke it as bash check-cve-2026-35346.sh /usr/bin/comm; if you omit the argument it defaults to comm in PATH. No root is required, but the script needs execute permission on the binary and access to --version output.

#!/usr/bin/env bash
# check-cve-2026-35346.sh
# Detects whether the local 'comm' binary appears affected by CVE-2026-35346.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-comm}"
TMPDIR="$(mktemp -d 2>/dev/null || mktemp -d -t cve35346)"
A="$TMPDIR/a.bin"
B="$TMPDIR/b.bin"
OUT="$TMPDIR/out.bin"
ERR="$TMPDIR/err.txt"

cleanup() {
  rm -rf "$TMPDIR"
}
trap cleanup EXIT

if ! command -v "$TARGET" >/dev/null 2>&1 && [ ! -x "$TARGET" ]; then
  echo "UNKNOWN: comm binary not found: $TARGET"
  exit 2
fi

# Resolve command path if a bare command name was given.
if command -v "$TARGET" >/dev/null 2>&1; then
  BIN="$(command -v "$TARGET")"
else
  BIN="$TARGET"
fi

VER_OUT="$($BIN --version 2>/dev/null | head -n 2)"
if [ -z "$VER_OUT" ]; then
  echo "UNKNOWN: unable to read version from $BIN"
  exit 2
fi

# If this is clearly GNU comm, it's not affected by this uutils-only CVE.
if printf '%s' "$VER_OUT" | grep -qi 'GNU coreutils'; then
  echo "PATCHED: GNU coreutils detected at $BIN (not affected by CVE-2026-35346)"
  exit 0
fi

# If this is clearly uutils >= 0.6.0, treat as patched.
if printf '%s' "$VER_OUT" | grep -qi 'uutils'; then
  UVER="$(printf '%s\n' "$VER_OUT" | sed -n 's/.*uutils[^0-9]*\([0-9][0-9.]*\).*/\1/p' | head -n1)"
  if [ -n "$UVER" ]; then
    awk -v v="$UVER" 'BEGIN {
      split(v,a,".");
      maj=a[1]+0; min=a[2]+0; pat=a[3]+0;
      if (maj>0 || (maj==0 && min>=6)) exit 0; else exit 1;
    }'
    if [ $? -eq 0 ]; then
      echo "PATCHED: uutils version $UVER detected at $BIN (>= 0.6.0)"
      exit 0
    fi
  fi
fi

# Behavioral test from the public repro: vulnerable versions replace invalid bytes.
printf '\376\n\377\n' > "$A"
printf '\377\n\376\n' > "$B"

if ! "$BIN" "$A" "$B" > "$OUT" 2> "$ERR"; then
  echo "UNKNOWN: test execution failed for $BIN"
  if [ -s "$ERR" ]; then
    echo "UNKNOWN detail: $(tr '\n' ' ' < "$ERR")"
  fi
  exit 2
fi

HEX="$(od -An -tx1 -v "$OUT" | tr -d ' \n')"
EXPECTED_PATCHED="0909ff0a0909fe0a"

if [ "$HEX" = "$EXPECTED_PATCHED" ]; then
  echo "PATCHED: raw-byte output preserved; behavior matches fixed/GNU comm"
  exit 0
fi

if printf '%s' "$HEX" | grep -qi 'efbfbd'; then
  echo "VULNERABLE: output contains UTF-8 replacement bytes (efbfbd), indicating lossy conversion"
  exit 1
fi

echo "UNKNOWN: unexpected output pattern from $BIN"
echo "UNKNOWN detail: hex=$HEX"
exit 2

Sources

1. NVD CVE-2026-35346
2. CVE.org record
3. Ubuntu CVE page
4. uutils issue #10192
5. uutils pull request #10206
6. uutils 0.6.0 release
7. FIRST EPSS project
8. CISA KEV catalog