How to Read a CVE by Its Class (and Why the Score Alone Will Mislead You)

A field guide to auth bypass, privilege escalation, and RCE, using two real bugs from this week's Patch Tuesday.

This week's Patch Tuesday shipped over 400 CVEs, including an actively exploited zero-day. If your inbox looks anything like mine, that means a wall of advisories, a spreadsheet of scores, and a manager asking which ones matter before lunch.

Here's the thing nobody really teaches you when you start: the CVSS score is not the answer to that question. It's an input. The faster shortcut is learning to read a vulnerability by its class, because the class tells you what the attacker actually gets.

Let me show you what I mean with three classes you'll see constantly, and two real bugs from this week.

The class tells you what the attacker gets

Strip away the vendor language and almost every vulnerability answers one question: what can the attacker now do that they couldn't before? Three answers come up again and again.

1. Authentication bypass — getting in

An authentication bypass lets someone act as a legitimate user without valid credentials. No password, no token, no account. They walk through the front door as if they belonged there.

This week's example is the SharePoint bug, CVE-2026–55040 (CVSS 9.1). It came down to flaws in the JWT token validation pipeline, and the result was blunt: a remote, unauthenticated attacker could bypass authentication and operate as a site user, up to and including an administrator. The weakness class behind it, CWE-1390, is literally "Weak Authentication."

When you see "authentication bypass," read it as: the login is optional now.

2. Privilege escalation — getting bigger

Privilege escalation assumes the attacker is already inside, but limited. Maybe they landed as a low-privileged user or a service account. Escalation turns that foothold into SYSTEM on Windows or root on Linux.

This week's example is the Windows zero-day, CVE-2026–68820, a use-after-free in afd.sys, the kernel-mode driver behind the Windows Sockets API. The bug abused how the driver handled a socket accessed by multiple threads at once, and it handed an attacker SYSTEM. It wasn't theoretical either. It was being exploited in the wild before the patch landed.

When you see "privilege escalation," read it as: whatever they've got, it's about to become everything.

3. Remote code execution — running code

Remote code execution means running your own code on the target. It's usually the end goal, because once you can execute code, most other things follow: persistence, lateral movement, data theft.

RCE is the class that makes people drop what they're doing, and rightly so. But here's where it gets interesting, because RCE is often not a single bug. It's a destination you reach by combining others.

The part nobody puts on the label: chaining

A single vulnerability is frequently limited on its own. An auth bypass gets you in as a user. A privilege escalation makes you an admin. An RCE lets you run a payload. Individually, any one of them might be something you'd patch on a normal cycle.

Chain them, and the math changes completely.

The SharePoint bug is the textbook case. On its own, CVE-2026–55040 is "just" an authentication bypass. But researchers at Rapid7 showed it could be chained with a second flaw to achieve unauthenticated remote code execution against a vulnerable server. Neither bug owned the box by itself. Together, they did.

This is why a page full of "medium" and "high" ratings can be more dangerous than a lone "critical." Attackers don't respect your severity columns. They look for combinations.

The three questions I run on every CVE

Once you start thinking in classes and chains, triage stops being about the biggest number and starts being about reachability and consequence. These are the three questions I ask before I even look at the score:

1. Can they reach it? An internet-facing service is a different universe from something that requires an authenticated user on an internal VLAN. A critical you can't reach is often less urgent than a medium sitting on your perimeter.

2. What does the class give them? In the door, bigger, or code execution? Map the bug to what it actually grants. That single word reframes the whole advisory.

3. What does it chain with? Look at your other open findings. A bypass sitting next to an RCE on the same asset is a bad morning waiting to happen, even if neither is individually alarming.

Do this, and the CVSS number becomes the last thing you check, not the first.

Where the score falls short

None of this means CVSS is useless. It's a reasonable baseline for severity. But it scores a vulnerability largely in isolation, and it says nothing about whether the bug is being exploited right now or whether it slots neatly into a chain in your environment.

That's why the mature move is to pair it with signals CVSS doesn't carry: CISA's Known Exploited Vulnerabilities catalog for "is anyone actually using this," and EPSS for the probability that a given CVE gets exploited in the near term. Score for severity, KEV and EPSS for reality, and your own asset context for reachability. The class is the lens that ties them together.

The takeaway

The next time a stack of advisories lands, resist the urge to sort by score and start at the top. Read the class first. Ask what each bug gets an attacker, whether they can reach it, and what it pairs with. That's the difference between patching the loudest CVE and patching the one that actually loses you the box.

Sources: Microsoft August 2026 Patch Tuesday coverage (SecurityWeek); Rapid7 technical analysis of CVE-2026–55040; Microsoft advisory for CVE-2026–68820.*