Unfortunately, the report I received was out of my hand. Isn't from any of my customers/colleagues, don't have access to the environment, and also don't know how they got in. Just telling that I saw a 8.4.0 getting owned.
Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth
- Thread starter pve7bug
- Start date
Could be a coincidence, or related to the fact that we have a sh**tload of occurrences in Brasil because of outdated version and bad sysadmins on small providers, that rely exclusively on next next finish installations and the mindset of using Mikrotik gives them the behavior that updates are not nice, as Mikrotik usually do not handle very well updates.
Anyhow our Portuguese telegram channel got bombarded today of victims, but so far it's really hard to pin down the vector, as the users in majority don't have a clear idea of their own infrastructure.
Will get back if any new discovery appears.
Anyhow our Portuguese telegram channel got bombarded today of victims, but so far it's really hard to pin down the vector, as the users in majority don't have a clear idea of their own infrastructure.
Will get back if any new discovery appears.
Last edited:
Has anyone reported an attack where they were running only PVE 8.2 or later?
I am wondering if 8.2 and 8.4 actually have no vulnerabilities at all, and what's really happening is that users have vulnerable servers running 8.0.4 or earlier, which get compromised first, and then the attackers move laterally to hit the 8.2+ servers.
I am wondering if 8.2 and 8.4 actually have no vulnerabilities at all, and what's really happening is that users have vulnerable servers running 8.0.4 or earlier, which get compromised first, and then the attackers move laterally to hit the 8.2+ servers.
regardless of if its out of support or not, it will be interesting to know the method for the breach
You're absolutely right, and I accept the failure on my side.
Just to clarify, this is informational, not a complaint. I'm sharing it so you're aware that this actually happened in our environment and can take it into account.
Hi,
Which on recent PSA allows an attacker to gain access to the host via LXC or VM. So yeah, not really a 0 day
I'm running a PVE8 system exposed to the internet (yes, I know not a good practice), but it's up to date (8.4.21) and I haven't waited too much to update. So far nothing and all the users on the WebUI have MFA using security keys or OTP.
And all my servers or VMs exposed to the internet have at least crowdsec installed with iptable/nftable bouncer.
Best regards,
hum 8.4 was out on the 9 april 2025, so it's affected by all the PSA (which affect PVE8) after this post : https://forum.proxmox.com/threads/p...nment-security-advisories.149331/#post-764654
Which on recent PSA allows an attacker to gain access to the host via LXC or VM. So yeah, not really a 0 day
I'm running a PVE8 system exposed to the internet (yes, I know not a good practice), but it's up to date (8.4.21) and I haven't waited too much to update. So far nothing and all the users on the WebUI have MFA using security keys or OTP.
And all my servers or VMs exposed to the internet have at least crowdsec installed with iptable/nftable bouncer.
Best regards,
Did you read the mentioned thread on lowendtalk? What is there to actually panic about? In what way did they mention Proxmox? Did they simply say "Can confirm not running Proxmox"? Please don't exacerbate LLM mistakes posted by others.
This is highly unlikely. Any Software has bugs and in System stuff like the Kernel every bug is an security issue. Since right now every week ai-assisted Security research discover previously unknown bugs it‘s just not realistic to assume that a certain Version is not exploitable. There is only one thing you can be sure: If you have installed all patches you are not vulnerable due to known bugs with an applied bugfix. You can still get owned by unknown exploits but bad Actors still mostly use known attack Channels. The timewindow for applying patches isn‘t long though. Right know It’s under 24 Hours before known exploits gets widdly used. This is expected to be lowered to one Hour or even one Minute next year: https://zerodayclock.com/
In other words: „Change-Management“ aka „Patch-avoidance Management“ or „keeping Systems hackable Management“ is finally over, allthough it will first need a new wave of ransomware attacks that enterprises ( especially in critical Infrastructure) will realize it. Nontheless: Good riddance!
Last edited:
Yes - even though this isnt proxmox itself im sure it would be helpful to find the method of the breach, for instance, im sure if hetzner were breached and proxmox hosts cryptolocked, many people who run proxmox on hetzner would come here as well
So because one vendor sucks every other sucks too? Interessting „Logic“ which confirms my strong belief that most developers and admins ( myself included ) shouldn‘t get ssh Not Root Access on Servers. In that regard immutable, Auto-updated Systems like IncusOs or talos have a clear benefit.
Hi,
The big problem that "virtualizor" has is that "[...]product update clients did not yet cryptographically verify update packages[..]" Unlike all debian/proxmox systems which use apt with gpg signed packages…
Best regards,
What are you talking about ? Neither hetzner was breached and/or proxmox host in hetzner network was affected by the BGP Hijack.
The big problem that "virtualizor" has is that "[...]product update clients did not yet cryptographically verify update packages[..]" Unlike all debian/proxmox systems which use apt with gpg signed packages…
Best regards,
I don't know if this is due to a language barrier or something, but obviously, when I said 8.2 and 8.4 don't have vulnerabilities, I didn't mean those systems are flawless. I just meant they don't have the unauthenticated RCE vulnerability we're currently dealing with.
Last edited:
1) Some people have their proxmox hosts connected to virtualizor
2) virtualizor was hacked with a feasible method of deploying ransomware https://www.virtualizor.com/blog/security-incident-bgp-hijacking/
3) The point of this thread is to find out the method in which the ransomware was deployed, it is very easy to say ohh your stuff isnt patched or open to the internet, i dont care about that, i want to know how this was deployed, and if it is a 0 day or a previously known vulnerability
regarding hetzner, i am only saying that in the case that hetzner was hacked, there would be many threads here wondering what happened to their proxmox hosts
I was hit with this same attack the night of the 28th luckily had backups i setup less than 24 hrs prior to happening. Seems they went around just scanning for vulnerable hosts exposed to the public. I had 2 hosts exposed to the public one 7.3-6 which was hit the other was 8.1-10 but that one didn't seam to have an issue no clue if they even attempted or not. 100% my fault for leaving these exposed to the internet and out of date they're both upto date and behind firewalls now luckily.
Unless we had missed it in the PVE logs they didnt attempt access via that or they removed their single entry point in that log. All other logs got cleared which kinda makes me assume it wasnt via PVE and an exploit somewhere else on the host system.
The only IP which accessed our system that we found on the network was from https://bgp.tools/as/27284
Unless we had missed it in the PVE logs they didnt attempt access via that or they removed their single entry point in that log. All other logs got cleared which kinda makes me assume it wasnt via PVE and an exploit somewhere else on the host system.
The only IP which accessed our system that we found on the network was from https://bgp.tools/as/27284
Last edited:
Hi,
All the systems mentionned was affected by :
Best regards,
how can you be sure that there is a "unauthenticated RCE" touching PVE7/8 systems ?
All the systems mentionned was affected by :
- https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-860952
- https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-862410
- https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-865179
- https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-865180
so it's a virtualizor issue, not a proxmox issue
Which cannot be applied to proxmox updates, since there is cryptographic verification unless the attacker gains access to proxmox signing infrastructure.
ATM no one that reported being touched by the ransomware has given any clue or log to appreciate the method... so for now the "obvious" reason is simply EOL systems exposed to the internet, yes it's a shortcut but without traces/logs there nothing more to appreciate.
Well not really, IF "hetzner was hacked" like you say, this changes nothing to their customers who used a bare metal server, the server still runs and the hacker should have no access to the host.
Best regards,
Virtualizor does have issues currently but this was not related to that as my system was not attached to it. Our PVE 8.1 install didnt get hit by this only 7.3-11.
Wish I had more logs to share but had to wipe the machine quickly and get it back up.
To me, it doesn't even make sense we are commenting about Virtualizor and Hetzner on this thread, since the issue is that we may or may not have a security issue within old versions of Proxmox itself, and it isn't even slightly clear yet. Can we leave Virtualizor out of this???
Sure, but who will put in the time to determine what CVE was used? Then we know for sure which versions are affected. Until then, up to date Proxmox appears to be safe.
Well, if that makes any difference (I'm not a troll and have been registered for years):
* I had a few bare metal customers with publicly accessible proxmox 7.2 URLs that were hacked;
* Same message as these other users (ramsomware note)
* No virtualizor installed
* I couldn't find the attack vector but seems like it was through SSH as I've reviewed the logs available and didn't seem they logged in using the proxmox GUI
* Old logs were deleted preventing more investigation
* They look for NFS mounts with "backup" names and delete everything within it
* Mounting the backup folders only when necessary might be something to consider
Last edited: