SecureBoot is a part of UEFI and other firmwares that can be used to verify signatures on the software that will be loaded at boot. This is usually a bootloader, but it can also be the OS itself.
On some implementations the user can "burn" a custom certificate for the firmware to use for validation. In other cases the certificates are preloaded by the manufacturer and only software signed by them can be used on the device.
Embedded devices like phones and tablets usually fall under the second category, where the user can't change the installed software except where allowed by the manufacturer (i.e., an OS update).
By breaking this lock, users would be allowed to install anything they want. This is usually called "jailbreaking" the device.
The problem with jailbreaking is that it also allows bad actors to compromise the device at a low level, which makes the threats more persistent and difficult to detect.
Different devices have had different methods for jailbreaking accross the years. In this case it was a snafu by Microsoft that allowed it. From the original write up (perhaps NSFW):
[secure boot policy is] a file in a binary format that's embedded
within an ASN.1 blob, that is signed. It's loaded by bootmgr REALLY
early into the windows boot process. It must be signed by a
certificate in db. It gets loaded from a UEFI variable in the
secureboot namespace (therefore, it can only be touched by boot
services). There's a couple .efis signed by MS that can provision such
a policy, that is, set the UEFI variable with its contents being the
This is a very clever and extensible scheme that was broken by an overlook during development:
During the development of Windows 10 v1607 'Redstone', MS added a new
type of secure boot policy. Namely, "supplemental" policies that are
located in the EFIESP partition (rather than in a UEFI variable), and
have their settings merged in, dependant on conditions (namely, that a
certain "activation" policy is also in existance, and has been loaded
[...] The "supplemental" policy contains new elements, for the merging
conditions. These conditions are (well, at one time) unchecked by
bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and
earlier certainly doesn't know about them. To those bootmgrs, it has
just loaded in a perfectly valid, signed policy.
In other words, they have a signed policy that allows them to load unsigned binaries, presumably to allow for testing development versions without having to sign each one.
They accidentally shipped this policy in some devices, someone discovered it and published it, and it can now be loaded on any device.
The write-up goes into a lot more detail about how it works. The point is that this is a jailbreak exploit. For some it's good news, for others not so much.
Successfull exploitation requires admin rights or physical access.
@Bradley mentioned in the comments that "It makes it easier for malware that is already on your pc to take over the boot progress and completely overtake your pc". While true, it means the malware already had admin rights on the device, so the boot compromise is the least of your problems.
Microsoft has stated:
The jailbreak technique described in the researchers’ report on August
10 does not apply to desktop or enterprise PC systems. It requires
physical access and administrator rights to ARM and RT devices and
does not compromise encryption protections.
But that may have been an understatement. They released two patches: MS16-094 and MS16-100. The first one states:
An attacker must have either administrative privileges or physical
access to install a policy and bypass Secure Boot.
This security update is rated Important for all supported editions of
Windows 8.1, Windows RT 8.1, Windows Server 2012, Windows Server 2012
R2, and Windows 10.
The security update addresses the vulnerability by blacklisting
So it's either root or physical access, as mentioned before.
And it does affect desktops and servers (see comments discussion for speculation on why they might have said it didn't).
Also, the policy blacklisting was deemed insufficient: rolling back to an older bootmgr could still allow for the policy to be loaded (this is mentioned in the write up). The second patch also blacklists old boot managers to address that.
TL;DR: Patch your windows systems and don't worry too much about this. There are far worse issues.