CVE-2026-49346

What it actually does

This vulnerability is a heap-based buffer overflow in libde265 before version 1.1.0. A malformed H.265/HEVC bitstream can specify very large sequence parameter set dimensions combined with 16-bit bit depth, causing a signed integer overflow in de265_image_get_buffer() when calculating image plane allocation sizes. The overflow causes libde265 to allocate a much smaller heap buffer than required, while later image initialization logic calculates the true size using size_t and writes far beyond the allocated buffer. The most likely outcomes are process crash and denial of service; memory corruption may also permit limited data corruption or potentially code execution depending on compiler hardening, allocator behavior, sandboxing, and how the library is embedded.

Why it matters to the business

Applications, media services, content-processing pipelines, thumbnailers, browsers, messaging tools, security gateways, or document/media preview systems that use vulnerable libde265 versions can be crashed by processing a malicious H.265 video file or stream. This can interrupt media ingestion, preview generation, file scanning, transcoding, or user-facing playback workflows. Because exploitation requires a victim application or service to parse attacker-supplied media, exposure is highest where untrusted videos are uploaded, previewed, transcoded, scanned, or opened by users. The vulnerability is not currently in CISA KEV, has low EPSS, and has no reported mature public exploitation, but the bug class is reliable for denial of service and should be remediated wherever libde265 handles untrusted content.

How an attack unfolds

An attacker crafts an H.265/HEVC bitstream with sequence parameter set values that drive extremely large image dimensions and 16-bit bit depth. The attacker then delivers the file or stream to software that uses libde265 prior to version 1.1.0, such as by upload, attachment, shared media, embedded content, or streaming input. When the application decodes the media, libde265 reaches de265_image_get_buffer(), where the signed allocation-size calculation overflows and wraps to a small value. The decoder allocates an undersized heap buffer, then fill_image() proceeds using a wider size calculation and writes a very large amount of image data into that buffer. This corrupts heap memory and commonly terminates the process, causing denial of service. In some deployments, repeated submissions may repeatedly crash worker processes or media services until the malicious input is removed or decoding is isolated.

How to fix it

Upgrade libde265 to version 1.1.0 or later wherever it is installed directly or bundled into applications, containers, media frameworks, desktop packages, image/video previewers, browsers, document processors, or transcoding services. If using operating system packages, apply the vendor security update that backports the fix, even if the displayed upstream version remains below 1.1.0. Rebuild statically linked applications and container images that embed libde265. Where immediate upgrade is not possible, reduce exposure by disabling H.265/HEVC decoding for untrusted content, rejecting or quarantining HEVC uploads, limiting maximum decoded dimensions and bit depth, running media parsers in a sandbox with memory and CPU limits, and isolating decoding workers so crashes do not affect broader services.

How to confirm the fix worked

Confirm that all runtime locations use libde265 version 1.1.0 or a vendor-patched build. Inventory both dynamically linked and statically bundled copies; package-manager checks alone may miss embedded library copies in appliances, containers, desktop applications, and media-processing tools. Validate package status with the relevant OS package manager, inspect container images and application bundles for libde265 shared objects, and verify linked libraries with tools such as ldd, otool, readelf, strings, or software composition analysis. Functional validation can include running known malformed HEVC regression samples in a non-production test environment and confirming the decoder rejects the input or fails safely without heap-buffer-overflow, abnormal memory growth, or process crash. Review crash telemetry after patching to ensure prior signatures involving de265_image_get_buffer(), fill_image(), or libde265/image.cc no longer occur.

Typical attack path

1. Identify an application, service, or processing pipeline that accepts or opens H.265/HEVC media and uses libde265 before version 1.1.0.
2. Create a malformed H.265 bitstream with oversized SPS dimensions and 16-bit bit depth values that trigger the allocation-size overflow.
3. Deliver the crafted media through an upload form, messaging workflow, email attachment, content feed, media stream, shared file, or other untrusted input path.
4. Wait for the target application or backend worker to decode or inspect the media using vulnerable libde265 code.
5. Trigger heap memory corruption when the decoder allocates an undersized buffer and then writes far beyond it during image initialization.
6. Cause the decoding process, worker, previewer, scanner, or application to crash, potentially producing repeated denial of service if the file is automatically retried.

How to detect it

To determine whether exploitation already occurred, review logs and telemetry from applications and services that parse HEVC/H.265 media, especially upload processors, thumbnail generators, transcoders, media previewers, content scanners, and desktop applications. Look for crashes, worker restarts, segmentation faults, aborts, out-of-memory-like behavior, or allocator corruption errors that occurred immediately after processing .hevc, .h265, .265, .mkv, .mp4, or similar media files. Useful sources include application logs, systemd journal, container stdout/stderr, Kubernetes pod restart events, crash dumps, core files, endpoint detection telemetry, macOS crash reports, Windows Error Reporting events for applications bundling libde265, and Linux kernel logs. In crash stacks or symbols, look for libde265 functions such as de265_image_get_buffer and fill_image, source references to libde265/image.cc, and heap-buffer-overflow reports from ASan or allocator hardening. Correlate crash times with file upload records, message attachments, content-ingestion queues, or media URLs, and preserve the triggering sample for isolated analysis. Because no unique public exploit payload indicators are available, detection should focus on crash signatures, decoder stack traces, anomalous HEVC inputs with unusually large dimensions or 16-bit bit depth, and repeated processing failures tied to the same media object.

• de265_image_get_buffer
• fill_image
• libde265/image.cc:128
• libde265/image.cc
• libde265.so
• libde265.dylib
• libde265.dll
• heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow
• SEGV in de265_image_get_buffer
• SIGSEGV in de265_image_get_buffer
• SIGABRT in de265_image_get_buffer
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• corrupted double-linked list
• double free or corruption
• HEVC
• H.265
• Sequence parameter set
• SPS
• bit_depth_luma_minus8
• bit_depth_chroma_minus8

What your security team should do

• Prioritize patching systems that automatically process untrusted videos, including upload handlers, thumbnailers, transcoders, content scanners, mail or messaging attachments, and media preview services.
• Upgrade libde265 to 1.1.0 or a vendor-patched equivalent, then rebuild and redeploy applications, containers, and appliances that bundle the library.
• Search software inventories and SBOMs for libde265, struktur libde265, libde265.so, and statically linked HEVC decoder components.
• Temporarily disable or restrict H.265/HEVC processing for untrusted content if patching cannot be completed quickly.
• Apply sandboxing, seccomp/AppArmor/SELinux profiles, container isolation, low-privilege execution, and memory limits to media decoding workers to reduce crash impact and exploitability.
• Add monitoring for repeated crashes in media-processing services and correlate them with recently received HEVC/H.265 files or streams.
• Retain suspicious media samples that correlate with decoder crashes for offline analysis in an isolated forensic environment.
• Do not treat the low EPSS score as a reason to ignore the issue where automated untrusted media processing is exposed; denial-of-service exploitation can be straightforward once a trigger file exists.