CVE-2026-6068: Critical Use-After-Free in NASM Response Files

CVE-2026-6068 is a critical (CVSS 9.6) heap use-after-free in the NASM assembler. A dangling pointer is kept when NASM processes a response file given with the -@ option. The researcher said it was unpatched when published. Check the NASM project for a fix and avoid running it on untrusted build inputs.

What's affected

• Product: NASM, the Netwide Assembler.
• Component: response file (-@) processing, where a pointer into a buffer is stored in the global depend_file and used after the buffer is freed.
• Versions and fix: the record lists none. The researcher's write-up said the issue was still unpatched at the time of writing, and the GitHub issue is the place to check current status.
• Weakness: CWE-416, use after free. CVSS 9.6 (critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H.
• The vector requires user interaction, which fits a person running NASM on something they were handed.

How to check if you're exposed

Find where NASM runs: developer machines, CI runners, container build images and package builds.

nasm -v
which -a nasm

Then look for builds that pass a response file to NASM, which is the -@ option, and for builds that pull in projects you did not write:

grep -rn "nasm.*-@" Makefile* CMakeLists.txt build/ 2>/dev/null

NASM is often a build dependency of other projects, such as codecs and crypto libraries, so check the build logs of your dependencies as well as your own code.

What to do now

1. Inventory where NASM is installed, including CI images and build containers.
2. Check the NASM repository and your distribution's security tracker for a fixed release. Do not assume one exists.
3. Do not run NASM on code or build files from untrusted sources on a machine that holds credentials or a long lived shell profile.
4. Build third party code inside a disposable container with no secrets and no write access to your home directory.
5. Review build scripts for response file use and remove it where you can.

Why it matters

A use-after-free is a memory safety bug. A pointer outlives the memory it points to, and the program later reads through it. In NASM the buffer holding the response file contents is freed, but a pointer into it stays in a global variable.

The researcher's write-up argues this is more serious than an ordinary crash and frames the risk as a supply chain scenario: a repository that builds normally while taking advantage of the assembler. I have left out the technique on purpose. The practical lesson stands without it. A build tool runs with your privileges, so untrusted inputs to a build are untrusted code.

The record's KEV flag is false, and no source I read reports attacks in the wild. The write-up says it was published with the permission of CERT/CC after the vendor could not be reached.

Quick check

Sources

• NASM issue 222
• Project SEKAI write-up

Last reviewed: 19 October 2026.