CVE-2026-62815 QUIC: Is UDP/443 In Your Pentest Scope?

The advisory arrives the way these always do: forwarded by a managed service provider at 8:40am, with a CVSS 9.8 in the summary like a dare. Within an hour the patching schedule is agreed and the Windows team has a list of servers. That part works. Most organisations are good at patching now.

Then somebody asks the quieter question, and it spoils the rest of the week: "Do we actually know which of our services speak QUIC?"

Nobody does. Not because the team is careless, but because the last external penetration test enumerated TCP ports, and QUIC does not live on a TCP port. It lives on UDP/443, next door to the HTTPS listener everyone has been testing for a decade, close enough to share a number and far enough to have never been probed.

That gap is more interesting than either bug in Microsoft's August cycle. Below: what shipped on 11 August, why the lower-scoring vulnerability should ruin your week, why UDP/443 is a systematic blind spot rather than one vendor's oversight, how to check your exposure this week, and the scope language that closes the gap. We will also be blunt about our own coverage, because CyberOrbit's scanner does not probe UDP/443 either.

What Microsoft Actually Shipped on 11 August

The August 2026 release carried two items that matter disproportionately to Windows server estates. They are very different bugs, and most of the coverage has conflated them.

CVE-2026-62815 is a use-after-free in Microsoft QUIC, shipped as MsQuic, rated CVSS 9.8 and reachable by a crafted packet with no authentication. Microsoft lists Windows 11 and Windows Server 2022 and 2025 as affected, Server Core included, which matters because Server Core is the build people assume is minimal enough to be safe. MsQuic is not an obscure add-on: it is the transport beneath HTTP/3 in the Microsoft stack, used by IIS, .NET networking, SMB over QUIC, and a range of Azure-fronted services.

At time of publishing, Microsoft's Security Response Center reports no confirmed in-the-wild exploitation of CVE-2026-62815. That is not a reason to defer the patch, but be precise when you brief your board: the second CVE is a different situation.

CVE-2026-68820 is a use-after-free in AFD.sys, the Ancillary Function Driver for WinSock, the kernel driver beneath the Windows sockets API. A race condition in concurrent socket-state handling gives local privilege escalation to SYSTEM. Its CVSS base score is 7.0, which reads as unremarkable in a spreadsheet.

It is not unremarkable. The detail the score cannot carry is the timeline: exploitation began in early July, and the patch arrived on 11 August. That is a confirmed, attributed, nation-state intrusion chain running roughly five weeks before a fix existed.

Check both yourself rather than take our summary on faith. Our free CVE lookup tool pulls the published record for each; the primary sources are the MSRC update guide, the CISA KEV catalog and Check Point Research.

Side by side, the two bugs sort very differently depending on whether you read the score or the exploitation status:

The dates matter as much as the scores, because they show how long the confirmed exploitation ran unpatched:

Why the CVSS 7.0 is the more urgent of the two

Most patch prioritisation is a sort on the severity column. Do that here and you get the wrong answer.

The 9.8 is theoretical today. A use-after-free in a network-facing parser is exactly the class of bug that eventually produces reliable remote code execution, and QUIC's encrypted transport makes exploitation harder to detect once it exists. But "eventually" is doing real work there: no confirmed exploitation, no widely circulating proof of concept at time of writing.

The 7.0 is being used right now, by an actor with a decade of persistence, against organisations that look like the ones reading this. It scores lower because the CVSS base score measures the wrong thing for prioritisation: it treats the local attack vector and the race condition's complexity as mitigating, and it says nothing about whether a working exploit exists. CVSS does have metrics for that, temporal in v3.1, threat in v4.0, but almost nobody publishes them, so the number that reaches your spreadsheet is the base score alone. Local privilege escalation is what an attacker reaches for after initial access, so a base score files it second-tier. Real intrusions do not respect that ordering. They chain.

So patch CVE-2026-68820 first and CVE-2026-62815 in the same window if you can. Exploitation status beats base score for sequencing; KEV exists precisely because CVSS is a severity measure, not a priority measure.

Sequencing is the easy part, though, and your team will finish it by Friday. The harder question is whether you can find the QUIC surface you just patched.

QUIC Doesn't Live on the Port You Scanned

Your HTTPS surface, the one every external test has enumerated since forever, is TCP/443. QUIC runs over UDP. HTTP/3 runs over QUIC. So an HTTP/3 endpoint is UDP/443: identical port number, different transport, different scan.

A TCP SYN scan will never see it. Not "might miss it under load", never. An nmap -p443 result showing a clean, patched, well-configured TLS listener tells you nothing about whether the same IP answers a QUIC Initial packet on UDP/443. Which produces the uncomfortable case at the centre of this article: a host can be fully patched and cleanly reported on its TCP listener while exposing a vulnerable QUIC stack to the internet, and every artefact in your evidence folder will say it is fine. The evidence is not wrong. It is answering a question nobody realised was narrower than it looked.

