CVE-2026-49337

What it actually does

This vulnerability is an availability issue in libde265, an H.265/HEVC video decoding library. Before version 1.0.20, specially crafted sequences of H.265 NAL units can cause decoder_context::read_slice_NAL() to attach slice headers to a picture object that has already finished and has no active image unit. Those attacker-controlled headers accumulate on the heap and are not released until the picture is released, which may not occur during continuous or long-running decoding. The practical result is unbounded memory growth that can exhaust process or system memory and crash or stall software that uses libde265 to parse untrusted H.265 content.

Why it matters to the business

Successful exploitation can disrupt services, applications, media-processing pipelines, thumbnailers, browsers, image/video preview components, or backend systems that decode H.265 content using vulnerable libde265 versions. The likely consequence is denial of service through memory exhaustion rather than data theft or code execution. Because exploitation requires a victim application or service to process attacker-supplied media, risk is highest for internet-facing upload, transcoding, messaging, surveillance, content moderation, or streaming workflows that automatically inspect or decode H.265 files or streams. The CVSS score and EPSS are low and there is no known KEV listing or mature public exploitation signal, but the library’s common use in downstream products means exposure may exist indirectly through packaged applications.

How an attack unfolds

An attacker prepares an H.265/HEVC file or stream containing a crafted sequence of NAL units that triggers incorrect slice-header retention in vulnerable libde265 versions. The attacker then causes a target application to decode that content, for example by uploading a video to a service, sending a media file to a user, hosting content that a previewer or browser component processes, or feeding a stream into an automated media pipeline. When the vulnerable decoder processes the malformed NAL sequence, it repeatedly attaches slice headers to a completed picture object without releasing them. In continuous decoding scenarios, memory usage can grow until the decoding process becomes slow, is terminated by the operating system, crashes due to allocation failure, or causes broader resource contention on the host.

How to fix it

Upgrade libde265 to version 1.0.20 or later wherever it is used directly or bundled into applications. Because libde265 is often consumed transitively through media frameworks, image libraries, operating-system packages, desktop applications, browsers, thumbnailers, and container images, inventory both direct packages and embedded copies. Rebuild statically linked applications against the fixed library. If immediate upgrade is not possible, reduce exposure by disabling automatic H.265/HEVC decoding for untrusted content, blocking or quarantining HEVC uploads where feasible, isolating media processing in sandboxed workers, applying strict memory and CPU limits to decoder processes, and using queue-level rate limits to prevent repeated resource exhaustion.

How to confirm the fix worked

Confirm that all installed, bundled, or containerized copies of libde265 report version 1.0.20 or later. Validate operating-system package versions using the relevant package manager, and inspect application containers and statically linked binaries where package metadata may not be sufficient. Confirm that media-processing workflows, upload handlers, preview generators, and streaming components use the patched library path at runtime. Where safe and authorized, run regression tests with malformed H.265 inputs to verify that memory use remains bounded and that decoder processes recover cleanly. Also verify that process-level memory limits, sandboxing, and monitoring alerts are in place for services that must continue accepting untrusted media.

Typical attack path

1. Identify an application, service, or embedded product that uses libde265 before version 1.0.20 to decode H.265/HEVC content.
2. Craft or obtain an H.265 media file or stream with a malicious sequence of NAL units that triggers unbounded slice-header retention.
3. Deliver the crafted media to the target through an upload feature, message attachment, web-hosted media resource, streaming endpoint, or other content ingestion path.
4. Wait for the target application or automated backend workflow to decode or preview the media.
5. The vulnerable decoder accumulates heap allocations while processing the crafted NAL sequence.
6. The affected process experiences excessive memory consumption, degraded performance, crash, or termination by resource controls or the operating system.

How to detect it

To assess whether exploitation may have already occurred, review logs and telemetry from systems that process H.265/HEVC media, including upload services, transcoding workers, preview/thumbnail generators, desktop crash reporters, container runtime events, kernel logs, and application error logs. Look for sudden or repeated memory growth in processes linked to libde265, ffmpeg-based workflows, media previewers, or applications that decode HEVC content. Investigate out-of-memory kills, allocation failures, segmentation faults, worker restarts, stalled jobs, or queue backlogs that correlate with processing a particular H.265 file or stream. In web or API logs, identify media uploads shortly before crashes or OOM events, especially files labeled as HEVC/H.265 or with extensions such as .heic, .heif, .h265, .hevc, .mkv, or .mp4. Preserve suspect media objects and hash them for comparison across systems. There are no known public attacker infrastructure indicators for this issue, so detection should focus on process behavior, crash artifacts, resource exhaustion, and correlation to recently processed media content.

• libde265
• decoder_context::read_slice_NAL
• read_slice_NAL
• std::bad_alloc
• Out of memory
• out of memory: Killed process
• Killed process
• oom-killer
• MemoryError
• Cannot allocate memory
• malloc failed
• allocation failed
• HEVC
• H.265
• .h265
• .hevc
• .heic
• .heif

What your security team should do

• Prioritize patching internet-facing or automated media-ingestion systems that decode user-supplied H.265/HEVC content.
• Upgrade libde265 to version 1.0.20 or later across operating-system packages, containers, desktop applications, appliances, and statically linked builds.
• Search software bills of materials, package manifests, container images, and vendor advisories for bundled libde265 copies, including transitive dependencies.
• Apply sandboxing and memory limits to media decoding workers so a malformed file cannot exhaust host-level resources.
• Temporarily restrict H.265/HEVC uploads, previews, or transcoding from untrusted sources if patching will be delayed.
• Monitor decoder processes for abnormal heap growth, repeated out-of-memory kills, crashes, or spikes correlated with specific uploaded media files or streams.
• Retain suspicious H.265 samples and associated access logs for forensic review if unexplained media-processing crashes or OOM events are observed.