This is a kernel-heap overflow in Zephyr's syscall layer, but the vulnerability's root cause is more subtle than a typical buffer overflow. The getsockopt handler for DTLS Connection IDs uses a bounce buffer sized exactly to the user-supplied optlen parameter, then passes that buffer to mbedtls_ssl_get_peer_cid() — a function that writes up to 32 bytes with no size parameter. When optlen is less than 32, overflow is architecturally guaranteed regardless of what mbedtls actually returns. The bounce buffer, intended to protect the kernel from user-supplied buffers, creates precisely the condition it was designed to prevent: a kernel-heap allocation sized by userspace metadata that receives data from a subsystem with fixed output requirements. The patch correctly validates optlen >= MBEDTLS_SSL_CID_OUT_LEN_MAX before allocation, but this fixes a parameter validation issue that only exists because the syscall boundary model is structurally incompatible with the mbedtls API contract. The severity (CVSS 8.4) is driven by the kernel-heap write, but the overflow content is the remote peer's negotiated CID — data the caller already received during the TLS handshake, making information disclosure minimal. The real risk is heap metadata corruption from attacker-controllable CID bytes landing in adjacent kernel objects. If you run Zephyr with CONFIG_USERSPACE enabled and handle DTLS CID, you need the v3.5.x or later patch. Check that your getsockopt callers always provide at least 32-byte buffers, and audit other syscall paths that pass user-sized buffers to fixed-output mbedtls or similar APIs — the bounce buffer model creates this mismatch wherever user length metadata drives kernel allocation decisions.
CVE-2026-8718
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedtls_opt_dtls_peer_connection_id_value_get() in subsys/net/lib/sockets/sockets_tls.c, which handles getsockopt(SOL_TLS, TLS_DTLS_PEER_CID_VALUE), passed the caller-supplied optval directly to mbedtls_ssl_get_peer_cid() without verifying the buffer was at least MBEDTLS_SSL_CID_OUT_LEN_MAX (default 32) bytes. mbedtls_ssl_get_peer_cid() copies the peer-negotiated DTLS Connection ID (length 1..MBEDTLS_SSL_CID_OUT_LEN_MAX) into that buffer without a destination-size parameter, so a caller-supplied optlen smaller than the CID causes a write of up to 31 bytes past the buffer end. In CONFIG_USERSPACE builds the getsockopt syscall verifier (z_vrfy_zsock_getsockopt) bounce-buffers the user's optval into a kernel allocation of exactly optlen bytes (k_usermode_alloc_from_copy -> z_thread_malloc), so an unprivileged user thread that passes a small optlen on a connected DTLS socket with Connection ID enabled induces a kernel-heap buffer overflow, with the overflowing content being the remote peer's CID. The defect requires CONFIG_MBEDTLS_SSL_DTLS_CONNECTION_ID, an established DTLS session with a negotiated peer CID, and (for the kernel-crossing case) CONFIG_USERSPACE. Introduced when the TLS_DTLS_CID option was added (v3.5.0). The fix rejects callers whose optlen is below MBEDTLS_SSL_CID_OUT_LEN_MAX with -EINVAL.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisThe program writes past the bounds of a buffer, overwriting adjacent memory an attacker can turn to their advantage. Crafted input can overwrite control data and redirect execution. Remediation is validating every index and length before a write, plus modern memory-safety mitigations.
General guidance for the out-of-bounds write class — the official description and references above are authoritative for this specific CVE. Want a bespoke review and a reviewed fix? Ask our team →
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Local
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- None
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade to the latest stable Zephyr RTOS release (v3.7.0 or later) which contains the fix for CVE-2026-8718
- Identify the current Zephyr RTOS version in use by checking the manifest or version file
- If running a version between v3.5.0 and the latest, upgrade to the most recent stable release that includes the security fix
- Verify the fix was applied by checking that getsockopt(SOL_TLS, TLS_DTLS_PEER_CID_VALUE) now returns -EINVAL when optlen is less than MBEDTLS_SSL_CID_OUT_LEN_MAX (32 bytes)
- If an immediate upgrade is not feasible, apply the vendor patch: add validation in tls_opt_dtls_peer_connection_id_value_get() to check optlen >= MBEDTLS_SSL_CID_OUT_LEN_MAX and return -EINVAL if violated
- Ensure CONFIG_MBEDTLS_SSL_DTLS_CONNECTION_ID is explicitly disabled in the build configuration if DTLS Connection ID functionality is not required, as a defense-in-depth measure
Generated from the published advisory — verify against the referenced sources before acting.
There is no version to upgrade to and no patch to apply. Every affected install stays exposed until the vendor ships a fix — or somebody else builds one.
Free. We build fixes in the order the community asks for them — and we’ll tell you the moment this one lands.
We develop and verify an original fix where the vendor hasn’t, from $8,000. Deployed to your staging first — never straight to production.
Scope it with usSee what else the community needs solved on the solutions-needed board.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-8718 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesThis is a kernel-heap overflow in Zephyr's syscall layer, but the vulnerability's root cause is more subtle than a typical buffer overflow. The getsockopt handler for DTLS Connection IDs uses a bounce buffer sized exactly to the user-supplied optlen parameter, then passes that buffer to mbedtls_ssl_get_peer_cid() — a function that writes up to 32 bytes with no size parameter. When optlen is less than 32, overflow is architecturally guaranteed regardless of what mbedtls actually returns. The bounce buffer, intended to protect the kernel from user-supplied buffers, creates precisely the condition it was designed to prevent: a kernel-heap allocation sized by userspace metadata that receives data from a subsystem with fixed output requirements. The patch correctly validates optlen >= MBEDTLS_SSL_CID_OUT_LEN_MAX before allocation, but this fixes a parameter validation issue that only exists because the syscall boundary model is structurally incompatible with the mbedtls API contract. The severity (CVSS 8.4) is driven by the kernel-heap write, but the overflow content is the remote peer's negotiated CID — data the caller already received during the TLS handshake, making information disclosure minimal. The real risk is heap metadata corruption from attacker-controllable CID bytes landing in adjacent kernel objects. If you run Zephyr with CONFIG_USERSPACE enabled and handle DTLS CID, you need the v3.5.x or later patch. Check that your getsockopt callers always provide at least 32-byte buffers, and audit other syscall paths that pass user-sized buffers to fixed-output mbedtls or similar APIs — the bounce buffer model creates this mismatch wherever user length metadata drives kernel allocation decisions.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-8718 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data