The scale is not trivial, and you should not take a vendor's number for it, including ours. The Shadowserver Foundation runs an internet-wide UDP/443 scan every 24 hours and publishes the results as its free Accessible QUIC report, recording which hosts answer a QUIC handshake and which protocol versions they offer. Read the current population there rather than a figure quoted in an article: it moves daily, and it counts hosts speaking the transport, not hosts confirmed vulnerable. What it establishes is that QUIC adoption stopped being niche some time ago, and most organisations serving it never explicitly decided to enable it.

Why standard tooling misses it

It would be convenient to blame testers. The honest explanation is protocol design and economics, in that order.

UDP scanning is genuinely hard. TCP gives you a handshake: send a SYN, get a SYN/ACK or a RST, and you know. UDP gives you silence, because an open port that ignores your packet and a filtered port return the same nothing. The only reliable negative signal is an ICMP port-unreachable message, which firewalls routinely suppress and operating systems rate-limit. Credible UDP scanning is therefore far slower than TCP scanning, and lossy on top.

QUIC compounds this, and it is worth being precise about why, because the usual shorthand is wrong. As practitioners writing for the SANS Internet Storm Center have documented in Scanning and abusing the QUIC protocol, nmap cannot reliably fingerprint QUIC services with standard probes. The reason is not that "QUIC is encrypted so you can't read the reply", QUIC Initial packets are cryptographically protected with keys derived from the connection ID using a salt published in RFC 9001, so any observer can unprotect them. The obstacle is on the way out, not the way back: a server will not answer at all unless you send a well-formed Initial packet, supported version, valid connection IDs, and a TLS ClientHello carried in a CRYPTO frame, with header protection applied. A generic UDP payload is not that, so it draws silence, which is indistinguishable from a closed port. Version-negotiation behaviour then varies between implementations on top. You need a prober that speaks QUIC, which is why Quicmap exists.

Now put that inside a time-boxed commercial engagement. A full UDP sweep of a /24 can consume the entire budget and return mostly noise, so it gets cut, and what survives is a top-N UDP list built for a threat model from 2015: DNS, SNMP, NTP, syslog, maybe TFTP. UDP/443 is not on it, because when those lists were written nothing served web traffic over UDP. That is not incompetence. It is a scoping heuristic that was correct for years and quietly stopped being correct while nobody reviewed it. Which brings us to the part we would rather not write.

The Scope Gap Most External Tests Have, Including Ours

CyberOrbit's scanner probes port 443 as TCP only. We never probe UDP/443. If you declare a host that serves HTTP/3 and we scope and run an assessment against it, we will test the TCP listener thoroughly, we will not touch the QUIC one, and nothing in the report will tell you a whole transport went unexamined. Our Nuclei integration accepts http: and https: schemes only: no QUIC handling, no HTTP/3 handling, no template in our set that speaks QUIC.

Our free SSL/TLS Checker opens a TLS socket over TCP. It grades your certificate, protocol versions, cipher suites and chain accurately, and it tells you precisely nothing about whether the same hostname answers on UDP/443. A host can score an A on that tool and run a vulnerable MsQuic build one transport over.

We do scan UDP: ports 53, 161, 162 and 514 are in our probe set today. So this is a scope decision, not a capability limit. It is tracked, and it is not shipped at time of writing.

We state our own gap in the first person because it is checkable: commission an assessment, read the report we deliver, find no QUIC finding and no UDP/443 probe in the evidence. For the market-wide version we defer to practitioner sources. The SANS ISC work on scanning QUIC, and the tooling gap that motivated Quicmap, make the same point from the offensive side: UDP/443 coverage is the exception in external assessment work, not the rule.

Weigh it honestly. There is a defensible case for leaving UDP/443 out of a time-boxed engagement, and there is a real price for doing so:

This is what our own scope claim actually means. We test the TCP-reachable external surface thoroughly and with captured evidence, and we name the transports we do not reach rather than letting the report imply we reached them. We are deliberately not putting a percentage on that, because nobody can honestly compute one: coverage of "your attack surface" depends on a denominator no vendor knows. A vendor who cannot name the edge of their own coverage is not offering you more coverage. They are offering you less information about it.

Take the discipline, not the disclosure. Ask your vendor what you should ask us: which transports did you probe, and on which ports?

How To Check Your Own QUIC Exposure This Week

Six steps, vendor-neutral, no signup, one afternoon for a competent infrastructure engineer.

Do those six things and you will know more about your QUIC surface than most organisations of any size. What you still will not know is whether the patch took.

Post-Patch Validation Is Where an External Test Still Earns Its Keep

Patching is claimed, not proven, and the gap between "patched" and "verified patched" is where most residual risk lives. Change tickets close on "deployed", not on "confirmed from outside the network, against the live listener, at the current build". The host that missed the reboot, the instance spun from a stale image two days after the window, the Server Core box nobody remembered is internet-facing: none appear in a deployment report, all appear in an external scan.

