Potential VestaCP zeroday exploit [May 19 Security Update Pushed]

Well, I though about using VestaCP, but in the end, I decided against it.

Yesterday hetzner took my cloud server offlline due ddos attack.I wonderd how that could happpend? Now i see is vestacp.I had vestacp installed on it :frowning:

I have never had a problem with IPs getting blocked, if they were it was obvious why. Anyone can get a second IP and use if the primary is blocked, which all OVH users can unblock on their end. It’s an inconvenience only if the person doesn’t monitor or secure their servers in the first place, in which case a few minutes of the IP being blocked to stop outbound attacks probably won’t cause them to lose millions of dollars.

I was referring to OVH putting your server in rescue mode, forcing you to do an OS reinstall if you wish to continue using it… I wasn’t talking about them blocking IPs.

From my understanding they only do that if their anti-hack blocks the IP, but the user continuously unblocks it without fixing the problem, unless they recently changed it due to these types of vulnerabilities being used so much.

I haven’t experienced this myself, but from what I gathered reading the vestacp forum thread, quite a lot of them woke up with servers in rescue mode. I’m not entirely sure what the OVH exact procedure is on this.

I guess that anyone not sanitizing user input properly in this day and age deserves to get hacked. I don’t understand how this didn’t happen sooner as the code is open source and the exploit is pretty basic.


access_log /dev/null main;


1 Like

Just cathing up on the thread on vestacp forum, and stumbled upon the email from DigitalOcean who downed all droplets running vestacp, quite drastic but I guess much needed prevention measurement.

That’s expected because the rooted servers are most likely to be used for DDoS and SPAM.

Shoutout DigitalOcean, AWS, and any other hosts that offer a cloud firewall/security groups. Helped a friend secure hundreds of Vesta boxes in minutes last night by blocking 8083 across every server in seconds.

@Hetzner_OL I’m gonna need firewall added to the features list, plz & thx


Patch released


Including some famous last words…

Therefore we have completely rewrite password auth function. It’s bullet proof now!


Challenge accepted.

~200 hackers worldwide.


Maybe this is their way of getting some free pen testing?

1 Like

Putting such claims up, could lead to more people, who will exploit the new code again.
Since that worked good, for DDOS, they may try it again.

I had an IP blocked in correlation to this exploit. I’m not with OVH, though.

For every person you see upset about it, there are many more not posting about how upset they were over constant packet loss. The compromised servers were being used in batches so you’d get alerts, respond, restore order, rinse and repeat for a day. Someone definitely meant business with this :frowning:

1 Like

Oh yeah, I’m not debating their decision. I can imagine it must have been a nightmare-ish type of scenario for such a big vps provider.

A couple things about all this.

One, even with the update I do not suggest running your vesta control panel on the open. Just do not do it right now. Wait for news that the patch really fixed, unless you have to run the control panel for users. Maybe do functions for them for the time being while you await to make sure the patch held.

Two, I do not think the API was the only exploited point. I do think the API was used, but not for everything. I think either exim + dovecot got hit, or roundcube was also hit. A combined attack vector to get the installation compromised.

Three, if you have a vesta instance please install clamav and scan your full system to be sure nothing was installed. Don’t go off assuming everything is hunky and dory because you don’t see a single cron.hourly entry.

Four, if you were compromised do not just remove the virus. Take a full backup, and do a restore. Vesta Control Panel — Documentation This is the safest way, and will remove any other holes they may have added. It is also a good time to upgrade the server to a newer distro and package set.

Five, please please please take backups of your installation even if you aren’t compromised currently as a fallback point.

Six, you do not gain security by simply changing the port of your control panel. Do not assume this protects you as people have already been hacked even with a port change.

Seven, of Nine.


Weird. I just did a fresh install of VestaCP (just to be sure), and I’m unable to update from 0.9.8-19 to 0.9.8-20 on Debian 9. The web panel’s update function doesn’t do anything other than refreshing the page, and the CLI command doesn’t seem to do anything either.

For some reason they haven’t added it to their mirror yet. It isn’t just you, and a few people have complained about it on the forums.

I also checked again on it this morning and here is what I got.

1 Like