Windows MSHTML Spoofing CVE-2024-43573 Explained

Windows MSHTML CVE-2024-43573 is a spoofing vulnerability in the legacy Trident rendering engine that Microsoft patched on October 8, 2024. It was exploited in the wild before the patch landed. The CVSS 6.5 score undersells it because in realistic phishing chains this class of flaw turns into code execution when paired with a second bug, which is exactly the pattern Void Banshee used through 2024. Understanding why MSHTML is still in Windows long after Internet Explorer was retired is the core of the story.

What exactly is CVE-2024-43573?

CVE-2024-43573 is a platform spoofing vulnerability in MSHTML that allows a crafted document or URL to misrepresent the true file type or origin to the user. The flaw lets an attacker render a payload inside the MSHTML engine while presenting a benign-looking UI element, so the user clicks through believing they are interacting with a trusted file. The vulnerability is a variant of CVE-2024-38112, which Check Point Research disclosed in July 2024 after observing it used to bypass protections in Internet Explorer mode and in applications that still embed MSHTML.

Microsoft acknowledged active exploitation at patch time and credited the Check Point team. The affected surface is every supported Windows client and server where mshtml.dll ships, which is all of them. Even though Edge replaced IE, Office, Outlook, and third-party applications like HTML Help and some CRM clients still invoke MSHTML through COM.

How does the spoofing chain weaponize into code execution?

The spoofing chain weaponizes by combining MSHTML rendering with a Mark-of-the-Web (MOTW) bypass to launch a payload as if it were a trusted local file. The typical flow looks like this:

1. Victim receives a phishing email containing a .url or .lnk file, or a ZIP containing one
2. The shortcut points at an attacker-controlled URL with a custom protocol handler or a deceptive icon
3. Windows uses MSHTML to parse the shortcut target, and the spoofing bug causes the OS to render the target inside an MSHTML window that looks like a trusted preview
4. The rendered content uses mhtml: or CHM tricks to execute JavaScript or spawn Internet Explorer mode
5. A follow-on bug such as the Atlantida Stealer loader runs and drops the final payload

Void Banshee, observed by Trend Micro and Check Point, used exactly this flow against finance and North American targets throughout 2024. The payload was Atlantida Stealer, which exfiltrated browser credentials, crypto wallets, and Telegram sessions.

The reason the chain works is that MSHTML treats files loaded via mhtml: as though the original source matters less than the rendering context, which breaks the zone model that Windows SmartScreen relies on. SmartScreen sees a PDF icon and a local rendering surface and waves it through.

Why is MSHTML still in modern Windows at all?

MSHTML is still shipped because hundreds of enterprise applications bind to its COM interfaces and Microsoft cannot remove it without breaking those dependencies. Applications that embed WebBrowser controls, older versions of Office that render Rich HTML email, Windows Help, and a long tail of line-of-business tools all link against mshtml.dll. When Microsoft retired IE, they removed the browser chrome but left the engine because removing it would have broken enterprise workflows en masse.

The consequence is a steady drumbeat of MSHTML CVEs: CVE-2021-40444 (the MSHTML ActiveX RCE that started the modern wave), CVE-2022-41128 (JScript9 type confusion), CVE-2024-38112 (the July 2024 sibling), and now CVE-2024-43573. Each one lives in a legacy parser that does not receive the same fuzzing and hardening investment as Chromium-based Edge. Attackers know this, and phishing kits have templates specifically for MSHTML chains.

How do defenders detect and contain this class of attack?

Defenders detect MSHTML chains by monitoring for mshtml.dll and iexplore.exe loaded in unusual parent processes and for outbound connections from those processes to recently registered domains. High-signal telemetry includes:

• explorer.exe spawning ie4uinit.exe or iexplore.exe from a user-writable path
• rundll32.exe loading mshtml.dll with command lines referencing mhtml: or file://
• Office applications spawning mshta.exe or rundll32 with HTML content arguments
• .url or .lnk files in Downloads or Temp directories with URL=file:// or URL=mhtml: inside

Sysmon event ID 1 plus image-load events give you enough lineage. Many EDRs ship built-in rules for this after the CVE-2021-40444 round, but they tend to miss the .url variant because .url files are benign in most corporate environments. Writing a detection for .url files containing mhtml: or CHM:// is a two-line Sigma rule and worth deploying.

For containment, the application-control tier matters most. Removing MSHTML is not an option, but you can:

• Deny execution of mshta.exe via AppLocker or Windows Defender Application Control
• Block .url and .lnk attachments at the email gateway
• Disable Internet Explorer mode in Edge for users who do not need it
• Enforce ASR rule "Block all Office applications from creating child processes"

What supply chain implications follow from MSHTML zero-days?

MSHTML zero-days have outsized supply chain impact because many ISV products embed MSHTML via the WebBrowser COM control without advertising it. A compromise through an embedded MSHTML instance in a third-party CRM, help viewer, or installer wizard gives attackers a foothold inside your environment without ever touching the actual browser. The patch flow is also uneven: Windows patches close the underlying DLL, but applications that ship their own COM interop layers or cache older DLLs in their install directories can stay vulnerable even after Windows is updated.

This is why a pure CVE-to-patch view of third-party risk misses the real problem. You need an inventory of every application that loads mshtml.dll into its process space at runtime, not just the ones that declare it in an installer manifest. Binary analysis against deployed artifacts is the only reliable way to find them. Procurement and TPRM questionnaires almost never catch MSHTML dependencies because vendors themselves frequently do not know their embedded controls pull it in transitively.

What does a clean remediation plan look like?

Clean remediation requires four parallel tracks rather than one. First, patch Windows to the October 2024 cumulative update or later on every endpoint and server. Second, audit every managed application for embedded MSHTML usage and file tickets with vendors whose products still ship their own COM wrappers. Third, enable ASR rules and AppLocker policies that block the typical MSHTML abuse vectors. Fourth, update your phishing awareness training and email gateway filters to flag .url and .lnk attachments by default.

Do not treat MSHTML CVEs as one-off events. The cadence since 2021 guarantees another variant within 12 months, and the controls above should be treated as persistent infrastructure rather than incident-response work.

How Safeguard.sh Helps

Safeguard.sh enumerates every deployed artifact that statically or dynamically links mshtml.dll through 100-level dependency scanning against binaries, not just manifests, so embedded MSHTML usage in third-party products is visible on day one. Reachability analysis cuts 60 to 80 percent of noise by distinguishing applications that actually invoke the vulnerable MSHTML parsing paths from those that link the DLL but never call the affected functions. Griffin AI autonomously generates ASR policy, AppLocker rules, and EDR detections tuned to your environment, and container self-healing rebuilds affected Windows container images against patched bases. SBOM generation covers Windows binaries alongside Linux, and the TPRM workflow surfaces vendors whose products ship their own MSHTML interop layers.