The practical priority is to identify the installed extension product and match it to the correct fixed build. This is not a case where one version number fits every affected installation.
What the vulnerability allows
Microsoft describes the flaw as follows: “Heap-based buffer overflow in Microsoft Windows Codecs Library allows an unauthorized attacker to execute code locally.”
The weakness is classified as CWE-122, a heap-based buffer overflow. In general technical terms, this type of memory-safety flaw involves writing beyond an allocated buffer in heap memory. Here, Microsoft identifies code execution as the security consequence.
The advisory also uses the description Microsoft Windows Codecs Library Remote Code Execution Vulnerability. Its reference to remote code execution needs careful reading: the attack vector in the CVSS assessment is local, and exploitation requires user interaction.
Security assessment
| Field | Microsoft assessment |
|---|---|
| CVE | CVE-2026-114167 |
| Title | HEVC Video Extensions Remote Code Execution Vulnerability |
| Severity | Important |
| CVSS base score | 7.8 |
| CVSS temporal score | 6.8 |
| Weakness | CWE-122 |
| Exploitation assessment | Exploitation Less Likely |
Publicly disclosed: No
Exploited: No
Customer action required: Yes
Microsoft supplies this complete CVSS vector:
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
The vector identifies a local attack vector, low attack complexity, no required privileges, required user interaction, unchanged scope, and high potential impact to confidentiality, integrity, and availability. Those impact ratings describe the assessed consequences of successful exploitation, not a statement that every attempted attack will succeed.
Why “remote” and “local” both appear
Microsoft explicitly explains the apparent mismatch between the title and the score. “Remote” refers to the attacker’s location; the attack itself is carried out locally. Microsoft notes that this can also be described as Arbitrary Code Execution (ACE).
The advisory gives a social-engineering example: an attacker persuades someone to download and open a specially crafted file from a website, leading to a local attack on that person’s computer.
That distinction matters when assessing exposure. A local attack vector should not be read as requiring the attacker to sit at the keyboard. Equally, the remote-code-execution title should not be read as describing an interaction-free network attack. Microsoft’s assessment specifically includes AV:L and UI:R.
The practical lesson is straightforward: caution around unexpected files remains relevant, but it does not replace installing the fixed extension.
Affected products and fixed builds
Microsoft lists the following product-to-build mappings:
| Affected product | Vendor fixed version |
|---|---|
| HEVC Video Extensions | 2.4.151.0 |
| HEVC Video Extensions for Licensed Applications | 2.4.150.0 |
| HEVC Video Extensions from Device Manufacturer | 2.4.149.0; 2.5.48.0 |
The exact remediation instructions are:
- For HEVC Video Extensions, update to fixed build 2.4.151.0 or later.
- For HEVC Video Extensions for Licensed Applications, update to fixed build 2.4.150.0 or later.
- For HEVC Video Extensions from Device Manufacturer, update to fixed build 2.4.149.0 or later; update to fixed build 2.5.48.0 or later.
Product identity matters as much as the version number. For example, the listed fixed build for HEVC Video Extensions for Licensed Applications is different from the one for HEVC Video Extensions. Administrators should therefore evaluate the product-and-version pair, rather than apply a single numerical threshold across all three products.
The manufacturer product also has two listed fixed builds. Preserve those separate entries in remediation tracking instead of reducing the advisory to one universal minimum.
What users and administrators should do
Based on Microsoft’s product-specific mappings, a practical remediation workflow is to:
- Identify which of the three affected extension products is installed.
- Record its installed version.
- Apply the corresponding remediation above.
- Verify the installed product version after updating before marking the device remediated.
This verification step is important: an update deployment record and a confirmed fixed version are not the same evidence.
Microsoft’s Exploitation Less Likely assessment provides prioritization context, but it does not cancel the explicit requirement for customer action. The supported response is to update the affected extension, verify the correct product-specific build, and retain that result as the remediation record.
References
- Official MSRC or vendor evidence api.msrc.microsoft.com
- Official MSRC or vendor evidence msrc.microsoft.com
- Official MSRC or vendor evidence api.msrc.microsoft.com