CVE-2026-88373

What it actually does

libde265's NAL parsing path can pass a NULL destination pointer into memcpy() when de265_push_NAL() is given a zero-length NAL unit. The NAL_unit object keeps a NULL backing buffer that NAL_unit::set_data() then uses as the memcpy destination. A zero copy length does not satisfy memcpy()'s nonnull contract, so the result is undefined behavior: UBSan-instrumented builds abort, and many production decoders crash, terminating the decoding process and denying availability. Confidentiality and integrity are not affected.

Why it matters to the business

Services that decode HEVC/H.265 with an affected libde265 can be knocked offline by unauthenticated network or upload input, interrupting streaming, transcoding, thumbnails, and content-moderation pipelines until workers or hosts are restarted. Because this decoder is commonly embedded in media stacks, one crash can take down a shared processing pool. The issue is a high-availability (CVSS 7.5) denial of service, is not in CISA KEV, has no reported ransomware use, and has no known public exploit maturity about two weeks after publication—so the operational risk is sudden outage rather than confirmed mass exploitation, but media-facing estates should still treat patching as urgent.

How an attack unfolds

An unauthenticated attacker supplies HEVC/H.265 content containing a zero-length NAL unit to any reachable component that feeds untrusted bitstreams into de265_push_NAL()—for example a video upload, a live stream ingest, or a transcode/thumbnail API. The library builds a NAL_unit with a NULL data buffer and later calls memcpy() with that NULL destination. Undefined behavior follows and the decoder process typically aborts, causing a denial of service until the process is restarted. No privileges or user interaction are required. No named threat actors, exploit kits, or KEV-linked campaigns are associated with this CVE at this time.

How to fix it

Upgrade libde265 to a release that includes a fix after commit 4d45a6b so zero-length NAL units cannot retain a NULL backing buffer before memcpy(). Rebuild and redeploy every statically or dynamically linked consumer (media servers, transcoders, image pipelines, mobile/desktop apps). If a patched package is not yet available, isolate decoders in crash-resilient workers with tight restart budgets, reject empty NAL units at the application or ingest boundary before they reach de265_push_NAL(), and avoid exposing raw NAL push APIs to untrusted callers. Inventory SBOM and package metadata for libde265 and downstream HEVC tooling, then roll the patched library through all environments.

How to confirm the fix worked

Enumerate hosts and images for libde265 (shared objects, vendored copies, language bindings, and container layers) and confirm they are newer than the affected commit 4d45a6b. Use SCA/SBOM and package-manager queries rather than crash reproduction. After upgrade, confirm the deployed binary or package changelog includes the NAL null-buffer fix, that services start cleanly, and that ingest still rejects empty or malformed NAL units at the edge. Regression-test legitimate HEVC playback and transcode paths only; do not use weaponized empty-NAL samples in shared environments.

Typical attack path

1. Identify an application or service that decodes untrusted HEVC/H.265 using libde265.
2. Deliver a bitstream, container, or API payload that includes a zero-length NAL unit to that decoder.
3. The service calls de265_push_NAL() on the empty NAL unit.
4. NAL_unit::set_data() invokes memcpy() with a NULL destination buffer.
5. The process hits undefined behavior and aborts, denying decoder availability until restart.

How to detect it

This is a crash-based denial of service, so look for evidence the decoder already aborted rather than for a persistent implant. Review process-manager and orchestrator events (unexpected worker exits, crash-looping media pods, OOM-killer is less typical than abort/SIGABRT). Inspect core dumps and sanitizer logs for frames in libde265, especially NAL_unit::set_data and de265_push_NAL, and for UBSan reports of a null pointer passed to memcpy. Correlate crashes with recent HEVC/H.265 uploads, stream ingest, or transcode jobs. Network IOCs are weak because the trigger is a well-formed-enough media payload with an empty NAL; hunt on crash artifacts and library symbols, not a unique packet signature. No named APT tooling is documented for this CVE.

• NAL_unit::set_data
• de265_push_NAL
• libde265
• libde265.so
• null pointer passed as argument 1, which is declared to never be null
• runtime error: null pointer passed as argument
• memcpy
• SIGABRT
• UndefinedBehaviorSanitizer

What your security team should do

• Inventory every product, container, and vendor component that ships or links libde265 and prioritize internet-facing media ingest, transcode, and thumbnail services.
• Patch or rebuild to a libde265 version that fixes the NULL NAL buffer handling as soon as vendors publish it; track commit 4d45a6b and later.
• Place decoders in isolated, restart-limited workers so a single abort cannot take down the whole application.
• Add ingest checks that drop zero-length NAL units before they reach de265_push_NAL().
• Watch process-manager and crash telemetry for libde265-linked aborts until the estate is patched.
• Reassess after vendor advisories: this CVE is not KEV-listed and has no known active exploitation, but treat new HEVC decoder crashes as potentially related until patched.