CVE-2026-45383

What it actually does

CVE-2026-45383 is an out-of-bounds heap read in libde265 before version 1.0.19, in decoder_context::decode_slice_unit_WPP() while decoding HEVC/H.265 Wavefront Parallel Processing slices. A crafted HEVC bitstream can manipulate PPS/SPS-derived dimensions so that ctbAddrRS is calculated beyond the bounds of pps.CtbAddrRStoTS, causing the decoder to read past the allocated vector. The most likely technical result is process instability or crash of the application or service using libde265 to parse untrusted media. Based on the published details, this is not primarily a code-execution flaw; the impact is expected to be availability-focused, though any memory-safety bug in media parsing should be treated cautiously in exposed or automated decoding pipelines.

Why it matters to the business

Organizations that process HEVC/H.265 media with vulnerable libde265 versions could experience crashes in media-processing applications, thumbnailers, transcoders, messaging platforms, content-ingestion systems, security scanners, or desktop viewers when they handle a malicious video file or stream. This can disrupt user-facing services, batch processing, moderation workflows, or automated content pipelines. The vulnerability is not in CISA KEV, is not currently associated with ransomware use, and has low EPSS at publication-plus-21-days, so broad exploitation urgency is lower than for actively exploited remote code execution flaws; however, internet-facing or high-volume media ingestion systems should still prioritize remediation because exploitation only requires supplying crafted media to a vulnerable decoder path.

How an attack unfolds

An attacker creates a malformed HEVC/H.265 file or stream with crafted PPS/SPS headers and WPP slice data. When a vulnerable application using libde265 before 1.0.19 decodes that content, the decoder computes ctbAddrRS as ctbRow * ctbsWidth during WPP entry-point processing. The crafted metadata causes that computed index to exceed the size of the CtbAddrRStoTS vector, and the decoder reads beyond the heap allocation. In practical terms, the attacker needs a delivery path that causes the target to decode the media: uploading a file to a content service, sending media to a messaging or collaboration platform, embedding media where a crawler or preview generator will process it, or convincing a user to open the file in an affected viewer. Successful exploitation is expected to cause a decoder crash or service worker failure rather than reliable remote code execution.

How to fix it

Upgrade libde265 to version 1.0.19 or later wherever it is used directly or bundled into downstream software. If operating-system packages, container images, desktop applications, browsers, media frameworks, or vendor products embed libde265, update those packages to versions that include the 1.0.19 fix. Where immediate patching is not possible, reduce exposure by disabling HEVC/H.265 decoding for untrusted content, blocking or quarantining HEVC uploads, routing media decoding through isolated sandboxes, limiting automatic preview/thumbnail generation, enforcing worker process restarts and resource limits, and restricting unauthenticated media ingestion endpoints. Rebuild statically linked applications against the fixed library, because replacing a shared library alone will not fix statically bundled copies.

How to confirm the fix worked

Confirm all deployed copies of libde265 report version 1.0.19 or later, including package-managed libraries, containers, appliances, desktop software, and statically linked binaries. On Linux, check package metadata and shared objects using package managers, software bills of materials, container scans, and binary inspection for libde265.so. Validate that downstream applications have been restarted or rebuilt after the update. If a proof-of-concept test file is available from a trusted source, test only in an isolated lab and confirm that vulnerable builds crash while fixed builds reject or safely handle the malformed HEVC input. For exposure validation, identify services that accept or automatically process HEVC/H.265 media and verify whether they use libde265 or an affected bundled copy.

Typical attack path

1. Identify an application, service, library, plugin, or package that uses libde265 before version 1.0.19 to decode HEVC/H.265 content.
2. Craft an HEVC bitstream with PPS/SPS and WPP slice parameters that cause ctbAddrRS to exceed pps.CtbAddrRStoTS.size().
3. Deliver the malicious media through an accepted ingestion path, such as file upload, email attachment, chat message, web content, media stream, or automated preview/thumbnail generation workflow.
4. Trigger decoding by the vulnerable libde265 code path.
5. Cause an out-of-bounds heap read, typically resulting in a crash, failed media job, denial of service, or abnormal termination of the consuming process.

How to detect it

Look for evidence of attempted exploitation in application crash logs, media-processing worker logs, core dumps, endpoint telemetry, container logs, and upload or content-ingestion records. Relevant events include crashes or abnormal exits of applications that decode HEVC/H.265 content, especially immediately after processing uploaded or externally supplied video. Search for AddressSanitizer or crash reports referencing decoder_context::decode_slice_unit_WPP(), libde265/decctx.cc, CtbAddrRStoTS, heap-buffer-overflow, SIGSEGV, SIGABRT, or libde265.so. Correlate crashes with recently received media files, upload source IPs, user agents, filenames, message IDs, object-storage keys, or URLs, while treating the media itself as hostile. In Linux environments, review systemd journals, kernel logs, coredumpctl entries, container orchestrator restart events, and application-specific transcoder or thumbnailer logs. On endpoints, review EDR process crash telemetry for media viewers or services loading libde265. Because exploitation artifacts are primarily malformed media inputs rather than durable host indicators, absence of a static IOC does not rule out attempted exploitation.

• heap-buffer-overflow
• decoder_context::decode_slice_unit_WPP
• libde265/decctx.cc
• pps.CtbAddrRStoTS
• CtbAddrRStoTS
• ctbAddrRS
• libde265.so
• AddressSanitizer: heap-buffer-overflow
• SUMMARY: AddressSanitizer
• SIGSEGV
• SIGABRT
• HEVC
• H.265
• hvc1
• hev1

What your security team should do

• Inventory all applications, services, containers, and endpoints that decode HEVC/H.265 media and determine whether they use libde265 before 1.0.19.
• Prioritize patching internet-facing, unauthenticated, or high-volume media ingestion systems before lower-risk desktop-only use cases.
• Upgrade libde265 to 1.0.19 or later, and rebuild any statically linked downstream applications.
• Temporarily disable or sandbox HEVC/H.265 processing for untrusted uploads where patching cannot be completed quickly.
• Add monitoring for repeated media-decoder crashes, thumbnailer failures, segmentation faults, AddressSanitizer reports, and abnormal worker restarts associated with HEVC content.
• Review recent uploads, messages, ingestion queues, and crash telemetry for malformed HEVC files processed shortly before decoder failures.
• Ensure container base images and third-party media-processing tools are refreshed, not only the host operating system package.
• Because this is not KEV-listed and has low EPSS, manage it through normal vulnerability remediation SLAs unless the vulnerable decoder is reachable from unauthenticated external users.