The iconv

CVE-2026-4046 is a reachable assertion in glibc iconv() when converting attacker-controlled input from the IBM1390 or IBM1399 character sets. Upstream describes GNU C Library 2.43 and earlier as affected, with downstream fixes/backports starting to appear in vendor package streams rather than only in a clean major-version jump. Practically, this only matters where an application accepts untrusted text, allows or infers one of those source encodings, and then actually routes that data through iconv() on a host that still has those gconv modules installed.

The vendor's HIGH 7.5 CVSS is technically defensible in a vacuum because the end state is unauthenticated remote process termination. In enterprise reality, though, the reachable population is much narrower: IBM1390/IBM1399 are niche encodings, many apps normalize to UTF-8 long before iconv() sees user input, and removing the two charsets is a trivial compensating control. That combination pushes this down to a middle-queue denial-of-service issue, not an all-hands emergency.

Why this verdict

• Down from 7.5 because the network precondition is misleading: the vulnerable component is a library, so 'AV:N' only materializes when a front-end application accepts untrusted text and passes it into iconv().
• Down again because the attacker must hit rare encodings: IBM1390 and IBM1399 are niche character sets, not common web or API defaults, which cuts the reachable population hard.
• Down again because the blast radius is usually one service tier: this is a process-abort DoS, and modern supervisors, containers, and load balancers often restart or isolate the failure.
• Kept above LOW because the path can still be unauthenticated and remotely triggerable on public text-processing services that preserve charset negotiation or legacy conversion workflows.
• Kept below HIGH because there is no strong exploitation pressure: no KEV listing, very low EPSS, and no solid evidence of widespread scanning or operational abuse.

Why not higher?

There is no code execution, privilege gain, or data exposure here. More importantly, the attack chain depends on a niche application condition set: attacker-controlled charset conversion, presence of IBM1390/IBM1399, and an exposed service path that does not normalize to safer encodings first.

Why not lower?

This is still a real unauthenticated remote crash when the vulnerable path exists, and glibc sits under a lot of software. If you run internet-facing mail, content ingestion, document processing, or legacy data-conversion workflows, the bug can be operationally noisy enough to deserve more than backlog trivia.

1. Remove unused IBM1390 and IBM1399 gconv modules — If your environment does not legitimately process these charsets, remove or exclude the relevant gconv support so the vulnerable conversion path does not exist. For a MEDIUM verdict there is no mitigation SLA; do this in the next normal change window while still aiming to complete permanent remediation within 365 days.
2. Constrain accepted source encodings — At the application, gateway, or parsing layer, enforce an allowlist such as UTF-8 and other business-required encodings only. This is the highest-value control where applications accept uploaded files, email bodies, or charset-declared text; again, no mitigation SLA applies for MEDIUM, so fold it into routine engineering changes.
3. Monitor for abort-and-restart loops — Add alerts for SIGABRT, coredumps, repeated worker exits, and restart storms on services that perform charset conversion. This will not remove the bug, but it reduces mean time to containment if a reachable edge case is exercised before patching.
4. Prioritize exposure-driven patching — Patch hosts that back public-facing text ingestion and legacy conversion services first, then broader fleet maintenance later. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but exposed conversion services should be moved to the front of that queue.

Run this on the target Linux host as a regular user; root is only helpful if your package-manager metadata is restricted. Save it as check-cve-2026-4046.sh and run bash check-cve-2026-4046.sh. It checks the installed glibc version, looks for IBM1390/IBM1399 converter support, and uses distro changelog/package hints where available to avoid false positives from backports.

#!/usr/bin/env bash
# check-cve-2026-4046.sh
# Detect likely exposure to CVE-2026-4046 on Linux/glibc hosts.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

say() { printf '%s\n' "$*"; }

version_le() {
  # returns 0 if $1 <= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

version_gt() {
  # returns 0 if $1 > $2
  ! version_le "$1" "$2"
}

get_glibc_ver() {
  local v=""
  if command -v getconf >/dev/null 2>&1; then
    v=$(getconf GNU_LIBC_VERSION 2>/dev/null | awk '{print $2}')
  fi
  if [ -z "$v" ] && command -v ldd >/dev/null 2>&1; then
    v=$(ldd --version 2>/dev/null | head -n1 | grep -Eo '[0-9]+\.[0-9]+' | head -n1)
  fi
  printf '%s' "$v"
}

has_ibm139x_modules() {
  local paths
  paths=$(find /usr/lib* /lib* -maxdepth 3 \( -name 'gconv-modules' -o -name 'gconv-modules.d' \) 2>/dev/null)
  if [ -z "$paths" ]; then
    return 1
  fi
  if grep -RqsE 'IBM1390|IBM1399' $paths 2>/dev/null; then
    return 0
  fi
  return 1
}

rpm_backport_fixed() {
  if ! command -v rpm >/dev/null 2>&1; then
    return 1
  fi

  # SUSE-style fixed floor seen in vendor advisory
  local nvra
  nvra=$(rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}\n' glibc 2>/dev/null || true)
  if printf '%s\n' "$nvra" | grep -q ' 2\.31-150300\.101\.1'; then
    return 0
  fi

  # Fedora/rawhide and other RPM backports often leave breadcrumbs in changelog
  if rpm -q --changelog glibc-common 2>/dev/null | grep -qiE 'CVE-2026-4046|IBM1390, IBM1399 character sets'; then
    return 0
  fi
  if rpm -q --changelog glibc 2>/dev/null | grep -qiE 'CVE-2026-4046|IBM1390, IBM1399 character sets'; then
    return 0
  fi
  return 1
}

dpkg_backport_fixed() {
  if ! command -v dpkg-query >/dev/null 2>&1; then
    return 1
  fi

  # No universal Debian/Ubuntu fixed floor could be asserted from the reviewed primary sources.
  # If a maintainer changelog mentions the CVE explicitly, trust it.
  if command -v zgrep >/dev/null 2>&1; then
    if zgrep -qi 'CVE-2026-4046' /usr/share/doc/libc6/changelog.Debian.gz 2>/dev/null; then
      return 0
    fi
  fi
  return 1
}

main() {
  local glibc_ver
  glibc_ver=$(get_glibc_ver)

  if [ -z "$glibc_ver" ]; then
    say 'UNKNOWN: could not determine glibc version'
    exit 2
  fi

  if rpm_backport_fixed; then
    say "PATCHED: distro backport evidence found for CVE-2026-4046"
    exit 0
  fi

  if dpkg_backport_fixed; then
    say "PATCHED: distro changelog indicates CVE-2026-4046 fix"
    exit 0
  fi

  if ! has_ibm139x_modules; then
    say "PATCHED: IBM1390/IBM1399 gconv modules not present, vulnerable path not reachable on this host"
    exit 0
  fi

  if version_gt "$glibc_ver" '2.43'; then
    say "PATCHED: glibc version $glibc_ver is newer than 2.43"
    exit 0
  fi

  if version_le "$glibc_ver" '2.43'; then
    say "VULNERABLE: glibc $glibc_ver with IBM1390/IBM1399 converters present"
    exit 1
  fi

  say "UNKNOWN: unable to reach a confident conclusion"
  exit 2
}

main "$@"

Sources

1. NVD CVE-2026-4046
2. Ubuntu CVE-2026-4046
3. Debian security tracker CVE-2026-4046
4. SUSE CVE-2026-4046
5. Fedora rawhide glibc-common changelog
6. Amazon Linux ALAS CVE-2026-4046
7. Tenable plugin 304363 changelog
8. CISA Known Exploited Vulnerabilities catalog