Microsoft Just Patched 77 Vulnerabilities — The SQL Server One Should Have You Running to Your Keyboard

Microsoft just dropped 77 security patches in its March 2026 Patch Tuesday release, and while there are no active zero-days this time around (February gave us five, which was fun), a couple of these vulnerabilities deserve your undivided attention right now.

I know. Patch Tuesday. Again. The security community’s version of laundry day — you know it is coming, you know you have to deal with it, and you know ignoring it is going to cause problems eventually. But this month’s batch has a few items that made me sit up straight, and I have been doing this long enough that it takes a lot to get me to sit up straight.

The SQL Server Vulnerability Everyone Should Be Panicking About

Let me start with CVE-2026-21262, because this one is genuinely nasty.

This is an elevation of privilege vulnerability in SQL Server 2016 and later editions. An attacker who already has low-level access to your SQL Server can exploit this bug to elevate themselves to sysadmin. Over the network. Without physical access.

Let that sink in for a second. Sysadmin privileges over the network from a low-privilege account.

Rapid7’s Adam Barnett called it out specifically: “This isn’t just any elevation of privilege vulnerability. The advisory notes that an authorized attacker can elevate privileges to sysadmin over a network. The CVSS v3 base score of 8.8 is just below the threshold for critical severity, since low-level privileges are required. It would be a courageous defender who shrugged and deferred the patches for this one.”

I have a friend — let’s call him Victor because that’s his name and he will never read this — who runs SQL Server for a mid-size retail company. I sent him the advisory at 7 PM last night. By 7:15, he had scheduled emergency maintenance. By 7:30, he texted me: “I hate that you know about these things before I do.” By 8 PM, he was patching. That is the correct response time for this one.

Why SQL Server EoP Is Particularly Dangerous

Most organizations treat their SQL Servers as the crown jewels. Customer data, financial records, PII, transaction histories — it all lives in SQL Server. A sysadmin on that box is not just a database admin. They can:

• Read, modify, or delete any data in any database on the instance
• Execute operating system commands via xp_cmdshell (if enabled — and it is more often than you think)
• Create new accounts, backdoors, or persistence mechanisms
• Access linked servers, potentially pivoting to other database instances across the network
• Dump credentials stored in the database

One compromised low-privilege account. One unpatched SQL Server. Complete database takeover. That is the math.

The Other One: CVE-2026-26127

The second publicly disclosed vulnerability this month is CVE-2026-26127. Details on this one are still emerging, but “publicly disclosed” in Patch Tuesday language means someone other than Microsoft knew about it before the patch dropped. That is never ideal, because it means potential attackers had a head start.

Any time Microsoft labels something as “publicly disclosed,” my rule of thumb is: patch within 48 hours, not the usual monthly cycle. The window between public disclosure and weaponization keeps shrinking. In 2024, it averaged about 15 days. In early 2026, we have seen it drop to single digits for high-value vulnerabilities.

The Bigger Picture: 77 Patches Is Not a Small Number

Seventy-seven. That is 77 things Microsoft found wrong enough to fix in a single month. And this is actually considered a moderate Patch Tuesday. February had more. January was worse. We are averaging about 80 vulnerabilities per month in 2026, which is up from about 70 per month in 2024.

Naomi, who manages patch deployment for a healthcare system with 12,000 endpoints, told me something last week that stuck with me: “We spend more time evaluating patches than we spend deploying them. For every hour of actual patching, there are three hours of figuring out what to patch first, what might break, and who needs to be warned about downtime.”

That ratio — three hours of assessment for every hour of deployment — is pretty standard across the organizations I work with. And it is getting worse as the patch volume increases.

My Triage Framework: What to Patch First

Here is the framework I actually use, refined over about 12 years of doing this (and getting it wrong plenty of times in the early days):

Tier 1: Patch This Week (by Friday)

• Any vulnerability that is publicly disclosed (CVE-2026-21262 and CVE-2026-26127 this month)
• Any vulnerability with a CVSS score above 8.0
• Any vulnerability in internet-facing services (IIS, Exchange, RDP)
• Any vulnerability in authentication or privilege escalation categories

Tier 2: Patch Within Two Weeks

• CVSS 6.0-8.0 vulnerabilities
• Client-side vulnerabilities (Office, Edge, etc.) that require user interaction
• Vulnerabilities in services you actually run (check before assuming you need every patch)

Tier 3: Patch Within the Monthly Cycle

• Everything else
• Low-severity issues
• Vulnerabilities in features you have disabled or do not use

The key insight most people miss: you do not need to patch everything at the same speed. Treating all 77 patches with equal urgency means you either rush through the critical ones or delay them while dealing with minor ones. Neither is good.

The “Zero Zero-Days” Trap

I can already hear some IT managers saying: “No zero-days this month? Great, we can take it easy.”

Please do not do this.

“No zero-days” means no vulnerabilities were being actively exploited before the patch was released. It does not mean these vulnerabilities are not dangerous. It does not mean attackers are not already reverse-engineering the patches to build exploits. It does not mean you have months to get around to it.

The clock starts ticking the moment patches are released, because attackers can diff the before-and-after to find exactly what was fixed and build exploits targeting unpatched systems. This process — called “patch diffing” — can produce working exploits within days.

Last November, my friend Rachel’s company got breached through a vulnerability that was patched three weeks prior. “We were going to get to it in the next maintenance window,” she told me, and I could hear the frustration in her voice. Their next maintenance window was scheduled for two weeks after the breach. Three weeks of exposure was all the attackers needed.

Practical Steps for This Month

Alright, enough doom and gloom. Here is what you should actually do this week:

Step 1: Inventory Your SQL Servers (Today)

I am serious. Today. CVE-2026-21262 affects SQL Server 2016 and later. Do you know every SQL Server instance in your environment? The sanctioned ones AND the ones someone in marketing set up on their desktop three years ago for “just a quick project”?

Step 2: Test and Deploy Critical Patches (By Thursday)

Test in a non-production environment first if you can. If you cannot, patch production anyway but have your rollback plan ready. An unpatched SQL Server with a known sysadmin exploit path is more dangerous than a briefly unstable one during patching.

Step 3: Review Your Patch Cadence

If your “patch cadence” is “whenever we get around to it,” this is your sign to fix that. Monthly minimum. Weekly for internet-facing systems. Immediately for publicly disclosed critical vulnerabilities.

Step 4: Do Not Forget the Stuff That Is Not Windows

While everyone focuses on Microsoft, remember that your FortiGate firewalls, your Cisco gear, your Linux servers, and your SaaS tools all need patching too. I wrote about FortiGate exploits literally yesterday. The attackers do not care what vendor made the vulnerable software.

The Real Talk

Look, I have been writing about Patch Tuesday for longer than I care to admit, and the message has not changed: patch your stuff, prioritize by risk, and do not wait for the perfect maintenance window because there is no such thing.

This month’s SQL Server vulnerability is a genuine “drop what you are doing” issue for any organization running SQL Server. Everything else can follow your normal cadence, but CVE-2026-21262 should be on your short list for this week.

And if you are still running SQL Server 2016 in production in 2026... we should probably have a different conversation entirely. But that is a topic for another day.

(For the record, Victor texted me again this morning. “Patched. Nothing broke. You owe me a coffee for the stress.” Fair enough, Victor. Fair enough.)