This was always intended. If you don't want Microsoft keys sitting at the root of the trust chain, you can also enroll your own keys (with UEFI access). And Microsoft literally forced vendors to allow this by making it a requirement to be able to call a device Windows-ready or whatever it's called. Yes: MSFT explicitly wanted it to be possible to remove MSFT keys from your device.

There's many things that Microsoft deserves a lot of criticism for, but Secure Boot is not one of those things in my eyes.

What I do is seal the disk encryption key against PCR 7 (among others) so even if it secure boots up, unless it boots with grub verified with a specific key, it won’t be able to decrypt the disk.

This is not a hack. It's working as designed.

Secure Boot’s MOK enrollment lets you enroll arbitrary keys without a BIOS password. By borrowing a Microsoft-signed shim from a package like ubuntu’s shim-signed, you can boot any OS on a corporate machine that has 3rd party certificates installed — which most do.

This allows you to boot a different OS, but will still not allow you to hack the existing one, the PCR registers will be different if you try chain-loading it.

Also, if you store part of the full disk encryption key in the TPM, you are also safe, the TPM will not release it. But there is a risk of the user entering their password (if they have one) in a fake login screen. But the OS will fail booting after that screen, so you need some plausible story to trick the user into not reporting the incident to IT.

If you have a laptop where you can install Ubuntu on it, this attack allows you to install a modified (unsigned) Ubuntu on it. So not much has changed.

"If you can mess around in the BIOS you can just enroll your own keys"

... and if your corporation has locked down the UEFI controls to prevent this, you can't. Forex: corporate Microsoft Surface, locked down with Intune (and Autopilot), you won't be getting far enough to do that.