The title is a bit clickbaity, but it’s a pretty ridiculous vulnerability.
So it’s definitely a genuine issue, but it’s in my view nowhere near as big a deal as the author or the comments on many other sites covering it are making it out to be. Definitely a long-way off from an all-caps “SEVERE”; I reserve those for unauthenticated RCE and wormable exploits, or similar mass carnage variety flaws (e.g. Heartbleed).
The main issue he points out is you can press Shift + F10 and get a Command Prompt during the install/upgrade process, which has been true dating back to at least 2006 with Windows Vista. So not exactly new, and it’s not a “CRAZY bug”, it’s by design, as it’s frequently incredibly useful. When you’re running in a minimal Windows environment (WinPE), if something goes wrong in the early setup, it’s going to be one of the few and possibly only options available to you to figure out what’s going wrong. It’s effectively the Windows equivalent of swapping to a different tty during a Linux or BSD setup. More importantly, it can be disabled, and this isn’t hard to do for enterprise deployment scenarios using tools like SCCM (System Center Configuration Manager). In fact, for memory the checkbox that enables it in SCCM is marked “Test mode only”. But if you’re in an unmanaged environment, you probably don’t want to have to hack your setup media to be able to access basic troubleshooting tools.
Shift + F10
As for the BitLocker point, this is again not a bug but documented behaviour. The issue is that BitLocker doesn’t just encrypt your system and ask for a password at boot, but verifies the execution chain and boot environment up to the point where it prompts for that password. Upgrading the OS means that many of those binaries that are part of that trust chain are going to change. Disabling BitLocker protectors keeps everything encrypted but with a null key, so the binaries can be updated without requiring a BitLocker recovery, then the protectors can be re-enabled once the upgrade is complete. It definitely should be improved, as it feels like a bit of a kludge, but it’s a tricky problem to solve elegantly, particularly with respect to unattended upgrades. It doesn’t cause me to lose sleep, as the only attack scenario this is useful in again requires physical access to a system during an OS upgrade, and while I’d like this process handled better, it’s pretty low on my threat assessment.
In short, both of these issues could probably do with more awareness, but they’re really only pertinent I think to enterprise scenarios, and the people who know what they’re doing are aware of both of these issues, and mitigate them if it’s worth the effort.