# CVE-2026-12520: Stack buffer overflow and off-by-one writes in Zephyr HL7800 modem AT response handlers

> A stack buffer overflow in the Zephyr HL7800 modem driver allows kernel code execution or crashes via malicious AT responses from a rogue base station.

- **Severity:** Medium 6.4 (`CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 18 Aug 2026
- **Updated:** 19 Aug 2026
- **Also known as:** GHSA-9xc4-j5x8-v6jx

## What is CVE-2026-12520?

CVE-2026-12520 is a medium-severity memory corruption vulnerability in zephyrproject zephyr, published on 18 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

The Sierra Wireless HL7800 cellular modem driver (drivers/modem/vendor_standalone/hl7800.c, located at drivers/modem/hl7800.c in v4.4.0 and earlier) parses AT responses with roughly twenty handlers that call net_buf_linearize(value, sizeof(value), *buf, 0, len) into a 128-byte stack buffer and then write value[out_len] = 0. Because net_buf_linearize() (lib/net_buf/buf.c) can return a count equal to its destination-length argument, a field that exactly fills the buffer makes the terminating NUL land one byte past the end, a single-byte out-of-bounds write into adjacent stack memory.

The +KCELLMEAS cell-measurement handler on_cmd_atcmdinfo_rssi() is worse: it passed the wire length len as the destination size (net_buf_linearize(value, len, *buf, 0, len)), so a response line longer than 128 bytes overflows the value stack buffer with attacker-influenceable content. The line length comes from net_buf_findcrlf(), which accumulates bytes across the whole net_buf fragment chain and is not bounded to 128, so an over-long line reaches the defect.

The data originates from the cellular modem over UART, driven by the network: operator-scan results, +CGCONTRDP IP/DNS info, socket indications, and +KCELLMEAS neighbour-cell reports. An attacker able to shape what the modem emits — a rogue base station, a compromised modem baseband, or a remote peer feeding oversized response framing — can drive a line past 128 bytes. The handlers run in the driver's RX thread in kernel context, so the corruption is kernel-side.

The +KCELLMEAS path is a full stack buffer overflow whose worst case is code execution in kernel context and whose floor is a reliable crash; the remaining sites are single-byte NUL out-of-bounds writes. Exploitation requires the modem to emit an over-long AT response line, giving high attack complexity over an adjacent (cellular radio) vector. The fix passes sizeof(dst) - 1 (and correct explicit bounds for the IMSI and +KCELLMEAS sites) so the terminator always stays in bounds.

Weakness: CWE-787 (Out-of-bounds Write)

## Which versions are affected by CVE-2026-12520?


## How do I fix CVE-2026-12520?

No fix has been published for CVE-2026-12520 yet. Limit exposure of the affected software until one is available.

## Is CVE-2026-12520 being exploited?

There is no known exploitation of CVE-2026-12520 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-12520 and fix it if it is affected.

What it is: CVE-2026-12520 is a medium-severity memory corruption vulnerability in zephyrproject zephyr, published on 18 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-12520 in the wild and no public exploit code.

Affected product: zephyrproject zephyr. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-12520/ (Markdown: https://insights.sbomify.com/CVE-2026-12520/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-12520
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-12520
- OSV: https://osv.dev/vulnerability/CVE-2026-12520

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-12520/
Summaries are generated and may contain mistakes; the official description above is the record.