How to Fix CVE-2012-4969: Use After Free in Internet Explorer

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2022-06-08, federal due date 2022-06-22.

What is CVE-2012-4969?

CVE-2012-4969 is a use-after-free vulnerability in the CMshtmlEd::Exec function inside mshtml.dll, the HTML rendering engine (Trident) used by Microsoft Internet Explorer 6, 7, 8 and 9. A specially crafted web page can free a CMshtmlEd object and then trigger a code path that reuses the dangling pointer. Because the attacker controls what gets allocated into the freed memory, that stale pointer can be steered to attacker-supplied data, which yields arbitrary code execution in the context of the user running the browser.

This is a classic CWE-416 (Use After Free) memory-corruption bug in a web browser, so the exploitation model is drive-by: the victim only has to visit a malicious or compromised page. There is no authentication and no further user interaction beyond loading the page, which is why the CVSS 3.1 base score is 8.1 (High) with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The high attack complexity reflects the heap-grooming and memory-layout work the exploit must do reliably; once it lands, the technical impact is total (confidentiality, integrity and availability all High).

This was a genuine zero-day. It was found being exploited in the wild in September 2012 (initially tied to watering-hole attacks), a working Metasploit module (windows/browser/ie_execcommand_uaf) appeared within days, and Microsoft shipped an out-of-band fix on 2012-09-21. CISA later added it to the Known Exploited Vulnerabilities catalog on 2022-06-08.

Why this CVE matters

The vulnerable code is in mshtml.dll itself, the shared Trident engine. That matters because anything that hosts the WebBrowser/MSHTML control: not just iexplore.exe, is reachable. HTML email rendered through the IE engine, third-party apps embedding the WebBrowser control, and HTML Help (.chm) content all run through the same vulnerable surface. On Windows XP and Windows Server 2003 era systems where this CVE was most prevalent, IE was deeply integrated, so "we don't use Internet Explorer" was not an effective control.

Because exploitation gives code execution as the logged-on user, the blast radius is exactly that user's privileges. An administrator browsing the web on a vulnerable box hands an attacker administrative-level execution. This is why standard hardening guidance for the era. run as a standard user, not as a local administrator, measurably reduced the impact of this exact bug.

Identify whether you are affected

Internet Explorer ships as a Windows component, so there is no Linux package and no dpkg/rpm entry to check: ignore any generic package-manager advice for this CVE. Confirm the installed IE version and whether the MS12-063 update (KB2744842) is present.

# Installed Internet Explorer version (run in an elevated PowerShell or cmd)
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Internet Explorer').svcVersion
# Older builds expose the value under 'Version' instead of 'svcVersion':
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Internet Explorer').Version

# File version of the vulnerable binary itself
(Get-Item "$env:WINDIR\System32\mshtml.dll").VersionInfo.FileVersion

# Is the fix (KB2744842) installed?
Get-HotFix -Id KB2744842 -ErrorAction SilentlyContinue
wmic qfe get HotFixID | findstr 2744842

IE 6 through IE 9 on any then-supported Windows release is affected. IE 10 was not affected by this issue. If KB2744842 (or a later cumulative IE security rollup that supersedes it) is not present and you are running IE 6-9, you are exposed.

How to fix CVE-2012-4969

The fix is Microsoft security bulletin MS12-063, delivered as update KB2744842, released as an out-of-band patch on 21 September 2012. There is a separate KB per IE version and OS, but Windows Update and the Microsoft Update Catalog resolve the correct package automatically. Any modern, fully patched Windows install that still has IE already includes the fix through the cumulative IE security updates that supersede KB2744842, applying the latest IE cumulative update is the durable fix.

Option A. Windows Update (recommended)

# Trigger Windows Update and confirm the IE security update applies.
# On systems with the PSWindowsUpdate module available:
Install-Module PSWindowsUpdate -Force -SkipPublisherCheck -Confirm:$false
Import-Module PSWindowsUpdate
Get-WindowsUpdate -KBArticleID KB2744842
Install-WindowsUpdate -KBArticleID KB2744842 -AcceptAll -AutoReboot

# On legacy systems without PSWindowsUpdate, use the built-in control panel
# (Windows Update) or run the WUA scan from cmd:
#   wuauclt /detectnow /updatenow

Option B, install the KB2744842 package directly (offline / WSUS)

# Download the exact KB2744842 package for your IE version and OS/architecture
# from the Microsoft Update Catalog (https://www.catalog.update.microsoft.com),
# then install the .msu silently and reboot.
wusa.exe C:\Patches\IE9-WindowsXP-KB2744842-x86-ENU.exe /quiet /norestart
# (the package name varies: IE8/IE9, x86/x64, and the OS string differ per build)
shutdown /r /t 60 /c "Rebooting to complete MS12-063 (KB2744842)"

