CVE-2024-43452
published 2024-11-12CVE-2024-43452: Windows Registry Elevation of Privilege Vulnerability
high7.5CVSS 3.1
AVNACHPRNUIRSUCHIHAH
Windows Registry Elevation of Privilege Vulnerability
Affected
32 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| microsoft | windows_10_1809 | < 10.0.17763.6532 | 10.0.17763.6532 |
| microsoft | windows_10_21h2 | < 10.0.19044.5131 | 10.0.19044.5131 |
| microsoft | windows_10_22h2 | < 10.0.19045.5131 | 10.0.19045.5131 |
| microsoft | windows_10_version_1809 | >= 10.0.17763.0 < 10.0.17763.6532 | 10.0.17763.6532 |
| microsoft | windows_10_version_21h2 | >= 10.0.19043.0 < 10.0.19044.5131 | 10.0.19044.5131 |
| microsoft | windows_10_version_22h2 | >= 10.0.19045.0 < 10.0.19045.5131 | 10.0.19045.5131 |
| microsoft | windows_11_22h2 | < 10.0.22621.4460 | 10.0.22621.4460 |
| microsoft | windows_11_23h2 | < 10.0.22631.4460 | 10.0.22631.4460 |
| microsoft | windows_11_24h2 | < 10.0.26100.2314 | 10.0.26100.2314 |
| microsoft | windows_11_version_22h2 | >= 10.0.22621.0 < 10.0.22621.4460 | 10.0.22621.4460 |
| microsoft | windows_11_version_22h3 | >= 10.0.22631.0 < 10.0.22631.4460 | 10.0.22631.4460 |
| microsoft | windows_11_version_23h2 | >= 10.0.22631.0 < 10.0.22631.4460 | 10.0.22631.4460 |
| microsoft | windows_11_version_24h2 | >= 10.0.26100.0 < 10.0.26100.2314 | 10.0.26100.2314 |
| microsoft | windows_server_2008_service_pack_2 | >= 6.0.6003.0 < 6.0.6003.22966 | 6.0.6003.22966 |
| microsoft | windows_server_2019 | < 10.0.17763.6532 | 10.0.17763.6532 |
| microsoft | windows_server_2019 | >= 10.0.17763.0 < 10.0.17763.6532 | 10.0.17763.6532 |
| microsoft | windows_server_2022 | < 10.0.20348.2849 | 10.0.20348.2849 |
| microsoft | windows_server_2022 | >= 10.0.20348.0 < 10.0.20348.2849 | 10.0.20348.2849 |
| microsoft | windows_server_2022_23h2 | < 10.0.25398.1251 | 10.0.25398.1251 |
| microsoft | windows_server_2025 | < 10.0.26100.2314 | 10.0.26100.2314 |
| microsoft | windows_server_2025 | >= 10.0.26100.0 < 10.0.26100.2314 | 10.0.26100.2314 |
| msrc | windows_10_version_1809 | — | — |
| msrc | windows_10_version_21h2 | — | — |
| msrc | windows_10_version_22h2 | — | — |
| msrc | windows_11_version_22h2 | — | — |
Project0
The Windows Registry Adventure #8: Practical exploitation of hive memory corruption - Project Zero
project_zero·2025-05-01
CVE-2019-0881 The Windows Registry Adventure #8: Practical exploitation of hive memory corruption - Project Zero
Posted by Mateusz Jurczyk, Google Project Zero
In the previous blog post, we focused on the general security analysis of the registry and how to effectively approach finding vulnerabilities in it. Here, we will direct our attention to the exploitation of hive-based memory corruption bugs, i.e., those that allow an attacker to overwrite data within an active hive mapping in memory. This is a class of issues characteristic of the Windows registry, but universal enough that the techniques described here are applicable to 17 of my past vulnerabilities, as well as likely any similar bugs in the future. As we know, hives exhibit a very special behavior in terms of low-level memory management (how and where they are mapped in memory), handling of allocated and freed memory chunks by a custom al
Project0
The Windows Registry Adventure #7: Attack surface analysis - Project Zero
project_zero·2025-05-01
CVE-2010-0237 The Windows Registry Adventure #7: Attack surface analysis - Project Zero
Posted by Mateusz Jurczyk, Google Project Zero
In the first three blog posts of this series, I sought to outline what the Windows Registry actually is, its role, history, and where to find further information about it. In the subsequent three posts, my goal was to describe in detail how this mechanism works internally – from the perspective of its clients (e.g., user-mode applications running on Windows), the regf format used to encode hives, and finally the kernel itself, which contains its canonical implementation. I believe all these elements are essential for painting a complete picture of this subsystem, and in a way, it shows my own approach to security research. One could say that going through this tedious process of getting to know the target unnecessarily lengthens the total
Project0
The Windows Registry Adventure #6: Kernel-mode objects - Project Zero
project_zero·2025-04-01
CVE-2023-21748 The Windows Registry Adventure #6: Kernel-mode objects - Project Zero
Posted by Mateusz Jurczyk, Google Project Zero
Welcome back to the Windows Registry Adventure! In the previous installment of the series, we took a deep look into the internals of the regf hive format. Understanding this foundational aspect of the registry is crucial, as it illuminates the design principles behind the mechanism, as well as its inherent strengths and weaknesses. The data stored within the regf file represents the definitive state of the hive. Knowing how to parse this data is sufficient for handling static files encoded in this format, such as when writing a custom regf parser to inspect hives extracted from a hard drive. However, for those interested in how regf files are managed by Windows at runtime, rather than just their behavior in isolation, there's a whole othe
Project0
The Windows Registry Adventure #5: The regf file format - Project Zero
project_zero·2024-12-01
CVE-2015-0073 The Windows Registry Adventure #5: The regf file format - Project Zero
Posted by Mateusz Jurczyk, Google Project Zero
As previously mentioned in the second installment of the blog post series ("A brief history of the feature"), the binary format used to encode registry hives from Windows NT 3.1 up to the modern Windows 11 is called regf. In a way, it is quite special, because it represents a registry subtree simultaneously on disk and in memory, as opposed to most other common file formats. Documents, images, videos, etc. are generally designed to store data efficiently on disk, and they are subsequently parsed to and from different in-memory representations whenever they are read or written. This seems only natural, as offline storage and RAM come with different constraints and requirements. On disk, it is important that the data is packed as tightly as
GHSA
GHSA-4jpm-2crw-5qqr: Windows Registry Elevation of Privilege Vulnerability
ghsa_unreviewed·2024-11-12
CVE-2024-43452 [HIGH] CWE-367 GHSA-4jpm-2crw-5qqr: Windows Registry Elevation of Privilege Vulnerability
Windows Registry Elevation of Privilege Vulnerability
Microsoft
Windows Registry Elevation of Privilege Vulnerability
vendor_msrc·2024-11-12·CVSS 7.5
CVE-2024-43452 [HIGH] CWE-367 Windows Registry Elevation of Privilege Vulnerability
Windows Registry Elevation of Privilege Vulnerability
FAQ: What privileges could be gained by an attacker who successfully exploited this vulnerability?
An attacker who successfully exploited this vulnerability could gain SYSTEM privileges.
FAQ: According to the CVSS metric, the attack complexity is high (AC:H). What does that mean for this vulnerability?
Successful exploitation of this vulnerability requires an attacker to have a deep understanding of the system and the ability to manipulate its components to trigger a specific condition. Successful exploitation is not guaranteed and depends on a combination of factors that may include the environment, system configuration, and the presence of additional security measures.
FAQ: According to the CVSS metric, user interaction is required
No detection rules found.
No public exploits indexed.
2024-11-12
Published