Threat intel · 5 MIN READ · BEN NAHORNEY AND MATT JASTRAM · FEB 11, 2026 · TAGS: vulnerability prioritization
TL;DR
- This February’s Patch Tuesday includes 59 CVEs.
- In this batch, there are six actively exploited zero-day vulnerabilities, three of which have been publicly disclosed.
- Additionally, check out our review of The NTLM Long Goodbye: Microsoft’s 2026 Deprecation Timeline.
February may be the shortest month of the year, but that rarely cuts security teams any slack. Between Valentine’s Day, the Super Bowl hangover, and the ongoing push to keep infrastructure secure, there’s no shortage of things competing for your attention. And right on schedule, Microsoft has delivered this month’s Patch Tuesday with several items worthy of your priority list.
Patch Tuesday: February 10, 2026
This month’s release addresses 59 security vulnerabilities, including six zero-days already being exploited in the wild. CISA has added all six to its Known Exploited Vulnerabilities (KEV) catalog. Six is a lot to field, and while we suggest you tackle them all, we’ve narrowed down the starting scope to these three.
- Windows Shell Security Feature Bypass Vulnerability (CVE-2026-21510): This is a serious Windows Shell vulnerability that can bypass several security protections to execute malicious code. Fortunately an attacker cannot trigger this vulnerability automatically, but it can be used in social engineering campaigns, such as phishing.
- MSHTML Framework Security Feature Bypass Vulnerability (CVE-2026-21513): This is another security feature bypass vulnerability, only this time impacting the MSHTML Framework used by Windows applications to render Web content. Attackers could leverage this flaw by convincing a user to open a malicious HTML file or shortcut (.lnk) file delivered through a link, email attachment, or download. Once successful, the process bypasses security prompts and could be used to execute malicious code.
- Windows Remote Desktop Services Elevation of Privilege Vulnerability (CVE-2026-21533): This is an elevation of privilege vulnerability in Windows Remote Desktop Services (RDS). With access to an account with low-level permission, an attacker could use this vulnerability to elevate those privileges to the SYSTEM level, giving the attacker full control over the compromised system.
The NTLM long goodbye: Microsoft’s 2026 deprecation timeline
New Technology LAN Manager (NTLM) is an authentication protocol that was first introduced by Microsoft in 1993, and has continued to be used as a fallback authentication method in Windows environments. The hopeful news is Microsoft has a 2026 plan to disable NTLM by default.
Why NTLM needs to go
NTLM has also been a long-standing security weakness for the past three decades. Despite Microsoft’s significant efforts to supersede the protocol with a Kerberos solution, starting way back with Windows 2000. The NTLM process continues to be a popular target for attackers to leverage legacy apps and local accounts.
NTLM remains a favorite for attackers due to three critical architectural failures: fragile cryptography, the pass-the-hash (PtH) loophole, and a lack of mutual authentication.
For the issue of weak cryptography, NTLM relies on outdated hashing algorithms (MD4, MD5, and 56-bit DES), which are the digital equivalent of a padlock that can be easily picked with a paperclip. A small key space in cryptography refers to a limited set of total possible combinations for a cryptographic key. Small key spaces use a 56-bit DES key, making it trivial to brute-force with modern hardware. In contrast, the modern standards like AES (128-bit to 256-bit) are exponentially more secure. The lack of salting—(the practice of adding unique random data before hashing)—means the same password continues to produce the same hash, allowing attackers to use a pre-computed Rainbow Table, or simply steal the hash and use it directly.
The PtH loophole can occur because NTLM validates the hash itself, rather than requiring a cleartext password. Instead, it creates a massive lateral movement risk. If an attacker extracts an MD4 hash from a local machine or domain controller, they don’t need to crack it, they simply “pass” that hash to a server to impersonate the user’s account.
The total lack of mutual authentication, unlike Kerberos, which requires users to prove their identities using encrypted tickets and session keys, NTLM requires the client to prove its identity to the server. It doesn’t require the server to prove its identity to the client. This “one-way trust” path makes NTLM highly susceptible to an adversary-in-the-middle (AitM) attack, where attackers can intercept or redirect the traffic to an attacker controlled device.
An additional attack vector is NTLM relaying—when an attacker captures an authentication attempt and “relays” it to another service, gaining unauthorized access while the user continues sipping their cup of coffee and they believe they are logging in to a ‘normal’ session.
Modern hardware paired with cracking tools can decrypt NTLMv1 hashes almost instantly. This makes the protocol a “low-hanging fruit” for any threat actor who gains access to NTLM hashes.
While Microsoft has long promoted Kerberos as the preferred authentication protocol, many organizations continue to use the legacy NTLM protocol due to legacy dependencies. These legacy protocols continue to present NTLM risk as attackers continue to leverage this weakness. Here at Expel, we’ve seen multiple MDR incidents attempting to exploit NTLM.
For example, CVE-2023-23397 is a critical privilege escalation vulnerability in Microsoft Outlook that is particularly dangerous because it’s zero-click. Unlike typical phishing attacks, the victim doesn’t need to open a malicious attachment or click a link. This exploit triggers automatically when the Outlook client processes a specially crafted email. Long story short, NTLM network packets are sent to users from a malicious, external IP address in an attempt to steal the users credentials. Oftentimes endpoint detection and response (EDR) tools interrupt the attack, and the bad actors don’t succeed in stealing the NTLM hash. However, attackers could use the NTLM authentication message to leverage the user’s password hash to gain unauthorized access.
Where we go from here
Thankfully, there’s a new hope in reducing the NTLM risks. A Microsoft’s 2026 Windows IT Pro Blog details how Microsoft is implementing an authentication model with a more secure mindset, which will make the relay attack and PtH loopholes that have plagued Windows environments for an IT eternity obsolete. Microsoft’s phased approach plan includes: auditing what you have, leveraging new tools to improve authentication, and then disabling NTLM by default.
Let’s focus on the NTLM replacement tools for a moment. Specifically, the local key distribution center (KDC) and initial authentication Kerberos (IAKerb). Local KDC addresses the ‘local account’ NTLM issue, so the local KDC brings Kerberos authentication to logins. IAKerb allows local accounts and non-domain joined scenarios to leverage Kerberos authentication, even if the user doesn’t have a direct line of sight to a domain controller. These tools are providing alternatives to NTLM so that organizations can remove use of NTLM entirely.
Organizations should prioritize a “disable NTLM” roadmap, shifting toward Kerberos or modern identity providers (claims-based authentication). Where legacy support is required, NTLMv2 should be enforced with SMB signing and extended protection for authentication (EPA) to mitigate the risk of relaying. If you’re not currently auditing assets still using NTLM, you might want to start. Below is a suggested phased execution plan:
Phase 1: Develop visibility (immediate action)
Enable NTLM auditing via GPO. Continuously monitor the NTLM operational logs (Event IDs 8001–8004) on domain controllers to identify legacy applications, service accounts, or hardware (printers/scanners) still relying on NTLMv1 or NTLMv2.
Phase 2: Protocol hardening
Push policies to enforce SMB signing and EPA. This is a critical control to mitigate relay attacks while you work toward your full deprecation plan.
Phase 3: Remediation & disabling
Once legacy dependencies are identified and moved to Kerberos (or added to an acceptable risk exception list), you should set the Network NTLM to be disabled by default. Microsoft has reiterated that during phase three, NTLM will remain present in the OS and can be explicitly re-enabled via policy if it’s still required in your infrastructure.