There is a second reason to validate from outside, and it is the one your auditor cares about. A deployment report written by the team that ran the deployment is self-assessment, and self-assessment is the weakest evidence in the folder. Be precise about what the frameworks actually say here, because the sloppy version of this claim is everywhere: PCI DSS is the one that explicitly requires penetration testing, Requirement 11.4 mandates it, performed by a qualified tester who is organisationally independent of the tested environment. SOC 2 and ISO 27001 do not mandate a penetration test by name. SOC 2's Trust Services Criteria require monitoring and vulnerability management; ISO 27001:2022 Annex A.8.8 requires technical vulnerability management. Auditors very commonly accept an independent test as the evidence for those controls, and many customer questionnaires demand one outright, but that is auditor and customer practice, not a clause in the standard. Anyone who tells you SOC 2 requires a pentest has not read it.

Be equally clear about which surface we can validate. The Windows TCP surface is squarely in CyberOrbit's scope: exposed RDP, SMB, NetBIOS and MSRPC, IIS version banners and HTTP response configuration, management interfaces that should never have been reachable, service banners that disagree with the patch level your CMDB claims. That is TCP, we probe it, and we capture the actual request and response as proof. The QUIC surface is not.

The AFD.sys bug sharpens the point. It is a local privilege escalation, so to use it Lazarus first needed a foothold, which in Operation Dream Job has historically come through social engineering and malicious document delivery rather than a network exploit. So the question that most changes your exposure to a confirmed, actively exploited kernel bug is not only "is AFD.sys patched". It is "how many ways can an attacker get initial access at all?" That is what an external test answers.

The QUIC bug is therefore a scope question for next quarter. The AFD.sys bug is an access question for this week, and our analysis of the 48-hour exploit window facing mid-market organisations covers how fast disclosure turns into scanning traffic.

The Scope Language That Closes the Gap

Scope statements fail quietly. They rarely say the wrong thing; they say nothing at all about the surface in question, and everyone reads the silence in whatever way suits them. Language you can paste into an RFP:

Declare transports explicitly. "External testing covers TCP and UDP services on in-scope IP ranges, including UDP/443 (QUIC and HTTP/3). Where UDP coverage is limited to a subset of ports, that subset is enumerated in the report." The second sentence is the important one: it converts an unstated limitation into a stated one.

Name the edge tier. "Scope includes CDN and edge-tier configuration for in-scope hostnames, including HTTP/3 enablement state, origin exposure, and header policy at the edge." Most organisations have outsourced a chunk of their attack surface to a CDN and never brought it back into a test scope.

Enumerate protocols instead of gesturing at "the perimeter". A scope listing HTTPS/TLS over TCP, HTTP/3 over QUIC, SSH, RDP, SMB, DNS, SMTP and VPN endpoints can be checked against the report line by line by someone who was not on the scoping call. "The external perimeter" cannot. We made the same argument about management planes in the Fortinet auth bypass and perimeter scope, and about model-serving infrastructure in the MLflow KEV analysis.

Tie retesting to significant change, not the calendar. "Validation testing will be performed following any significant change, including emergency patch cycles affecting internet-facing hosts." PCI DSS Requirement 11.4.3 already requires external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, with 11.4.4 requiring retest of corrected findings, so PCI entities have leverage that costs nothing to use. One caveat before you quote it at a QSA: PCI DSS leaves "significant change" for the entity to define in its own change-management policy. Define emergency patch cycles on internet-facing hosts as significant there, and the requirement does the rest. Skip that step and a vendor can reasonably argue the trigger never fired.

And accept "out of scope" as an answer, in writing. If a vendor says QUIC and UDP/443 are outside what they cover, that is defensible, and our own answer today is the same. What is not defensible is the surface being absent without ever being declared out of scope, because then the report reads as coverage when it was a choice nobody recorded.

Five clauses, in checklist form, for your next scoping call:

What To Do This Week, Whether Or Not You Buy Anything

Reorder your patch queue by exploitation status. CVE-2026-68820 first: CVSS 7.0, confirmed exploited, KEV-listed, attributed to Lazarus since early July 2026. CVE-2026-62815 second: CVSS 9.8, no confirmed exploitation at time of publishing, but network-reachable and unauthenticated.

Verify against build numbers. Compare MSRC's affected-build lists to what your Windows 11 and Server 2022/2025 hosts actually report, Server Core included.

Open your last penetration test report and search it for the word "UDP". Highest-value action in this article, ninety seconds. If UDP is tested with an enumerated port list, check whether 443 is on it. If UDP is explicitly excluded, you have a recorded risk decision and are in better shape than most. If the word does not appear at all, you have found the gap, and you know what to raise on the next scoping call.

Run the six-step QUIC inventory above, and add UDP/443 to next quarter's scope statement using the clauses above. If your vendor cannot cover it, get the exclusion in writing and record it as an accepted risk with a review date.

The QUIC advisory will fade from the news cycle in about ten days, the way they all do. The scope gap it exposed will still be there next quarter, and the quarter after that, until somebody writes UDP into a document. That somebody is usually whoever read the article.

Frequently Asked Questions