Why the login screen matters more than the count
Eleven of the twelve are the usual mix: stored XSS in blocks, server-side request forgery, privilege escalation on multisite, information disclosure. Reaching most of them takes an account or a particular configuration.
The login screen is different because it is the one page every WordPress install serves to anybody who asks for it. An XSS there is pre-auth by construction, and WordPress's own security repository records that it can be pushed to remote code execution given conditions the attacker does not control: the target has to be socially engineered into interacting with it. That caveat matters, and it also stops mattering the day somebody writes a convincing enough lure.
How far back the fix goes
Fixes were backported to WordPress 4.7, which shipped in 2016. That is a long tail of installs to reach, and it says the affected code has been in place for a while and that WordPress expects a meaningful number of sites to be sitting on old branches with background updates still doing their job.
Automatic updates for minor releases have been on by default for years, which is why most sites take a release like this without anyone noticing. The sites that will not are the ones where somebody turned the mechanism off, and those are rarely the sites with someone watching a security feed.
What to do about it
Confirm the update landed rather than assuming it did
Open the admin on each install you are responsible for and check the version string, or query the REST API root from the front end if you have no login. If a site is not on 7.0.3, find out why before updating it: an install with automatic updates disabled usually has a reason attached, and the reason is often a plugin or a customization that will break. For merchants on a hosted storefront, the WordPress in scope is usually the blog, a landing-page build, or a microsite on a subdomain rather than the store itself.