Cyberpanel delete all files and directors public_html

It didn’t delete everything except wp-content, it deleted everything including wp-content and then wp-content was recreated (as an empty shell) by an automatic script that needed to make a folder inside it.

If you run mkdir -p wp-content/something/something-else it will create all the parent directories for your innermost one.

1 Like

ok,hope your problem will get solved soon

why you have process than run this ?
if public html already empty

well i hope your problem will solved soon

The main point I came to make is that this bug had the potential to destroy an entire business for someone who didn’t have any other backups except Google Drive installed.

Thankfully, we’re not complete amateurs, but there is no way I could recommend Cyberpanel to anyone if such a major error and deletion of all site files could even be a possibility, bug or no bug.

@ricardojds thanks for the note about 2nd March installation. Can someone advise in simple terms how to update Cyberpanel then? Should we be installing the dev version because at the moment our server is showing it’s using 2.1 Build 1 though, not Build 2.

2 Likes

@edwardm @dazburn this log line is in the syslog?

1 Like

Proceed with caution :rofl:

FIY i’m not part of dev team i just need a good hosting manager tool and this project beeing opensource and Python based, its a match for my needs and skills

1 Like

@ricardojds

I’ve confirmed both cases after my fix. public_html is not deleted now, these guys may have v2.1.2 but they will not have the latest code.

Be sure to upgrade.

1 Like

@usmannasir

This is yet another example of why it is MISSION CRITICAL, TOP PRIORITY to improve the versioning system before you work on anything else.

We currently don’t receive any notification that there have been minor updates, so most people have no idea that they need to do so. This is even more urgent when you push tiny updates to fix CATASTROPHIC bugs, such as this one.

It seems completely clear that you should be making proper use of the 2.1.X for all of these - each minor commit should result in the final digit incrementing. It can go to 2.1.99999999 if needed. And then when a major feature is added, it moves to 2.2.0. And when there are breaking changes, it moves to 3.0.0. This is basic, standard practice.

If this makes your development/git workflow more difficult, so be it - it doesn’t matter compared to this. Though, given that this is standard practice, I don’t see how it could be difficult to manage. You’ll just have to adapt your workflow. There is no other choice.

Again, someone nearly lost their entire business because of this bug. Moreover, how many servers and businesses are currently running on a version of 2.1.2 that doesn’t have this fix (let alone all the other fixes from the past 6 months since 2.1.2 was released)? Thousands? Tens of thousands? More? All of your efforts to improve the security and stability are irrelevant if people aren’t made aware until an official version comes out every 6-12 months…

It would be completely unforgivable if you don’t urgently take the appropriate steps (detailed above) to fix this problem once and for all.

@die2mrw007 @shoaibkk @asma, I’m copying you here to make sure you are aware and that you can put your energy towards supporting Usman in urgently making this crucial change

2 Likes

i always vote-up and always agree with this…

One quick fix is using

root@server:/usr/local/CyberCP# git rev-parse --short HEAD
e6ed5094

becoming the version 2.1.2.e6ed5094

1 Like

How is this different/better than running the upgrade script?

Also, that’s an old commit - there’s a newer one related to this bug since then

Commits · usmannasir/cyberpanel (github.com)

Or, are you saying that the “fix” was not a fix?

1 Like

@usmannasir i’m woried with this log line

Remember that when i was digging it was the print function that was causing the issue.

why whould some print command send the string to be used as a parameter on a rm -f command?

This means that with the newest version it is beeing called an command like this:

/usr/bin/rm -f Failed to run cp command during backup generation.

If there is somewere else another thing like this, cyberpanel may be vunerable to sheel injection that will be run as root, this is a huge security risk to be taken light

2 Likes

Ok, thanks. I dont really understand, but take your word for it.

So, the most recent fix is not a fix. But the commit (e6ed5094) that uses copytree works fine and doesnt delete anything when there is a disk space or permissions issue?

ignore e6ed5094 this is from my dev server that is not up to date :laughing:

1 Like

Ok, so is there a commit that satisfies this issue? Or does it still need Usman’s attention?

two known scenarios where fixed with the change of the line 378 with commit 6e40f53

The thing that is worrying me is that the string passed to the exception, according to the log line shared, is being used in an rm command. this is another thing we need to checkout

CyberPanel has been audited by rack911 (they are pioneer in these sorts of audits), our work with them is almost complete now.

However, if you can still penetrate using any function do let me know.

We’ve fixed and addressed many security issues.

Because to make it easy to understand where problem happened (but it was our mistake), it was kind of you to point it out. I will again go through code to make sure things are OK.

thanks.

1 Like

It is fixed.

I will release v2.1.3 first and then take care of it.

2 Likes

this 2.1.2 too ?