Which vulnerabilities does 0patch provide micropatches for?

We focus on micropatching vulnerabilities that present highest risk for our users. Our assessment of the risk depends on several factors:

1. Is exploit or proof-of-concept publicly (or inexpensively) available to attackers?
   Often, a proof-of-concept exploit is published on the Internet, where anyone can obtain and weaponize it. Sometimes, an exploit can be purchased from threat analysis companies or extracted from an exploit kit or a leaked offensive toolset. Finally, an official patch can be reverse-engineered to extract sufficient vulnerability details to devise an exploit. All these cases increase the risk of the vulnerability becoming exploited in real attacks.
   Notably, vulnerabilities that are only vaguely described in vendor advisories (such as Microsoft Security Advisories) without any useful details are "useless" for both defenders and attackers - neither can do anything about them, and are therefore also largely irrelevant. That's why you can have dozens of CVE IDs listed as patched in a monthly vendor update but most of these have little practical impact on security without additional information.
2. Is the vulnerability being exploited in the wild?
   If the vulnerability is already being exploited in real attacks, it means that a reliable exploit is feasible and likely to be obtained by additional attackers.
3. Is it a remote code execution or local privilege escalation vulnerability with a realistic attack scenario?
   We assign the highest priority to vulnerabilities that allow a remote attacker to get their code executed on victim's computer, but next on the list are patches for those that allow for local privilege escalation. Denial of service issues may only be eligible if their impact is unusually high, and we typically don't create patches for information disclosure vulnerabilities.
4. Is there no official vendor patch available for this vulnerability (or is such patch expensive)?
   If the original vendor doesn't provide an official patch for the vulnerability or wants to charge users for it, and especially when a proof-of-concept or exploit is publicly available, our micropatch can be the only actual fix users can apply. This obviously applies to end-of-life products for which vendors no longer provide security patches.
5. Do users have functional problems applying official vendor patch, prompting them to delay or forgo its application?
   Sometimes official vendor patch breaks functionalities that are critical for users and business processes, so users decide not to apply it and wait for a corrected one. In the meantime, they remain vulnerable and our micropatch can be the only actual fix.
6. Is the vulnerable product widely used or a niche product?
   In general, the more widely-used the product, the higher cumulative risk it presents for our users. Nevertheless, a niche product (e.g., control systems products, secure communication products) can be used by individuals and organizations that may be targeted by strong dedicated attackers - which we consider to be elevated risk. 
7. Can this vulnerability be micropatched?
   0patch can micropatch vulnerabilities in native code running in Windows user space, but (currently) not code in Windows kernel, scripted code or managed code (e.g., .NET). More details here.