MS10-090 Microsoft Internet Explorer CSS SetUserClip Memory Corruption

zetlyn/cve-metasploit exploit cve CVE-2010-3962 known 2010-11-03

https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/browser/ms10_090_ie_css_clip.rb

Properties

platformWindows
receipt
Source
Metasploit exploit modules
Its words
Windows
Read by
field:platform
Said since
2026-09-28 11:44 UTC
Last answered
2026-10-05 21:42 UTC
Original
open at the source
What the source handed over
{
  "aliases": [],
  "arch": "",
  "author": [
    "unknown",
    "Yuange",
    "Matteo Memelli",
    "jduck <jduck@metasploit.com>"
  ],
  "autofilter_ports": [],
  "autofilter_services": [],
  "check": false,
  "default_credential": false,
  "description": "This module exploits a memory corruption vulnerability within Microsoft's\n          HTML engine (mshtml). When parsing an HTML page containing a specially\n          crafted CSS tag, memory corruption occurs that can lead arbitrary code\n          execution.\n\n          It seems like Microsoft code inadvertently increments a vtable pointer to\n          point to an unaligned address within the vtable's function pointers. This\n          leads to the program counter being set to the address determined by the\n          address \"[vtable+0x30+1]\". The particular address depends on the exact\n          version of the mshtml library in use.\n\n          Since the address depends on the version of mshtml, some versions may not\n          be exploitable. Specifically, those ending up with a program counter value\n          within another module, in kernel space, or just not able to be reached with\n          various memory spraying techniques.\n\n          Also, since the address is not controllable, it is unlikely to be possible\n          to use ROP to bypass non-executable memory protections.",
  "disclosure_date": "2010-11-03",
  "fullname": "exploit/windows/browser/ms10_090_ie_css_clip",
  "is_install_path": true,
  "mod_time": "2025-06-23 12:43:46 +0000",
  "name": "MS10-090 Microsoft Internet Explorer CSS SetUserClip Memory Corruption",
  "needs_cleanup": null,
  "notes": {
    "Reliability": [
      "unknown-reliability"
    ],
    "SideEffects": [
      "unknown-side-effects"
    ],
    "Stability": [
      "unknown-stability"
    ]
  },
  "path": "/modules/exploits/windows/browser/ms10_090_ie_css_clip.rb",
  "platform": "Windows",
  "post_auth": false,
  "rank": 400,
  "ref_name": "windows/browser/ms10_090_ie_css_clip",
  "references": [
    "CVE-2010-3962",
    "OSVDB-68987",
    "BID-44536",
    "EDB-15421",
    "MSB-MS10-090"
  ],
  "rport": null,
  "session_types": false,
  "targets": [
    "Automatic",
    "Debug",
    "Internet Explorer 6",
    "Internet Explorer 7"
  ],
  "type": "exploit"
}
rank400
Good. A default target, reliable against the common configuration.
receipt
Source
Metasploit exploit modules
Its words
400
Read by
field:rank
Said since
2026-09-28 11:44 UTC
Last answered
2026-10-05 21:42 UTC
Original
open at the source
What the source handed over
{
  "aliases": [],
  "arch": "",
  "author": [
    "unknown",
    "Yuange",
    "Matteo Memelli",
    "jduck <jduck@metasploit.com>"
  ],
  "autofilter_ports": [],
  "autofilter_services": [],
  "check": false,
  "default_credential": false,
  "description": "This module exploits a memory corruption vulnerability within Microsoft's\n          HTML engine (mshtml). When parsing an HTML page containing a specially\n          crafted CSS tag, memory corruption occurs that can lead arbitrary code\n          execution.\n\n          It seems like Microsoft code inadvertently increments a vtable pointer to\n          point to an unaligned address within the vtable's function pointers. This\n          leads to the program counter being set to the address determined by the\n          address \"[vtable+0x30+1]\". The particular address depends on the exact\n          version of the mshtml library in use.\n\n          Since the address depends on the version of mshtml, some versions may not\n          be exploitable. Specifically, those ending up with a program counter value\n          within another module, in kernel space, or just not able to be reached with\n          various memory spraying techniques.\n\n          Also, since the address is not controllable, it is unlikely to be possible\n          to use ROP to bypass non-executable memory protections.",
  "disclosure_date": "2010-11-03",
  "fullname": "exploit/windows/browser/ms10_090_ie_css_clip",
  "is_install_path": true,
  "mod_time": "2025-06-23 12:43:46 +0000",
  "name": "MS10-090 Microsoft Internet Explorer CSS SetUserClip Memory Corruption",
  "needs_cleanup": null,
  "notes": {
    "Reliability": [
      "unknown-reliability"
    ],
    "SideEffects": [
      "unknown-side-effects"
    ],
    "Stability": [
      "unknown-stability"
    ]
  },
  "path": "/modules/exploits/windows/browser/ms10_090_ie_css_clip.rb",
  "platform": "Windows",
  "post_auth": false,
  "rank": 400,
  "ref_name": "windows/browser/ms10_090_ie_css_clip",
  "references": [
    "CVE-2010-3962",
    "OSVDB-68987",
    "BID-44536",
    "EDB-15421",
    "MSB-MS10-090"
  ],
  "rport": null,
  "session_types": false,
  "targets": [
    "Automatic",
    "Debug",
    "Internet Explorer 6",
    "Internet Explorer 7"
  ],
  "type": "exploit"
}

Text

This module exploits a memory corruption vulnerability within Microsoft's HTML engine (mshtml). When parsing an HTML page containing a specially crafted CSS tag, memory corruption occurs that can lead arbitrary code execution. It seems like Microsoft code inadvertently increments a vtable pointer to point to an unaligned address within the vtable's function pointers. This leads to the program counter being set to the address determined by the address "[vtable+0x30+1]". The particular address depends on the exact version of the mshtml library in use. Since the address depends on the version of mshtml, some versions may not be exploitable. Specifically, those ending up with a program counter value within another module, in kernel space, or just not able to be reached with various memory spraying techniques. Also, since the address is not controllable, it is unlikely to be possible to use ROP to bypass non-executable memory protections.