● High · CVSS 8.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2015-2425: Out-of-bounds Write in Internet Explorer

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

⚡ At a glance
SeverityCVSS 8.8 - High (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
Actively exploited?Yes, listed in CISA KEV (added 2022-05-25)
AffectedMicrosoft Internet Explorer 11 (all supported Windows hosts before the MS15-065 update)
Fixed inMicrosoft security bulletin MS15-065 (July 2015 cumulative IE security update, install the KB listed for your Windows build)
Type (CWE)CWE-787 Out-of-bounds Write (remote code execution)

Exploitation status

CVE-2015-2425 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Microsoft Internet Explorer Memory Corruption Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: although a public exploit is not directly linked in this CVE’s primary references, its place on the CISA KEV catalog confirms working attack code is in active use in the wild: treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

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

What is CVE-2015-2425?

CVE-2015-2425 is a memory-corruption flaw in Microsoft Internet Explorer 11. Per the MITRE record, IE 11 "allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site," tracked by Microsoft as the "Internet Explorer Memory Corruption Vulnerability." It is a distinct bug from the two IE memory-corruption issues fixed in the same batch, CVE-2015-2383 and CVE-2015-2384.

The CISA vulnrichment data classifies the root cause as CWE-787, an out-of-bounds write. When IE parses the attacker's crafted page, the rendering engine (mshtml.dll) writes past the bounds of an allocated buffer. A carefully shaped page lets the attacker control where that write lands and what it contains, which is what turns a crash into reliable remote code execution. The injected code runs with the privileges of the logged-on user, so a user browsing as a local administrator hands the attacker administrative control of the machine.

This is a client-side, drive-by vulnerability. There is no listening service to firewall off. The trigger is a user pointing IE 11 at a malicious or compromised web page, or one serving a malicious ad. The CVSS vector confirms this: AV:N (reachable over the network) but UI:R (the victim must take an action, namely load the page). That is why the score is 8.8 rather than a 9.8 wormable rating.

Why this CVE matters

Microsoft patched this in MS15-065 on 14 July 2015, but the real urgency is the CISA Known Exploited Vulnerabilities listing added on 25 May 2022, which confirms working exploit code has been used against real targets. IE 11 reached end of support on 15 June 2022 and the desktop application was retired on 15 February 2023, yet IE 11 still ships inside Windows Server, and the IE engine is still reachable through Edge's IE mode and through embedded WebBrowser controls in legacy line-of-business apps. Any host that never received the MS15-065 rollup remains exploitable through every one of those surfaces.

Because the write is fully attacker-influenced and the resulting code runs as the current user, a single unpatched workstation that visits the wrong page is enough for initial access. If that user is a domain or local admin, treat it as a full host compromise. If an internal kiosk, jump box, or server with IE 11 went unpatched between July 2015 and now, assume it could have been reached and review accordingly.

Am I affected? Check your IE 11 patch level

Internet Explorer is a Windows-only component, so there are no Linux package checks here. The fix for CVE-2015-2425 is delivered as a cumulative IE security update under MS15-065. The KB number differs per Windows version (for example KB3065822 was the IE cumulative update in that bulletin), so the most reliable test is whether the MS15-065 rollup, or any later cumulative IE/Windows update that supersedes it. is installed.

# Check the installed Internet Explorer version (run in PowerShell)
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Internet Explorer').svcVersion

# List installed updates and look for the MS15-065 IE cumulative update or anything newer
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID,InstalledOn -First 40

# Direct check for the July 2015 IE cumulative update KB
Get-HotFix -Id KB3065822 -ErrorAction SilentlyContinue

If Get-HotFix shows no MS15-065-era IE update and no later cumulative update has superseded it, the host is vulnerable. On a fully maintained Windows machine, a more recent monthly rollup will already include this fix, the goal is simply to confirm patching did not stall in or before July 2015.

How to fix CVE-2015-2425

The only complete fix is Microsoft's update from MS15-065. It is shipped as the cumulative Internet Explorer security update for July 2015, so installing it patches CVE-2015-2425 along with the other IE issues in that bulletin. On any Windows host that has stayed current, a later monthly cumulative/rollup update has already superseded MS15-065: so for most environments the fix is simply "bring Windows Update fully current." For frozen or air-gapped systems, install the specific KB for your Windows build from the Microsoft Update Catalog.

# Run PowerShell as Administrator.
# Easiest path: let Windows Update pull every pending security update,
# which includes the MS15-065 IE cumulative update (or a newer one that supersedes it).
Install-Module -Name PSWindowsUpdate -Force -SkipPublisherCheck -Confirm:$false
Import-Module PSWindowsUpdate
Get-WindowsUpdate -MicrosoftUpdate
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -AutoReboot

Install the specific KB on a frozen host

# For systems that cannot reach Windows Update, download the matching IE cumulative
# update .msu from the Microsoft Update Catalog (https://www.catalog.update.microsoft.com)
# and install it directly. KB3065822 was the IE cumulative update shipped in MS15-065;
# on a long-unpatched host, prefer the latest cumulative IE update available for that OS.
wusa.exe C:\Patches\IE11-Windows6.1-KB3065822-x64.msu /quiet /norestart
shutdown /r /t 60

# Confirm the update is now present
Get-HotFix -Id KB3065822 -ErrorAction SilentlyContinue

A reboot is required because the IE rendering libraries (mshtml.dll, jscript.dll) are loaded in memory; the new code only takes effect after restart. Close all browser windows before patching.

If you can't patch immediately

Patching via MS15-065 (or a superseding update) is the only durable fix. Because this is a client-side browser bug with no listening service, network ACLs and WAFs do nothing here, since the relevant mitigations all reduce what the IE engine will execute. Microsoft documented several in the bulletin:

# Mitigation: force the Internet zone (zone 3) to prompt before running Active Scripting.
# Export the key first so you can roll back.
reg export "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" "C:\Backup\preFix-CVE-2015-2425-zone3.reg" /y
# 1400 = Active Scripting; value 1 = Prompt, 3 = Disable.
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" -Name "1400" -Value 1 -Type DWord

These mitigations break some legitimate sites and are a stopgap, not a fix. Remove them once MS15-065 (or a newer cumulative update) is installed.

Verify the fix landed

After the update and reboot, confirm the patch is recorded and the IE engine version moved forward.

# Confirm the IE cumulative update (or a superseding update) is installed
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID,InstalledOn -First 10

# Confirm the Internet Explorer build advanced
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Internet Explorer').svcVersion

Then run an authenticated vulnerability scan with a current signature set and confirm the scanner no longer flags CVE-2015-2425. For any host that browsed the web with an unpatched IE 11 during the exposure window, review proxy and endpoint logs for that period, look for unexpected child processes spawned by iexplore.exe, and rotate credentials that were used interactively on the machine.

Frequently asked questions

Which update fixes CVE-2015-2425?

Microsoft security bulletin MS15-065, released on 14 July 2015 as the cumulative Internet Explorer security update (KB3065822 was the IE update in that bulletin; the exact KB depends on your Windows version). Any later cumulative IE or monthly rollup update supersedes it, so a fully patched Windows host already has the fix.

Does CVE-2015-2425 still matter now that Internet Explorer 11 is retired?

Yes, if any host still has the IE 11 engine. Even though the IE 11 desktop app was retired in February 2023, the engine ships in Windows Server, runs behind Edge's IE mode, and loads inside embedded WebBrowser controls in legacy apps. Any of those surfaces on an unpatched machine remains exploitable.

Will a firewall rule or WAF fully mitigate CVE-2015-2425?

No. This is a client-side browser bug triggered when IE 11 renders a crafted web page, so there is no listening service to filter. Network controls do not stop it. Installing MS15-065 (or a superseding update) is the only durable fix; disabling Active Scripting or stopping use of the IE engine are stopgaps.

Should I assume a host was compromised if it browsed the web with unpatched IE 11?

For a CVE that CISA confirms is actively exploited, treat it as possible. The exploit runs code as the logged-on user, so check whether that user held admin rights, review proxy and endpoint logs for the exposure window, look for unexpected child processes of iexplore.exe, and rotate credentials used on the machine.

References


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.

Nearby vulnerabilities you may as well remediate alongside this fix:

People also ask

Which update fixes CVE-2015-2425?

Microsoft security bulletin MS15-065, released 14 July 2015 as the cumulative Internet Explorer security update (KB3065822 in that bulletin; the exact KB depends on your Windows version). Any later cumulative IE or monthly rollup update supersedes it.

Does CVE-2015-2425 still matter now that Internet Explorer 11 is retired?

Yes, if any host still has the IE 11 engine. It ships in Windows Server, runs behind Edge's IE mode, and loads inside embedded WebBrowser controls in legacy apps. Any of those surfaces on an unpatched machine remains exploitable.

Will a firewall rule or WAF fully mitigate CVE-2015-2425?

No. It is a client-side browser bug triggered when IE 11 renders a crafted web page, so there is no listening service to filter. Installing MS15-065 (or a superseding update) is the only durable fix.