Skip to main content

Microsoft Exploitability Index

Published: October 10, 2008 | Updated: July 11, 2012

The Microsoft Exploitability Index helps customers priority security bulletin deployment by providing information on the likelihood that a vulnerability addressed in a Microsoft security update will be exploited within the first 30 days of the update's release.

Why Microsoft Developed the Exploitability Index

Microsoft developed the Exploitability Index in response to customer requests for additional information to further evaluate risk. Through Microsoft's monthly security bulletin release and webcast, the company provides customers with information about proof-of-concept code, exploit code or active attacks addressed by our security updates, at the time of their release.

How the Exploitability Index Works

Microsoft evaluates the potential exploitability of each vulnerability of severity Important or Critical associated with a Microsoft security update and then publishes the exploitability information as part of the monthly Microsoft security bulletin summary. If Microsoft determines within the first 30 days that the Exploitability Index Assessment warrants a change, it will change the assessment in the bulletin summary and notify customers through technical security notifications. The company will not update the assessment in the bulletin summary when exploit code is posted that matches the existing exploitability information.

This exploitability information includes:

  • The bulletin ID
  • The bulletin title for that bulletin
  • The CVE ID associated with the specific vulnerability
  • The exploitability assessment for code execution on the latest software release
  • The aggregate exploitability assessment for code execution on older software releases
  • A description of the potential for denial of service
  • Key notes

We define the "latest software release" as the most recent version of the application or platform listed in the "Affected Software" and "Non-Affected Software" tables in the security bulletin. For "older software releases," the highest rating pertains to all other supported releases, as listed in the "Affected Software" tables in the security bulletin.

For example, a vulnerability addressed in a security update would have the following Exploitability Assessment in July, 2012:

BulletinVulnerability TitleCVE IDExploitability Assessment for Latest Software ReleaseExploitability Assessment for Older Software ReleaseDenial of Service Exploitability AssessmentKey Notes
MS12-047Keyboard Layout VulnerabilityCVE-2012-18902 - Exploit code would be difficult to build1 - Exploit code likelyTemporaryThis vulnerability has been publicly disclosed.


In those scenarios where multiple product series are affected, for instance a vulnerability that affects both Windows and Office, the "latest software release" rating reflects the highest risk level across both products. In this case, if the Exploitability Assessment on the latest version of Office is "1," and on the latest version of Windows is "2," the rating will reflect "1."

In both cases, the Exploitability Index uses one of three values to communicate to customers the likelihood of functioning exploit code development, based on vulnerabilities addressed by Microsoft security bulletins. As of November 2011, Microsoft changed the wording to simplify and clarify our assessments:

Exploitability Index AssessmentShort Definition
1Exploit code likely *
2Exploit code would be difficult to build **
3Exploit code unlikely ***
* Previously "Consistent exploit code likely"
** Previously "Inconsistent exploit code likely"
*** Previously "Functioning exploit code unlikely"


1 – Exploit code likely

This rating means our analysis has shown that exploit code could be created in such a way that an attacker could consistently exploit that vulnerability. For example, an exploit would be able to cause remote code execution of that attacker's code repeatedly, and in a way that an attacker could consistently expect the same results. This would make it an attractive target for attackers, and therefore more likely that exploit code would be created. As such, customers who have reviewed the security bulletin and determined its applicability within their environment could treat this with a higher priority.

2 – Exploit code would be difficult to build

This rating means that our analysis has shown that exploit code could be created, but an attacker would likely have difficulty creating the code, requiring expertise and sophisticated timing, and/or varied results when targeting the affected product.

For example, an exploit could cause remote code execution, but may only work one out of 10 times, or one out of 100 times, depending on the state of the system being targeted and the quality of the exploit code. While an attacker may increase the consistency of their results by having better understanding and control of the target environment, the unreliable nature of this attack makes it a less attractive target for attackers. As such, customers who reviewed the security bulletin and determined its applicability within their environment should treat this as a material update. If they are prioritizing against other highly exploitable vulnerabilities, they could rank this lower in their deployment priority.

3 – Exploit code unlikely

This rating means that our analysis shows that successfully functioning exploit code is unlikely to be released. This means that it might be possible for exploit code to be released that could trigger the vulnerability and cause abnormal behavior. However, it is unlikely that an attacker would be able to create an exploit that could successfully exercise the full impact of the vulnerability. Given that vulnerabilities of this type would require significant investment by attackers to be useful, the risk of exploit code being creating and used within 30 days of a bulletin release is much lower. Therefore, customers who have reviewed the security bulletin to determine its applicability within their environment could prioritize this update below other vulnerabilities within a release.

The DoS Exploitability Assessment can reflect either of the following:

DoS Exploitability AssessmentShort Definition
TemporaryExploitation of this vulnerability may cause the operating system or application to become temporarily unresponsive, until the attack is halted, or to exit unexpectedly but automatically recover. The target returns to the normal level of functionality shortly after the attack is finished.
PermanentExploitation of this vulnerability may cause the operating system or application to become permanently unresponsive, until it is restarted manually, or to exit unexpectedly without automatically recovering.


If a vulnerability could allow a permanent denial of service, it requires an administrator to start, restart, or reinstall all or parts of the system. It should be noted that any vulnerability that automatically restarts the system is also considered a permanent DoS. Also, client applications that are typically intended for interactive use, such as Microsoft Office releases, would not get a DoS Exploitability Assessment.

Key Notes Section

The Key Notes provided in the table contain additional information on whether there is a significant change in the exploitability prediction for a particular product or operating system, as well as other important information relating to the ability to exploit that specific vulnerability. In the example above, Windows 2000 is at more risk than other operating systems, so customers should take this into account if prioritizing their release by operating system or product version.

