NASM contains a heap use after free vulnerability in response file

CVE-2026-6068 is a heap use-after-free in NASM's -@ response-file handling: a pointer derived from the response-file buffer is stored in global depend_file, the backing buffer is freed, and the stale pointer is later dereferenced during command-line parsing. Public references confirm the bug in the -@ path and NVD currently enriches at least 3.02rc5 as affected; the full upstream affected range is not authoritatively published, so anything carrying the same code path should be treated as suspect until the project ships a fix.

The vendor's CRITICAL 9.6 framing overshoots reality for enterprise patch queues. The deciding friction is attacker position: NASM is a local assembler used on developer workstations and CI runners, so exploitation generally requires getting a victim build process to consume attacker-controlled response-file content or a malicious repository/build recipe first. That makes this a real supply-chain and build-host integrity problem, but not a mass internet-reachable emergency on the level implied by a network-preauth RCE score.

Why this verdict

• Downgrade for attacker position: exploitation starts with control of build input, repository content, or response-file content; that is materially narrower than a true network-preauth service flaw.
• Downgrade for exposure fraction: only systems that actually run NASM are in scope, and in most enterprises that is a tiny slice of developer workstations, CI runners, and niche build containers rather than 10,000 general endpoints.
• Hold at MEDIUM because of supply-chain blast radius: if a sensitive CI runner or release workstation is hit, the attacker can tamper with artifacts or steal secrets, so this is still more than hygiene-level noise.

Why not higher?

There is no evidence here of broad internet reachability, wormability, or one-shot exploitation against common end-user/server software. Every practical attack chain assumes either attacker-controlled build input, social engineering, or an earlier compromise stage in the software supply chain, and each prerequisite compounds downward pressure on severity.

Why not lower?

The bug is still a memory-safety flaw in a trusted build component, and public research claims a path to code execution rather than a mere crash. On build hosts with access to source, package registries, or signing workflows, compromise can have outsized downstream impact even if the vulnerable population is small.

1. Block untrusted NASM builds on shared runners — Do not allow shared CI runners to build forks, external pull requests, or third-party source with NASM enabled unless the runner is fully isolated and ephemeral. Even though this is a MEDIUM and there is no mitigation SLA, do this in your next normal hardening cycle because it directly removes the attacker-controlled-input prerequisite.
2. Constrain CI identities and secrets — Scope tokens so NASM build jobs cannot read signing keys, production registries, or unrelated secrets. For a MEDIUM verdict there is no mitigation SLA, but reducing secret reach sharply limits the only scenario that makes this bug strategically dangerous: build-host compromise turning into supply-chain compromise.
3. Inventory and pin NASM instances — Find NASM on developer images, build containers, and self-hosted runners; pin approved versions and prevent ad hoc source builds where possible. With no mitigation SLA for MEDIUM, complete this as routine vulnerability management and be ready to swap in the vendor fix quickly once one exists.
4. Disable or lint response-file usage — If your build wrappers can do it, reject -@ response-file usage or require allowlisted, generated response files only. This directly targets the vulnerable parser path and is a practical temporary control until an upstream fix is available.
5. Increase build-host telemetry — Turn on process, child-process, file-write, and artifact-diff telemetry for build workers that run NASM. There is no mitigation SLA for MEDIUM, but better telemetry is the fastest way to catch the post-exploitation behaviors that matter more than the parser crash itself.

Run this on the target developer workstation, CI runner, or build container that may invoke NASM. Save as check-nasm-cve-2026-6068.sh and run bash check-nasm-cve-2026-6068.sh with a normal user account; no root is required unless you want package-manager metadata from restricted locations.

#!/usr/bin/env bash
# check-nasm-cve-2026-6068.sh
# Detect likely exposure to CVE-2026-6068 in NASM.
# Exit codes:
#   0 = PATCHED / not vulnerable by version heuristic
#   1 = VULNERABLE
#   2 = UNKNOWN
#   3 = NASM not installed

set -u

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

extract_version() {
  # Example: "NASM version 3.02rc7 compiled on ..."
  nasm -v 2>/dev/null | sed -nE 's/.*version[[:space:]]+([^[:space:]]+).*/\1/p' | head -n1
}

version_in_known_vuln_window() {
  local v="$1"
  case "$v" in
    3.02rc5|3.02rc6|3.02rc7) return 0 ;;
    *) return 1 ;;
  esac
}

source_pattern_present() {
  local f="$1"
  [ -f "$f" ] || return 1
  grep -q 'depend_file = q;' "$f" 2>/dev/null || return 1
  grep -q 'nasm_free(buffer);' "$f" 2>/dev/null || return 1
  grep -q 'strcmp(inname, depend_file)' "$f" 2>/dev/null || return 1
  return 0
}

if ! have_cmd nasm; then
  echo "UNKNOWN: NASM not found on PATH"
  echo "NOT_INSTALLED"
  exit 3
fi

VER="$(extract_version)"
if [ -z "$VER" ]; then
  echo "UNKNOWN: Could not parse NASM version"
  exit 2
fi

# Heuristic 1: publicly enriched NVD data confirms at least 3.02rc5,
# and public references reviewed do not disclose a fixed version.
if version_in_known_vuln_window "$VER"; then
  echo "VULNERABLE: NASM version $VER falls in the publicly known affected pre-release window"
  exit 1
fi

# Heuristic 2: if source tree is present, inspect for the vulnerable code pattern.
for candidate in \
  ./asm/nasm.c \
  /usr/src/*/asm/nasm.c \
  /usr/local/src/*/asm/nasm.c

do
  for f in $candidate; do
    if source_pattern_present "$f"; then
      echo "VULNERABLE: source pattern for CVE-2026-6068 found in $f"
      exit 1
    fi
  done
done

# If version is newer than the known vulnerable prerelease set we still may not know,
# because no authoritative fixed version was available in reviewed sources.
case "$VER" in
  3.02rc*|3.*|2.*)
    echo "UNKNOWN: NASM version $VER installed, but no authoritative fixed version was published in reviewed sources"
    exit 2
    ;;
  *)
    echo "PATCHED: NASM version $VER is outside the known vulnerable prerelease window and no source pattern was found"
    exit 0
    ;;
esac

Sources

1. NVD CVE-2026-6068
2. NASM issue #222
3. Project SEKAI disclosure
4. Ubuntu CVE page
5. Debian NASM tracker
6. CISA KEV catalog
7. FIRST EPSS overview
8. NASM project site