Linux Distros Unpatched Vulnerability : CVE-2026-31681

CVE-2026-31681 is a Linux kernel netfilter/xt_multiport validation flaw in the rule-checking path for malformed multiport v1 rules. Upstream affected ranges published by NVD are 2.6.17 to <6.6.136, 6.7 to <6.12.83, 6.13 to <6.18.24, 6.19 to <6.19.14, plus 7.0-rc1 through 7.0-rc7. The bug is in how the kernel validates port-range encoding before accepting a rule, so the practical trigger is rule insertion via iptables/xtables-compatible paths, not ordinary network traffic.

Reality is lower than a generic vendor 'HIGH' label. This is *local* and, more importantly, it effectively assumes the attacker can already create firewall rules—typically root, CAP_NET_ADMIN, or a badly over-privileged container. That makes it a post-initial-access kernel DoS/memory-safety bug with a narrow reachable population, not an internet-scale intrusion path.

Why this verdict

• Post-compromise requirement: The bug is local-only (AV:L) and starts after the attacker already has code execution on the host or container.
• Privilege friction compounds: Reaching the vulnerable path generally implies iptables rule creation rights, which in practice means root/CAP_NET_ADMIN, not a normal user.
• No exploitation heat: No KEV listing, no public PoC, and very low EPSS all argue against emergency treatment.
• Blast radius is mostly availability: The public scoring and descriptions point mainly to DoS-class impact rather than a clean, reliable privilege-escalation chain.

Why not higher?

If this were reachable by network traffic alone or usable by any unprivileged local user, it would climb fast. But stacking local foothold + firewall admin capability + specific kernel matcher path is exactly the sort of compounding friction that drags real-world severity down.

Why not lower?

It is still kernel-space memory-safety in a widely deployed component, and the impact can be a host crash. Also, some containerized or appliance-style deployments hand out NET_ADMIN too freely, which makes this more reachable than a purely root-only kernel bug.

1. Strip CAP_NET_ADMIN from containers — Remove NET_ADMIN from Kubernetes pods, Docker containers, and service wrappers unless there is a documented need. That directly cuts off the most realistic enterprise attack path; for a LOW verdict there is no mitigation SLA, so treat this as backlog hygiene and complete it during the next hardening cycle.
2. Lock down firewall administration — Restrict iptables/nft changes to trusted administrators and audited automation only. Use sudo, RBAC, and config-management guardrails so malware or low-trust operators cannot reach the vulnerable rule-insertion path; for LOW, there is no mitigation SLA, so fold this into normal platform-hardening work.
3. Prioritize admin-heavy Linux tiers for kernel updates — Focus first on bastions, network appliances, container hosts, and any node where operators or workloads legitimately manipulate netfilter rules. These are the small subset where the CVE is actually reachable; for LOW, there is no mitigation SLA, so schedule through routine maintenance.
4. Monitor for unauthorized rule writes — Alert on iptables, ip6tables, nft, and changes to netfilter configuration from unexpected parents, users, or containers. This won't patch the flaw, but it gives you a practical tripwire for the prerequisite behavior; for LOW, there is no mitigation SLA, so implement as standard detection engineering.

Run this on the target Linux host as root or with enough rights to read /boot/config-*, /proc/config.gz, package metadata, and kernel logs if needed. Invoke it as sudo bash cve-2026-31681-check.sh; it performs a conservative offline assessment and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# CVE-2026-31681 conservative checker
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

KREL="$(uname -r)"
BASE="${KREL%%-*}"
ARCH="$(uname -m)"
OS_ID="unknown"
OS_VER=""
OS_CODENAME=""

if [[ -r /etc/os-release ]]; then
  . /etc/os-release
  OS_ID="${ID:-unknown}"
  OS_VER="${VERSION_ID:-}"
  OS_CODENAME="${VERSION_CODENAME:-}"
fi

have_xt_multiport="unknown"
if command -v modinfo >/dev/null 2>&1 && modinfo xt_multiport >/dev/null 2>&1; then
  have_xt_multiport="yes"
