All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
OVH uefi boot - freakin' friday f*ck w/ CVE-2026-97631?
So as we had no (new) 0day kernel vuln this friday I used the day to remember that sth. else was swimming below the surface: CVE-2026-97631 since Oct. 2026.
This is only relevant for systems with a boot order of first testing PXEboot via UEFI - hello OVH, this is your stock settings on dedicated servers, so the question is: how save and isolated is the PXE network at OVH?
So far I have not seen any firmware updates e.g. by AMI for this for quite some Supermicro boards used at OVH.
So:
a) how do you mitigate this atm? Should we never reboot those to not open the attack vector, huh?
b) unrelated but also freaking sh*t: how do you handle efivars partition filling up by firmware? This seems to happen at those OVH servers as well - I now have one at 100% filled up for 512K efivars partition at OVH and others filling up fast as well....
regarding a) some readings:
https://status.hetzner.com/incident/54493dac-b3a2-44f0-8d8b-6de8b25d8f17
https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m
Comments
Too much effort
I wiuld power it off
Just never power it on again
So you have to reboot to apply all those kernel fixes, but then you are not allowed to reboot because of CVE-2026-97631 - I think i call it a day and start the weekend...
just change the boot order ?
bios setup is accessible before default pxe boot
Just checked on 2 KS-LE-B
and my configuration is correct
Old servers will never receive any patch.
So you have to rely on ovh to filter the network correctly
Critical flaws everywhere, I consider all my data public at this point.
Yeah, ahem, I just have zero trust in them in this regard.
But blocking ICMP via their edge network firewall could help somewhat (as own sw firewall rules on server won't help) but this would not help for OVH internal traffic nor ipv6.
So changing boot order would be the best bet atm.
But this would also mean changing it manually each time you want to use rescue mode...
Man, I hate having to use rescue mode every day
Yes, rescue mode is last resort and normally not used but i just hate the idea that is not instantly usable once needed... but server security in 2026 is crutches everywhere, fun long gone.
and the bigger prob is actually b) right now if every reboot adds 11KB of unknown garbage data in the efivars partition until that one is filled up and starts to go on strike.
I use OLA on 95%+ my dedis anyway, so rescue mode isn't a thing for me any way.
If there is an IPMI, I prefer to use that and if not, there are plenty of ways you can get around using a rescue mode by your provider.
https://github.com/minlearn/inst & https://github.com/codebyjawad/restage (vibe coded, but you get the point, if you need it, you could vibe it yourself ^^)
At this point? It is public for years. Doesn't mean the vulnerabilities weren't there, just the CVEs weren't :P
Not worried the slightest, it's hard to pull of.
About the same chance as me having an affair with Huang
any good ideas about efivars cleanup if the firmware garbage collector seems to be broken as well? Or would just a BIOS default reset be the only help there?