Coordinated Vulnerability Disclosure - Off-by-One Null Byte Heap Buffer Overflow in fgetl()

I’m a vulnerability analyst at VulnCheck, an exploit intelligence company and research CVE Numbering Authority (CNA), where I'm one of several folks who manage our coordinated vulnerability disclosure (CVD) program.

An external security researcher recently reported a potential vulnerability impacting the hashcat and VulnCheck is acting as the intermediary and coordinator.

VulnCheck follows a 120-day disclosure policy, meaning we afford vendors/maintainers up to 120 days from the time of receiving the report to address the issue before publishing a CVE record and third-party advisory. For this vulnerability, the 120-day deadline falls on November 28, 2026.

The following CVE ID has been provisionally reserved for reference purposes:

CVE-2026-68767 - Off-by-One Null Byte Heap Buffer Overflow in fgetl()

Reservation does not constitute publication. The ID will remain in a non-public RESERVED state with no technical details visible in the CVE database until we have aligned on CVE-eligibility, disclosure details, and a timeline, or until the 120-day coordinated disclosure window closes.

They have provided us with a comprehensive technical report, which we have attached below. Let us know if you have any questions for us about the CVD process or for the researcher regarding the reported vulnerability.

---

Off-by-One Null Byte Heap Buffer Overflow in fgetl()

Package: hashcat/hashcat Tested Versions: v7.1.2-382-g2d71af371 Affected File: src/filehandling.c line 1061 CWE: CWE-193: Off-by-One Error; CWE-787: Out-of-Bounds Write CVSS 3.1: AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H -- 7.8 High

Affected Files src/filehandling.c Line 1061 line_buf[line_len] = 0; -- when line_len == line_sz, writes null at line_buf[line_sz]: OOB

Line 1070 count_lines() allocates HCBUFSIZ_LARGE + 1 -- SAFE (correct pattern) -- callers of fgetl() allocate only HCBUFSIZ_LARGE -- UNSAFE

Affected callers (allocate HCBUFSIZ_LARGE, no room for terminator): src/hlfmt.c:359 hlfmt_detect() src/hashes.c:1412 hashes_init_stage1() src/potfile.c:517 potfile_read() src/outfile_check.c:181 outfile_check() Root Cause

fgetl() reads characters into line_buf up to line_sz characters, tracking truncation when the buffer is full. After the loop, it unconditionally writes a null terminator at line_buf[line_len]. When line_len == line_sz (exactly buffer-full), this writes one null byte at line_buf[line_sz] — one byte past the allocation. All callers that supply an HCBUFSIZ_LARGE (16,777,216 byte) buffer allocate exactly that size with no terminator room. The correct pattern (HCBUFSIZ_LARGE + 1) already exists in count_lines() in the same file.

PoC python N = 0x1000000 # HCBUFSIZ_LARGE h = b'd41d8cd98f00b204e9800998ecf8427e' open('/tmp/oob.hash', 'wb').write(b'A' * (N - 33) + b':' + h)

exactly N bytes, no newline

bash python3 poc.py hashcat --show /tmp/oob.hash --force

-> SIGSEGV / ASAN heap-buffer-overflow

ASAN output:

ERROR: AddressSanitizer: heap-buffer-overflow WRITE of size 1 #0 fgetl src/filehandling.c:1061 #1 hlfmt_detect src/hlfmt.c:363 0x... is located 0 bytes after 16777216-byte region allocated by hcmalloc (memory.c:27) Impact

One controlled-position null write immediately past a 16 MB heap buffer. Depending on heap layout, the null byte can clear a chunk-size PREV_INUSE bit or zero the LSB of an adjacent pointer (e.g. a tcache next), both classical heap exploitation primitives given grooming and an ASLR bypass. Confirmed SIGSEGV and ASAN heap-buffer-overflow WRITE of size 1 at fgetl. Reliable exploitation requires heap grooming; denial of service is the confirmed minimum impact.