elif [[ -r /proc/config.gz ]] && zgrep -Eq '^CONFIG_NETFILTER_XT_MATCH_MULTIPORT=(y|m)$' /proc/config.gz; then
  have_xt_multiport="yes"
elif [[ -r "/boot/config-$KREL" ]] && grep -Eq '^CONFIG_NETFILTER_XT_MATCH_MULTIPORT=(y|m)$' "/boot/config-$KREL"; then
  have_xt_multiport="yes"
else
  have_xt_multiport="no"
fi

if [[ "$have_xt_multiport" == "no" ]]; then
  echo "PATCHED: xt_multiport support not present on running kernel ($KREL)"
  exit 0
fi

ver_ge() { printf '%s\n%s\n' "$2" "$1" | sort -V -C; }
ver_lt() { ! ver_ge "$1" "$2"; }

# Debian-specific assessment from Debian tracker snapshot
if [[ "$OS_ID" == "debian" ]]; then
  case "$OS_CODENAME" in
    bullseye|bookworm)
      echo "VULNERABLE: Debian $OS_CODENAME was listed vulnerable for CVE-2026-31681 in the reviewed tracker snapshot; running kernel=$KREL"
      exit 1
      ;;
    trixie)
      if ver_ge "$BASE" "6.12.85"; then
        echo "PATCHED: Debian trixie running kernel $KREL is at/above reviewed fixed branch floor 6.12.85"
        exit 0
      else
        echo "VULNERABLE: Debian trixie running kernel $KREL is below reviewed fixed branch floor 6.12.85"
        exit 1
      fi
      ;;
    sid|forky)
      if ver_ge "$BASE" "7.0.10"; then
        echo "PATCHED: Debian $OS_CODENAME running kernel $KREL is at/above reviewed fixed floor 7.0.10"
        exit 0
      else
        echo "UNKNOWN: Debian $OS_CODENAME detected but package/backport mapping is ambiguous for kernel $KREL"
        exit 2
      fi
      ;;
  esac
fi

# Upstream-only version gate. Conservative: distro backports can invalidate this.
# If this looks like a distro kernel (has a suffix after the upstream base), prefer UNKNOWN.
if [[ "$KREL" != "$BASE" ]]; then
  echo "UNKNOWN: distro kernel detected ($KREL). Upstream version math alone is unreliable because vendors backport fixes. xt_multiport=$have_xt_multiport"
  exit 2
fi

vuln=no
if ver_ge "$BASE" "2.6.17" && ver_lt "$BASE" "6.6.136"; then
  vuln=yes
fi
if ver_ge "$BASE" "6.7" && ver_lt "$BASE" "6.12.83"; then
  vuln=yes
fi
if ver_ge "$BASE" "6.13" && ver_lt "$BASE" "6.18.24"; then
  vuln=yes
fi
if ver_ge "$BASE" "6.19" && ver_lt "$BASE" "6.19.14"; then
  vuln=yes
fi

case "$BASE" in
  7.0.rc1|7.0-rc1|7.0.rc2|7.0-rc2|7.0.rc3|7.0-rc3|7.0.rc4|7.0-rc4|7.0.rc5|7.0-rc5|7.0.rc6|7.0-rc6|7.0.rc7|7.0-rc7)
    vuln=yes
    ;;
esac

if [[ "$vuln" == "yes" ]]; then
  echo "VULNERABLE: upstream kernel $KREL falls in reviewed CVE-2026-31681 affected ranges and xt_multiport is present"
  exit 1
fi

echo "PATCHED: upstream kernel $KREL is outside the reviewed affected ranges"
exit 0

Sources

1. Tenable Nessus Plugin 310347
2. NVD CVE-2026-31681
3. Ubuntu CVE-2026-31681
4. Debian Security Tracker CVE-2026-31681
5. Amazon Linux ALAS CVE-2026-31681
6. CISA Known Exploited Vulnerabilities Catalog
7. Feedly CVE-2026-31681 summary
8. CVE Record