After the reboot, close and reopen Internet Explorer (and restart any application that hosts the WebBrowser/MSHTML control) so the patched mshtml.dll is loaded from disk rather than served from the old in-memory copy.

If you can't patch immediately

Patching with KB2744842 (or a later cumulative IE update) is the only durable fix. While the change window is scheduled, Microsoft documented these specific interim mitigations in advisory 2757760 for this exact bug. They reduce exploitability but do not remove the use-after-free.

• Deploy EMET. Microsoft's Enhanced Mitigation Experience Toolkit was the recommended stopgap for CVE-2012-4969. Adding iexplore.exe to EMET and enabling the memory-corruption mitigations (DEP, mandatory ASLR, EAF, heap spray protection) broke the public exploit chains for this bug.
• Set Internet and Local intranet zones to High. This makes IE prompt before running ActiveX controls and Active Scripting, blocking the scripted heap grooming the exploit relies on.
• Configure IE to prompt before Active Scripting, or disable it in the Internet and Local intranet security zones.
• Apply the official "Fix it" / MSHTML shim that Microsoft published with advisory 2757760, which blocked the specific vulnerable code path until the binary patch could be deployed.

None of these are substitutes for the update. Treat them as containment for hours-to-days, not weeks.

Verify the fix landed

After applying the update, confirm the patch is registered and that the mshtml.dll file version moved to a build that includes the MS12-063 fix.

# 1) The update is recorded in the patch history
Get-HotFix -Id KB2744842

# 2) The vulnerable binary has been replaced
(Get-Item "$env:WINDIR\System32\mshtml.dll").VersionInfo.FileVersion

# 3) Most recent updates, newest first, to confirm a recent IE cumulative rollup
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID,InstalledOn

Then run an authenticated vulnerability scan with a current signature set and confirm the scanner no longer flags CVE-2012-4969. If the host was used for web browsing while unpatched during the September 2012 exposure window: especially by an administrator, treat it as potentially compromised: review proxy and endpoint logs for that period, look for unexpected processes, scheduled tasks, and outbound connections, and rotate any credentials that were entered or cached on the machine.

Frequently asked questions

Which update fixes CVE-2012-4969?

Microsoft security bulletin MS12-063, delivered as update KB2744842, released out-of-band on 21 September 2012. It patches Internet Explorer 6, 7, 8 and 9. On a currently maintained system, a later cumulative Internet Explorer security update supersedes KB2744842 and also closes this bug. installing the latest IE cumulative update is sufficient.

Is CVE-2012-4969 being exploited in the wild?

Yes. It was a zero-day exploited in targeted attacks in September 2012, a public Metasploit module (windows/browser/ie_execcommand_uaf) exists, and CISA added it to the Known Exploited Vulnerabilities catalog on 2022-06-08. Drive-by exploitation only requires the victim to load a malicious page.

I don't use Internet Explorer as my browser, am I still at risk?

Possibly. The flaw is in mshtml.dll, the shared rendering engine, so any application that hosts the WebBrowser/MSHTML control, HTML email rendered through the IE engine, and HTML Help content can reach the vulnerable code even if you never open iexplore.exe. Apply the update regardless of your default browser.

Can a firewall or WAF fully mitigate this instead of patching?

No. This is a client-side browser bug triggered by content the user fetches, not a listening network service. Network filters can block some known malicious URLs but cannot stop a crafted page delivered from an arbitrary site. Installing KB2744842 (or running as a standard user plus EMET as a stopgap) is the real control.

References

• Official vendor advisory: http://technet.microsoft.com/security/advisory/2757760
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2012-4969
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV record: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2012-4969
• Additional reference: http://www.us-cert.gov/cas/techalerts/TA12-265A.html
• Additional reference: http://www.kb.cert.org/vuls/id/480095
• Additional reference: https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A15729
• Additional reference: http://www.us-cert.gov/cas/techalerts/TA12-262A.html

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Other flaws in this area worth reviewing while you patch this one:

• How to Fix CVE-2012-1854: Security Vulnerability in Visual Basic for Applications (VBA)
• How to Fix CVE-2012-1889: Out-of-bounds Write in Xml Core Services
• How to Fix CVE-2012-1856: Security vulnerability in Microsoft Office
• How to Fix CVE-2012-0151: Improper Input Validation in Windows
• How to Fix CVE-2012-4792: Use-After-Free in Internet Explorer