Given this:
Shouldn’t there be mention of it in the BIOS release notes, such as this:
Or is it there, and I just don’t know what I’m reading to link the two things together?
Given this:
Shouldn’t there be mention of it in the BIOS release notes, such as this:
Or is it there, and I just don’t know what I’m reading to link the two things together?
Thanks for the heads-up. A fascinating and well-presented read.
I’m sorry I can’t offer an answer to your final question (but I’m keen to learn what the answer is).
The security fixes are listed under Security Fixes on the respective download pages.
Researchers that don’t quote CVE numbers are frustrating to follow. It seems the “BombShell” thing by Eclypsium is the same as UEFI Secure Boot bypass which is NVD - CVE-2025-3052 and that is not mentioned in the BIOS release notes.
Exactly…and I don’t see this mentioned in the Security Fixes section explicitly.
…unless the ‘boomshell’ is the CVE-2025-4275.
…which goes to Tommi’s point on missing CVE from the researcher’s article, and / or CVE-2025-3052 is not mentioned in the BIOS release note.
Again, it could be me not seeing / realising / linking two things together.
“CVE-2025-3052” only has two mentions in the forum (base on forum search).
It is CVE-2025-3052 as far as I understand it, yes.
…and so CVE-2025-3052 has not been addressed in any recent BIOS updates?
This is not CVE-2025-3052. If you follow the link from the the NVD vulnerability page linked by @tommi_virtanen above to the vulnerability report at cert.org, it says the following:
UEFI firmware applications
DTBiosandBiosFlashShellfrom DTResearch contain a vulnerability that allows Secure Boot to be bypassed using a specially crafted NVRAM variable.
cert.org
Neither DTBios nor BiosFlashShell are the UEFI shell implicated in Eclipsium’s article.
It goes on to say,
The vulnerability stems from improper handling of a runtime NVRAM variable that enables an arbitrary write primitive
ibid.
The mm command documented in Eclipsium’s report is not “improper handling of a runtime NVRAM variable.”
It is possible a CVE has not yet been issued for this vulnerability. Perhaps no CNA has been involved.
The release notes you are assessing as being insufficiently transparent or accurate state:
Added Framework’s dbx key
3.24 release thread
This tracks with Eclipsium’s table indicating that a DBX update was targeted for release in 1.24.
QED
Great, I was gathering as much when I was searching for “DBX” in the release note…which brought me to the “not sufficiently” section of the thread’s title. (see below)
Given this:
There’s only mention of “Added Framework’s dbx key”, and no mention of wording to the effect of “blacklist” or revocation of key(s)? Also, no details on the effect / intent of the “added” DBX key, and also no mention of a vulnerability / security posture improvement of the added DBX key. Plus, if it’s to address a security concern (with or without CVE assigned), then the release note should have mention of this specifically under the “Security Fixes” section.
(I intentionally left the first post ‘open’…in order to arrive to this point of the discussion because I wasn’t sure if that addition of DBX key is related to this issue. Thanks for the confirmation)
I was getting the feeling from the few articles I read today that this is certainly not Framework specific and relates to other vendor machines. Though the inclusion of Framework and riding the whole XX # of Linux laptops did give the story the extra traction some of the news outlets were hoping for.
Clearly the function being referred to is commonly reserved for engineering and platforms that are much more open (like Framework) than the majority of walled off systems, that guard any of these tools, is going to be the brunt of this “vulnerability”.
Just looking at the table quoted says that it is being addressed which may be more difficult to pin down with other manufacturers. It does go to show that while secure boot has made some improvements in security, there are still aspects of it that are not as mature as people are led to believe.
It has (see the Security notes on the respective download page).
But alas I seem to have been wrong anyway (see @DHowett answer).
You have a link to it?
(i.e. I don’t see mention of CVE-2025-3052 anywhere… I’m not looking in the right places?)
Summary (So far):
Sorry, I was talking about CVE-2025-4275.
…and thatCVE-2025-4275seems to be different from the ‘bombshell’ matter, right?
We have already released BIOS updates for all affected products to implement the fix. The table below shows the specific BIOS version where the Framework dbx key was introduced. Please ensure your system is updated to the latest version.
| Products | Initial BIOS Version that contains limited shell | BIOS version that contains Framework dbx key |
|---|---|---|
| Framework13 11th Gen Intel® Core™ | 3.24 | 3.24 |
| Framework13 12th Gen Intel® Core™ | 3.18 | 3.19 |
| Framework13 13th Gen Intel® Core™ | 3.08 | 3.09 |
| Framework13 Intel® Core™ Ultra Series 1 | 3.06 | 3.06 |
| Framework13 AMD Ryzen™ 7040 Series | 3.16 | 3.16 |
| Framework13 AMD Ryzen™ AI 300 Series | 3.04 | 3.05 |
| Framework16 AMD Ryzen™ 7040 Series (Laptop 16) | 3.07 | 3.07 |
| Framework Desktop AMD Ryzen™ AI 300 MAX Series | 3.01 | 3.03 |
| Framework 12 13th Gen Intel® Core™ | 3.06 | 3.06 |