---
id: "CVE-2026-18748"
kind: "vulnerability"
aliases: ["CVE-2026-18748"]
title: "Zephyr Bluetooth A2DP: oversized codec IE leaks adjacent RAM to a paired peer"
severity: "low"
cvss: 3.5
epss: 0.00158
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["a2dp", "bluetooth", "embedded", "runtime", "zephyr"]
not_affected_if: ["no-a2dp", "no-bluetooth-classic", "sbc-only-codec"]
published_at: "2026-10-21T19:17:02+00:00"
first_seen_at: "2026-10-23T21:57:29+00:00"
updated_at: "2026-10-25T04:45:41+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18748", "first_seen_at": "2026-10-23T21:57:29+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-18748", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Zephyr Bluetooth A2DP: oversized codec IE leaks adjacent RAM to a paired peer

The Zephyr Bluetooth Classic A2DP host copies only 8 bytes of a codec Information Element but keeps the attacker-supplied length, so a later GET_CONFIGURATION response reads roughly 245 bytes of adjacent memory. A paired Bluetooth peer can receive that adjacent RAM over the air, a disclosure rather than code execution.

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

## How to check

- Check whether the firmware is built with `CONFIG_BT_CLASSIC=y` and `CONFIG_BT_A2DP=y`.
- Check whether a local endpoint is registered for a non-SBC codec (BT_A2DP_MPEG1, BT_A2DP_MPEG2, BT_A2DP_ATRAC or BT_A2DP_VENDOR) via `BT_A2DP_EP_INIT()`.
- Check the Zephyr version in the tree; the sources do not name the fixed version range.

## Fix

- Zephyr: move to a release that includes the fix replacing `BT_A2DP_MAX_IE_LENGTH` with `CONFIG_BT_A2DP_CODEC_MAX_IE_LEN` and rejecting oversized IEs (fixed version: unknown).
- Until patched, unknown; the sources do not offer a configuration workaround.

## Timeline

- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-18748
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-18748

## From the sources

The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array. When an AVDTP peer sent a codec IE longer than 8 bytes, a2dp_process_config_ind() in subsys/bluetooth/host/classic/a2dp.c copied only the first 8 bytes but assigned the full, attacker-chosen length to len, and then persisted that inconsistent structure into the application's struct bt_a2dp_stream via stream->codec_config. bt_a2dp_get_config_cb() and bt_a2dp_set_config_cb() had the same truncate-the-copy-but-keep-the-length pattern.

Every later consumer trusts len. In particular the responder for an incoming AVDTP GET_CONFIGURATION, a2dp_get_config_ind(), executes net_buf_add_mem(rsp_buf, &ep->stream->codec_config.codec_ie[0], ep->stream->codec_config.len), so a paired BR/EDR peer that first sends a SET_CONFIGURATION carrying an oversized codec IE and then requests the configuration back causes the stack to read up to roughly 245 bytes past the end of the 8-byte array and transmit them in the response. codec_config is the last member of struct bt_a2dp_stream, so the read runs into memory adjacent to the application's stream object. The same inconsistency is also handed to the config_req(), reconfig_req() and get_config_rsp() application callbacks, where a natural memcpy() of len bytes performs a further out-of-bounds read.

Reaching the on-air disclosure requires CONFIG_BT_CLASSIC with CONFIG_BT_A2DP, an AVDTP peer that has completed pairing (the AVDTP L2CAP channel requires BT_SECURITY_L2), and a local endpoint registered for a non-SBC codec — BT_A2DP_MPEG1/BT_A2DP_MPEG2/BT_A2DP_ATRAC/BT_A2DP_VENDOR via BT_A2DP_EP_INIT() — because the SBC branch already pins the IE length to 4 bytes. The bt_a2dp_get_config_cb() response path has no such gate and hands the lying length to any application. There is no out-of-bounds write: the net_buf tailroom check bounds the destination, so the impact is limited to disclosure of a bounded region of adjacent RAM to the peer.

The fix replaces the hardcoded BT_A2DP_MAX_IE_LENGTH with the configurable CONFIG_BT_A2DP_CODEC_MAX_IE_LEN (default 8, range 4–253), sizes codec_ie[] from it, and rejects any received IE that exceeds it instead of silently truncating, so len can no longer exceed the number of valid bytes.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_