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):
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 -9
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
Topic: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's (Read 188 times)
