Recent Posts
21
Backup / problem with the local beta backup
« Last post by cgauthey on July 08, 2026, 01:37:42 PM »I notice this problem with the local beta backup
I am encountering an issue with the local backup restore feature (beta version).
Hello,
We are experiencing a problem with the new local backup restore feature on our server.
The backup files are present on the server and appear to be complete and intact. However, the restore process does not start correctly.
Whenever we attempt to restore an account, the process consistently gets stuck at the "Detecting files" stage and makes no further progress.
The restore log repeatedly shows the following information:
2026-07-07 14:14:06 UPDATE restore SET ST='20260707201406' WHERE ST='1'
2026-07-07 14:14:06 >>>>>>>>> [1,1,1,1,1,1,1,1,1,grizzy,2026-06-27_17-15-04,0,,1,1,1,1,1]
2026-07-07 14:14:06 Detecting files
We have verified that the backup directory exists and that all backup archives are available.
Based on our investigation, it appears that the restore utility is generating an incorrect path and attempting to locate a non-existent backup archive, even though the backup data is available at the correct location.
Could you please check if this is a known issue with this new local backup restore feature?
If so, is there a fix, a workaround, or an updated restore procedure available to successfully restore the accounts?
I am encountering an issue with the local backup restore feature (beta version).
Hello,
We are experiencing a problem with the new local backup restore feature on our server.
The backup files are present on the server and appear to be complete and intact. However, the restore process does not start correctly.
Whenever we attempt to restore an account, the process consistently gets stuck at the "Detecting files" stage and makes no further progress.
The restore log repeatedly shows the following information:
2026-07-07 14:14:06 UPDATE restore SET ST='20260707201406' WHERE ST='1'
2026-07-07 14:14:06 >>>>>>>>> [1,1,1,1,1,1,1,1,1,grizzy,2026-06-27_17-15-04,0,,1,1,1,1,1]
2026-07-07 14:14:06 Detecting files
We have verified that the backup directory exists and that all backup archives are available.
Based on our investigation, it appears that the restore utility is generating an incorrect path and attempting to locate a non-existent backup archive, even though the backup data is available at the correct location.
Could you please check if this is a known issue with this new local backup restore feature?
If so, is there a fix, a workaround, or an updated restore procedure available to successfully restore the accounts?
22
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by Starburst on July 08, 2026, 08:06:59 AM »The date math isn't mathing...
No offense.
The CVE you posted here, CVE-2026-57517.
https://nvd.nist.gov/vuln/detail/CVE-2026-57517
And was published on 2026-07-01. CWP had fixed that security hole as the CVE shows with 0.9.8.1225 and later.
CWP 0.9.8.1225 was pushed to servers on the night of 2026-05-06.
CWP 0.9.8.1226 was pushed to servers on the night of 2026-05-10
--
CVE CVE-2025-48703:
https://nvd.nist.gov/vuln/detail/CVE-2025-48703
And was published on 2025-09-19. CWP had fixed that security hole as the CVE shows with 0.9.8.1205 and later.
CWP 0.9.8.1205 was pushed to servers on the night of 2025-06-16.
CWP had those 2 security holes patched almost 2 months BEFORE the CVE's came out.
So if you had an up2date server, the security holes were already closed, and wouldn't allow hackers in using those methods.
I've also never seen a SysAdmin leave SSH on the default port and not behind some kind of firewall to limited access.
If you are truly running 5 servers for 5 years, I'm guessing these are EOL (2024-06-30) CentOS 7 boxes from the date you gave.
The CWP migration tool works between CentOS 7 and AlmaLinux 8.
Unfortuently, it currently doesn't between CentOS 7 and AlmaLinux 9, or AlmaLinux 8 -> AlmaLinux 9.
No offense.
The CVE you posted here, CVE-2026-57517.
https://nvd.nist.gov/vuln/detail/CVE-2026-57517
And was published on 2026-07-01. CWP had fixed that security hole as the CVE shows with 0.9.8.1225 and later.
CWP 0.9.8.1225 was pushed to servers on the night of 2026-05-06.
CWP 0.9.8.1226 was pushed to servers on the night of 2026-05-10
--
CVE CVE-2025-48703:
https://nvd.nist.gov/vuln/detail/CVE-2025-48703
And was published on 2025-09-19. CWP had fixed that security hole as the CVE shows with 0.9.8.1205 and later.
CWP 0.9.8.1205 was pushed to servers on the night of 2025-06-16.
CWP had those 2 security holes patched almost 2 months BEFORE the CVE's came out.
So if you had an up2date server, the security holes were already closed, and wouldn't allow hackers in using those methods.
I've also never seen a SysAdmin leave SSH on the default port and not behind some kind of firewall to limited access.
If you are truly running 5 servers for 5 years, I'm guessing these are EOL (2024-06-30) CentOS 7 boxes from the date you gave.
The CWP migration tool works between CentOS 7 and AlmaLinux 8.
Unfortuently, it currently doesn't between CentOS 7 and AlmaLinux 9, or AlmaLinux 8 -> AlmaLinux 9.
23
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by 6Sense on July 08, 2026, 04:21:17 AM »Changing SSH port is imperative IMO.
Just be aware that the gsocket exploit bypasses the firewall entirely (doesn't matter what ports you block) so this is not an effective measure against it. Was glad to see multiple CWP version upgrades in quick succession to help keep us safe.
Just be aware that the gsocket exploit bypasses the firewall entirely (doesn't matter what ports you block) so this is not an effective measure against it. Was glad to see multiple CWP version upgrades in quick succession to help keep us safe.
24
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 08, 2026, 04:06:34 AM »None of my servers were hit. Probably because I'm running low on the radar to script kiddies, worms, and Shodan.
https://azdigi.com/en/blog/webserver-panel/centos-web-panel/how-to-change-the-port-on-centos-web-panel-cwp
https://wiki.centos-webpanel.com/how-to-change-ssh-port
Yeah, I never use port 22 on my servers either — it's one of the first things I change during configuration. But since the issue came from public panel access, you probably weren't affected because you changed CWP's default ports or had other protections. Now that I know CWP access is risky, I'll put it behind a firewall or block public access entirely.
25
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by overseer on July 08, 2026, 03:03:48 AM »None of my servers were hit. Probably because I'm running low on the radar to script kiddies, worms, and Shodan.
https://azdigi.com/en/blog/webserver-panel/centos-web-panel/how-to-change-the-port-on-centos-web-panel-cwp
https://wiki.centos-webpanel.com/how-to-change-ssh-port
https://azdigi.com/en/blog/webserver-panel/centos-web-panel/how-to-change-the-port-on-centos-web-panel-cwp
https://wiki.centos-webpanel.com/how-to-change-ssh-port
26
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 08, 2026, 01:21:10 AM »Thanks, but maybe some introductions are in order...
Sure, introductions are fair.
I've run CWP for about 5 years, and all 5 of my servers on the panel got hit in this wave. I spent several days doing the cleanup myself, so what I'm sharing are my own notes from actually working these boxes, not theory.
Here is what it came down to on my side, now that the picture is clear.
The entry point was the panel, not SSH and not the database port. In my case it lines up with the newer bug, CVE-2026-57517, the unauthenticated blind SQL injection in the panel (the userRes parameter). It runs inside the panel's own MySQL root session, so the injected SQL executes as root on its own, then it writes a PHP file to a web path and that gives remote code execution, then full root. It was fixed in 0.9.8.1225, but that fix landed around the July disclosure, which is after my servers were already breached in June, so at the time there was no patch to apply even on a fully updated box. The older file manager RCE (CVE-2025-48703, fixed a year ago in 0.9.8.1205) was not my vector, my boxes had been patched against that one for months.
The part I want people to take away: the firewall was never what saved or doomed a box here. One of my servers had a full firewall (CSF) and still got rooted, because the panel ports have to stay open for you to administer them, so the firewall was gating the database and the random ports but never the panel itself. Every one of my servers was rooted the exact same way through the panel, firewall or not. What actually differed from one box to the next was only what each server was worth to the attacker, so a static content server just got the backdoor while my main WordPress site is where they went after the app layer.
So the real fix on my end was not another IP rule. I closed the panel ports to the public completely, and I now reach them only through an SSH tunnel, with the key itself protected by a passphrase. Nothing on those ports is exposed to the internet anymore, even if my IP changes or the next panel bug drops.
27
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 07, 2026, 11:47:04 PM »
Another new AI troll account with a very, very supicious link at the end...
No wonder, I've largely resolved the leaks with AI tools that CWP's fix couldn't address. Plus they destroyed the root user's authorized keys, which caused a lot of concern among forum users.
Rentry is just a pastebin service with markdown, so there's no risk. https://www.scamadviser.com/check-website/rentry.co?url=%2Fh2cqmbco
However, I also resolved quite a few issues on my end with Wordfence and ClamAV. Despite the fixes CWP quietly applied, the damage was already too extensive, so I think this will help a lot of users. I can't see how CWP can fix the intrusion of malicious scripts when the behavior can vary from one server to another. The truth is that thousands of servers have been infiltrated by one or more malicious hackers, and surely thousands of servers have backdoors that give unlimited access to any bad actor without the owners even knowing.
This is the first time I've left a review because on my end, what the intruder managed to pull off on my servers was very serious.
Translated with GLM 5 xD
28
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by Starburst on July 07, 2026, 03:17:09 PM »
Another new AI troll account with a very, very supicious link at the end...
29
Updates / Re: Dev Team went rogue ?
« Last post by overseer on July 07, 2026, 01:34:34 PM »I read the script. Your theory is definitely worthy of Ian Flemming. Refutation straight from the Administrator's keyboard:
Dev Team Member went Rogue and start Hacking CWPro servers, thats why the updates.
nope, only new hackers with AI are now attacking...but we solve them.
30
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by overseer on July 07, 2026, 01:29:32 PM »Thanks, but maybe some introductions are in order...
