From https://uefi.org/revocationlistfile and in light of this (which is really a run-of-the-mill DBX security update that shouldn't warrant all the fuss):
The x86 and x64 files were updated January 14, 2025.
Alrighty then, let's take a look at the official link and compare this "latest" x64 DBX version against the one it is supposed to replace (the link for which can be found at https://uefi.org/revocationlistfile/archive):
pete@debian:~$ wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin --2025-01-16 20:32:35-- https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin Resolving uefi.org (uefi.org)... 104.21.48.1, 104.21.112.1, 104.21.64.1, ... Connecting to uefi.org (uefi.org)|104.21.48.1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 21170 (21K) [application/octet-stream] Saving to: ‘x64_DBXUpdate.bin’ x64_DBXUpdate.bin 100%[===============================================================================>] 20.67K --.-KB/s in 0s 2025-01-16 20:32:35 (52.7 MB/s) - ‘x64_DBXUpdate.bin’ saved [21170/21170] pete@debian:~$ wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate_20230509.bin --2025-01-16 20:32:42-- https://uefi.org/sites/default/files/resources/x64_DBXUpdate_20230509.bin Resolving uefi.org (uefi.org)... 104.21.96.1, 104.21.80.1, 104.21.32.1, ... Connecting to uefi.org (uefi.org)|104.21.96.1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 21170 (21K) [application/octet-stream] Saving to: ‘x64_DBXUpdate_20230509.bin’ x64_DBXUpdate_20230509.bin 100%[===============================================================================>] 20.67K --.-KB/s in 0s 2025-01-16 20:32:43 (84.8 MB/s) - ‘x64_DBXUpdate_20230509.bin’ saved [21170/21170] pete@debian:~$ cmp -b x64_DBXUpdate_20230509.bin x64_DBXUpdate.bin pete@debian:~$
Wow, you forgot to update the one thing you were supposed to update (and yes I tested from completely different networks and validated that it isn't a cache issue). Great job taking care of one of the most important Internet security resource, that is being relied on by virtually every single current PC user!
I've said it before and I'll say it again: Microsoft should NOT be left in charge of Secure Boot. They have demonstrated time and time again that they are completely untrustworthy of that role.
PS: Of course I e-mailed security@uefi.org the minute I discovered the issue. And of course, as of now, they still haven't replied to that e-mail or done anything about it.