Recent Posts
21
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.
22
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
23
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...
24
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.
25
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...
26
CentOS-WebPanel Bugs / CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 07, 2026, 11:27:36 AM »If your CWP box has been acting up since mid-June — root SSH key vanishing
overnight, MySQL users dropped, "cleanups" that don't hold, /etc/hosts pointing
gsocket.io / cloudsyndication.org at 127.0.0.1 — it's all one incident. Short
version, including the one thing nobody here has posted yet: the actual
PERSISTENCE that makes your cleanups keep failing.
TWO unauthenticated panel bugs are behind this, both chaining to RCE:
- CVE-2025-48703 — command injection in the file manager. Fixed 0.9.8.1205
(CISA KEV, mass-exploited). = the July-2025 "PHP execution via filemanager".
- CVE-2026-57517 — blind SQLi via the userRes param, runs as MySQL root ->
INTO DUMPFILE a PHP payload -> RCE. Fixed 0.9.8.1225. = the current wave.
Both need only a valid non-root username. Patch past BOTH (>= 0.9.8.1225) — or
better, firewall the panel (see end).
DIRECT ANSWER to the "new security issue and no communication" thread:
- That "script hunting for a mysterious SSH key" is CWP's OWN
/scripts/temp_hacker_check. The key it hunts is the ATTACKER's:
IPCsi58xDKuXuq8CMnlIFQHoqiGkyziMQpAks2t0EBa0
- The "bug that wipes all your SSH keys" is that same script: early builds ran
cleanup through the "operator" account (home = /root on RHEL) -> effectively
"rm -rf /root/.ssh" nightly. Stop-gap: usermod -d /var/empty operator.
0.9.8.1244 made it surgical (it now only sed's out that one key line).
So your key-wipe = CWP's own cleanup misfiring, NOT the attacker (he PLANTS
keys, he doesn't delete them).
THE PART EVERYONE MISSES — why cleanups don't hold:
A gsocket reverse C2 installed as a SYSTEMD SERVICE, DISGUISED AS A KERNEL
THREAD (e.g. defunct.service, Restart=always, ExecStart via exec -a
'[watchdogd]'; on-disk binary deleted-while-running). It's an OUTBOUND
connection, so your firewall doesn't stop it — the attacker dials back in and
re-plants keys/users/sudoers by hand. CWP's cleanup kills the /tmp gsocket but
NEVER this unit, so it survives every update.
Find it (name-independent — a real kernel thread has an EMPTY /proc/PID/cmdline;
an imposter has a bracketed cmdline BUT a resolvable /proc/PID/exe):
the process, rm the binary + .dat, remove the re-planted keys / NOPASSWD sudoers
/ "login" user, and chattr -i /root/.ssh/authorized_keys if it's immutable.
Other IOCs: /usr/bin/defunct, */systemd/system/defunct.{service,dat}, /tmp/.gs-0,
/dev/shm/.gs-0; the /tmp/.auto_monitor + /tmp/.tmp_baf droppers; random
<name>.php or fake .jpg webshells in public_html. If you run WordPress, check the
DB users/roles too — an OS-level sweep never sees app-layer admin accounts.
THE REAL FIX: for a box rooted for weeks, rebuild it (fresh OS, restore DATA
ONLY, rotate EVERY secret that lived on it) and FIREWALL the CWP panel ports
(2030-2087) to your own IPs. Two unauthenticated panel RCEs in twelve months
means patching alone can't keep up — stop exposing the panel to the internet.
And to CWP: the changelog skips every version 1236-1244, there is no advisory,
yet your own script hardcodes the attacker's key — you clearly know exactly what
happened. Please publish the CVEs, the IOCs, and manual remediation steps.
Full writeup (step-by-step remediation, the WordPress rogue-admin case, and what
we rebuilt): https://rentry.co/h2cqmbco
overnight, MySQL users dropped, "cleanups" that don't hold, /etc/hosts pointing
gsocket.io / cloudsyndication.org at 127.0.0.1 — it's all one incident. Short
version, including the one thing nobody here has posted yet: the actual
PERSISTENCE that makes your cleanups keep failing.
TWO unauthenticated panel bugs are behind this, both chaining to RCE:
- CVE-2025-48703 — command injection in the file manager. Fixed 0.9.8.1205
(CISA KEV, mass-exploited). = the July-2025 "PHP execution via filemanager".
- CVE-2026-57517 — blind SQLi via the userRes param, runs as MySQL root ->
INTO DUMPFILE a PHP payload -> RCE. Fixed 0.9.8.1225. = the current wave.
Both need only a valid non-root username. Patch past BOTH (>= 0.9.8.1225) — or
better, firewall the panel (see end).
DIRECT ANSWER to the "new security issue and no communication" thread:
- That "script hunting for a mysterious SSH key" is CWP's OWN
/scripts/temp_hacker_check. The key it hunts is the ATTACKER's:
IPCsi58xDKuXuq8CMnlIFQHoqiGkyziMQpAks2t0EBa0
- The "bug that wipes all your SSH keys" is that same script: early builds ran
cleanup through the "operator" account (home = /root on RHEL) -> effectively
"rm -rf /root/.ssh" nightly. Stop-gap: usermod -d /var/empty operator.
0.9.8.1244 made it surgical (it now only sed's out that one key line).
So your key-wipe = CWP's own cleanup misfiring, NOT the attacker (he PLANTS
keys, he doesn't delete them).
THE PART EVERYONE MISSES — why cleanups don't hold:
A gsocket reverse C2 installed as a SYSTEMD SERVICE, DISGUISED AS A KERNEL
THREAD (e.g. defunct.service, Restart=always, ExecStart via exec -a
'[watchdogd]'; on-disk binary deleted-while-running). It's an OUTBOUND
connection, so your firewall doesn't stop it — the attacker dials back in and
re-plants keys/users/sudoers by hand. CWP's cleanup kills the /tmp gsocket but
NEVER this unit, so it survives every update.
Find it (name-independent — a real kernel thread has an EMPTY /proc/PID/cmdline;
an imposter has a bracketed cmdline BUT a resolvable /proc/PID/exe):
Code: [Select]
for p in /proc/[0-9]*; do
cmd=$(tr -d '\0' < "$p/cmdline" 2>/dev/null); exe=$(readlink "$p/exe" 2>/dev/null)
case "$cmd" in \[*\]) [ -n "$exe" ] && echo "IMPOSTER pid=${p#/proc/} $cmd -> $exe";; esac
done
Any hit = your persistence. Then: systemctl stop/disable/mask that unit, kill -9the process, rm the binary + .dat, remove the re-planted keys / NOPASSWD sudoers
/ "login" user, and chattr -i /root/.ssh/authorized_keys if it's immutable.
Other IOCs: /usr/bin/defunct, */systemd/system/defunct.{service,dat}, /tmp/.gs-0,
/dev/shm/.gs-0; the /tmp/.auto_monitor + /tmp/.tmp_baf droppers; random
<name>.php or fake .jpg webshells in public_html. If you run WordPress, check the
DB users/roles too — an OS-level sweep never sees app-layer admin accounts.
THE REAL FIX: for a box rooted for weeks, rebuild it (fresh OS, restore DATA
ONLY, rotate EVERY secret that lived on it) and FIREWALL the CWP panel ports
(2030-2087) to your own IPs. Two unauthenticated panel RCEs in twelve months
means patching alone can't keep up — stop exposing the panel to the internet.
And to CWP: the changelog skips every version 1236-1244, there is no advisory,
yet your own script hardcodes the attacker's key — you clearly know exactly what
happened. Please publish the CVEs, the IOCs, and manual remediation steps.
Full writeup (step-by-step remediation, the WordPress rogue-admin case, and what
we rebuilt): https://rentry.co/h2cqmbco
27
Updates / Re: CWP7: 0.9.8.1243
« Last post by Administrator on July 07, 2026, 06:04:25 AM »Dev Team Member went Rogue and start Hacking CWPro servers, thats why the updates.
nop, only new hackers with AI are now attacking...but we solve them.
28
Updates / Re: update 0.9.8.1239 remove all users database + postfix acc
« Last post by overseer on July 07, 2026, 02:07:10 AM »Now at 0.9.8.1244. Rapid update with small fixes.
30
Other / Re: Yanz Webshell! - PRIV8 WEB SHELL ORB YANZ BYPASS! V3.0
« Last post by Starburst on July 07, 2026, 01:58:05 AM »@cgauthey Keep your AL8 server updated and don't allow shell access to users and you'll be fine.
If you're still running CentOS 7, there are no patches for an EOL OS.
Yanz Webshell has been hitting Linux Kernels and WordPress sites.
CWP fixed this CVE several versions back.
But other software, like mentioned above may still have it, if you haven't updated and secured your server.
If you're still running CentOS 7, there are no patches for an EOL OS.
Yanz Webshell has been hitting Linux Kernels and WordPress sites.
CWP fixed this CVE several versions back.
But other software, like mentioned above may still have it, if you haven't updated and secured your server.