Important Terms and Definitions

Exploit Code – A software program or sample code that, when executed against a vulnerable system, uses the vulnerability to spoof attacker identity, tamper with user or system information, repudiate attacker action, disclose user or system information on the server side, deny service to valid users, or elevate privileges for the attacker. For example, if a vulnerability had a security impact of remote code execution, Exploit Code could cause remote code execution to occur when run against a target system.

Trigger a Vulnerability – The ability to reach the vulnerable code, but not always achieving the maximum impact. For example, it may be easy to trigger a remote code execution vulnerability, but the resulting effect may only be a denial of service.

Frequently Asked Questions (FAQ) Related to the Exploitability Index

Q: What is the Microsoft Exploitability Index?

A: The Microsoft Exploitability Index is an index that provides additional information to help customers prioritize their deployment of the monthly security updates. Microsoft designed this index to provide customers guidance concerning the likelihood of functioning exploit, based on each vulnerability addressed by Microsoft security bulletins.

Q: Why did Microsoft create the Exploitability Index?

A: Customers asked for more information to help them prioritize their deployment of Microsoft security updates each month, specifically requesting details about the likelihood of exploit code for the vulnerabilities addressed in security bulletins. Through webcasts and customer calls, Microsoft has always answered this request with a description of known exploit code or attacks at the time of release.  The Exploitability Index goes beyond this by providing details about how exploitable a vulnerability may be, and the likelihood of exploit code being published in the month following a security bulletin's release.

Q: Is this a truly reliable rating system?

A: While predicting activity within the security ecosystem is always difficult, there are three reasons why this system should be reliable.

First, over the last few years we've realized that many security researchers analyze the updates associated with Microsoft's security bulletins the day they are released in order to create and evaluate protections. In doing so, many of these researchers also create exploit code to test them. The methodology used to develop this exploit code is similar to the one Microsoft uses to determine the likelihood of exploit code release.  Microsoft analyzes the updates themselves, the nature of the vulnerability, and the conditions that must be met in order for an exploit to execute successfully.

Second, not all vulnerabilities resolved by our security updates result in released exploit code.  In fact, only 30 percent of vulnerabilities resolved in Microsoft security bulletins in 2006 and 2007 had functioning exploit code released. While there are many social factors that can determine the release of exploit code, the technical differences in some vulnerabilities make exploitation even more challenging.  For example, the combination of address space layout randomization (ASLR) and data execution prevention (DEP) on Windows Vista makes some vulnerabilities more difficult to exploit.  Some vulnerabilities also require systems to have memory in a predictable state in order for exploit code to function successfully. Therefore, careful analysis of each vulnerability, using the methodology mentioned above, can provide reliable insight into the difficulty of creating exploit code that could work consistently.

Finally, we're also partnering with protection providers through the Microsoft Active Protections Program, working with them to help validate our predictions each month – thereby using a community approach as a way to ensure better accuracy through information sharing.

Q: How is the Exploitability Index different from the MSRC Bulletin Severity Rating system?

A: The MSRC Bulletin Severity Rating system assumes that exploitation will be successful. For some vulnerabilities where exploitability is high, this assumption is very likely to be true for a broad set of attackers. For other vulnerabilities where exploitability is low, this assumption may only be true when a dedicated attacker puts a lot of resources into ensuring their attack is successful. Regardless of the Bulletin Severity or Exploitability Index rating, Microsoft always recommends that customers deploy all applicable and available updates; however, this rating information can assist sophisticated customers in prioritizing their approach to each month's release.

Q: How are Denial of Service, Tampering, Information Disclosure or Spoofing issues rated?

A: The Exploitability Index only attempts to rate vulnerabilities that can be leveraged for code execution. Vulnerabilities that could allow denial of service, tampering, information disclosure or spoofing will receive an Exploitability Index rating of "3." The notes for that particular CVE will also reflect the nature of the vulnerability.

Q: What happens if an Exploitability Index rating is incorrect?

A: The ability to rate the possible exploitation of vulnerabilities is an evolving science, and new techniques for exploitation in general, or unique techniques specific to a vulnerability, may be discovered that could change the Exploitability Index rating. However, the goal of the Exploitability Index is to help customers prioritize those updates for the most current monthly release. Therefore, if there is information that would change an assessment released in the first month of a security release, the Microsoft Research Center (MSRC) will update the Exploitability Index. If information becomes available in subsequent months, after most customers have made their prioritization decisions, the Exploitability Index would not be updated as it is no longer useful to the customer. When, within the first thirty days of release, an Exploitability Index rating is corrected in a way that reflects increased risk to customers, the security bulletin summary revision is incremented at a major version number (for instance, from 1.0 to 2.0). When risk is adjusted downwards, the bulletin summary revision is incremented at a minor version number (for instance, from 1.0 to 1.1).

Q: How does the Exploitability Index relate to CVSS and other rating systems?

A: The Exploitability Index is separate and not related to other rating systems.  However, the MSRC is a contributing member to the Common Vulnerability Scoring System (CVSS), and Microsoft shares its experience and customer feedback in building and releasing the Exploitability Index with the working group in order to help ensure CVSS is effective and actionable.

Q. Does this warn against targeted attacks?

A: While the Exploitability Index itself does not warn of how an attacker may target an attack, it can be helpful in providing customers a view into which vulnerabilities could be used more prominently in targeted attacks. For example, in limited targeted attacks, an attacker will most likely choose vulnerabilities with high exploitability in order to reduce the discoverability of the attack. Therefore, customers concerned with targeted attacks may use the Exploitability Index to prioritize those updates and protections for those vulnerabilities in their monthly risk assessments.