I’ve tracked Microsoft’s Windows patches for years and closely watched all of the changes the company has made. I remember when you had to install updates in a certain order — and watch for which one had to be installed first. I remember the arrival of automated patching using Software Update Services (later called Windows Server Update Services). I’ve seen how we went from a system where each vulnerability was patched individually to what we now have: cumulative patching.

The ideal patch is self-contained. Install, reboot, get back to your work. It causes no side effects. It protects the operating system. And you forget about it because it does what it’s supposed to do.

Many in the security industry remember specific security incidents and wax poetically about them. I tend to remember particular patches and their side effects. My favorite was a long ago update that triggered a blue screen of death. This particular update, MS10-015, fixed an elevation-of-privileges issue by making changes to kernel registers. The problem: in some places outside the US, users were running software that bypassed the need for a product licensing key — and it used exactly the same registers to hook into the Windows kernel.

So, when that patch was installed, it immediately triggered a BSOD and the computer could not be recovered. To get to the root cause, Microsoft even went so far as to purchase a laptop from an affected customer. (The story is recounted in this video by Dustin Childs, head of the Microsoft Security Response Center.)

Fast forward to this month’s Patch Tuesday release. It included an update that doesn’t fully protect the operating system until someone deploys registry hives and keys — details that are almost buried in the KB article. To find it, you had to expand the Windows 10 21H2 section to get to a tiny link to an additional Knowledge Base article. Mind you, 21H2 got its final update this month, so while Microsoft often showcases changes that affect both 21H2 and 22H2 in this manner on the same bulletin, it seems odd to bury this information so far down in the update history.

The details about one of Microsoft's June patches requiring digging around in an additional KB article.

The guidance to take additional action is found in the “to learn more” section and it’s not even clear we have to manually add the registry hive. Why wasn’t this just part of the update? (The patch doesn’t even include the registry keys in a disabled setting, users have to add the entire hive on their own.) Then, last Thursday, Microsoft noted that the manual steps might introduce a “potential breaking change” but gave no clue as to what that change might affect or even what to look for.

Microsoft added to the patch confusion with a follow-up note on June 15.

The needed registry key is unique to each version of Windows 10 and 11 as well as Server 2022. Now, there is some good news here. The vulnerability is described this way:

An authenticated user (attacker) could cause an information disclosure vulnerability in Windows Kernel. This vulnerability does not require administrator or other elevated privileges.

The attacker who successfully exploits this vulnerability could view heap memory from a privileged process that is running on the server.

Successful exploitation of this vulnerability requires an attacker to coordinate the attack with another privileged process that is run by another user in the system.

Translated, this would be an attacker going after a high-value target, not consumers or even many businesses. And it would not be a trivial attack to pull off, given that it would need to be a blended attack that takes extra time and effort. That still doesn’t minimize the concerns I have about how badly the communication has been on this particular release — especially the lack of information about what side effects could occur. I manually added the registry hive to a Windows 10 22H2 machine in the office and a Windows 11 22H2 PC at home and I’ve see no direct impact.

So, let’s recap. We have a vulnerability where some users, but not all, need to take additional action. The registry settings must be done manually, while paying close attention to the unique keys needed for each OS. If you’re an IT admin, consider using PowerShell or some other technique to deploy these keys. That said, unless your business is at high risk, I would skip doing this. Until Microsoft provides more information about any side effects, use your time and energy on other projects that will better protect your network, or that will validate other patch implementations.  There are many other security projects you would be better served doing.

The same advice holds true if you’re a small business user, or manage a PC at home: I don’t see any need to add these registry keys now.

Finally, Microsoft needs to do better. Your communication about this release has been abysmal, and communication is about as important to security as patching. You’ve blown this one; it feels like we’ve gone back about 20 years in terms of  security communication. Let’s hope this is not a trend going forward.