---
id: "CVE-2026-62976"
page: "https://infrastack.ai/live/CVE-2026-62976"
kind: "vulnerability"
aliases: ["CVE-2026-62976"]
title: "BACnet Stack: record counting reads past heap buffer on consecutive appends"
severity: "high"
cvss: 8.7
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["bacnet-stack", "building-automation", "c", "embedded", "package"]
not_affected_if: ["no-ramfs-file-object", "no-record-access-writes", "patched-version"]
published_at: "2026-11-13T19:19:33+00:00"
first_seen_at: "2026-11-13T19:52:09+00:00"
updated_at: "2026-11-13T19:54:04+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62976", "first_seen_at": "2026-11-13T19:52:09+00:00"}]
exploit_sources: []
---

# BACnet Stack: record counting reads past heap buffer on consecutive appends

Link for people: https://infrastack.ai/live/CVE-2026-62976 (this .md is for agents)

BACnet Stack is a C library for building BACnet building-automation devices. Two consecutive AtomicWriteFile append requests to the RAMFS-backed FILE object make the record counter read one byte past a heap allocation, which can crash or leak memory contents.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the BACnet Stack version in your build (for example the bacnet-stack tag or the library source) and see whether it is below `1.5.1`.
- Look for use of the RAMFS-backed FILE object with AtomicWriteFile record-access writes in your device firmware.

## Fix

- BACnet Stack: move to `1.5.1` or `1.6.0`.

## Timeline

- 2026-11-13T19:52:09+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-62976

## Documents

- [advisory] Vendor advisory: github.com https://github.com/bacnet-stack/bacnet-stack/security/advisories/GHSA-32jj-x86x-w98w

## From the sources

BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to version 1.5.1, the RAMFS-backed FILE object implementation stores appended records as NUL-terminated strings, but its record-counting logic later walks the buffer as if an additional terminating empty record were present. As a result, two consecutive AtomicWriteFile(record-access) append requests can cause record_count() to call bacnet_strnlen() on a pointer that is already one byte past the end of the heap allocation. This issue has been patched in versions 1.5.1 and 1.6.0.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_