Messages

1

CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

« on: July 23, 2026, 02:24:22 PM »

I have removed 3 entries from /etc/hosts
127.0.0.1 mya.cloudsyndication.org
127.0.0.1 gsocket.io
127.0.0.1 www.gsocket.io

and I have upgraded apache to version 2.4.66.
I have also checked numerous files on server, but I didn't find something suspicious.
Everything seems to work fine by now, but I am not sure if server is 100% clean.
Can you suggest something else that I should check?
Thank you

Sorry you got hit too. This is the same compromise being tracked in the big "I think there is a very serious security vulnerability in CWP right now" thread - same gsocket C2, same IOCs. We cleaned it across our own fleet. Removing the /etc/hosts lines and restarting Apache does nothing: those entries are cosmetic, and the infected files get re-infected within 2-3 minutes as long as the persistence is alive. So order matters - kill persistence FIRST, then clean.

The hard truth first: once an attacker had a root C2 on the box, you can't fully trust that OS again - modified binaries, a hidden rootkit or backdoored packages are all possible. The only way to be 100% sure is a fresh rebuild on a supported OS (you are on CentOS Linux 8.5.2111, EOL, no security updates - move to AlmaLinux 8 or Rocky 9/10 anyway), migrating data only after scanning, rotating every credential, then repointing DNS. That is what we did for our worst-hit box.

If you clean in place, here is the checklist that worked, in this order:

0. Apply the official fix + close the entry points
Run the CWP updater TWICE (some users still got reinfected on 0.9.8.1231; you want 0.9.8.1235+):

Code: [Select]

sh /scripts/update_cwp && sh /scripts/update_cwpThe likely entry vector is Roundcube (CVE-2025-49113) - and CWP re-bundles a vulnerable Roundcube on install, so update it and close webmail (2095/2096) to the public. Close the panel ports too (2030/2031, 2082-2087) - restrict to your IP, or reach them only through an SSH tunnel. The gsocket C2 is outbound, so the firewall never stopped it.

1. Kill the gsocket persistence (do this BEFORE cleaning files)
The C2 ships as a service named defunct.service, running gsocket from /usr/bin/defunct with config /lib/systemd/system/defunct.dat, and hides its process as a fake kernel thread (a bracketed name such as mm_percpu_wq in ps auxf).

Code: [Select]

systemctl stop defunct.service; systemctl disable defunct.service
rm -f /usr/bin/defunct /lib/systemd/system/defunct.dat
rm -f /usr/lib/systemd/system/defunct.service /etc/systemd/system/multi-user.target.wants/defunct.service
systemctl daemon-reload
ps auxf | grep -Ei 'mm_percpu_wq|defunct|gs-netcat'   # must be empty now
ss -tnp                                               # no outbound to the C2 IPs belowThen check for variants and re-install vectors:

Code: [Select]

systemctl list-unit-files --state=enabled
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done
grep -Rn '' /etc/cron* /var/spool/cron/ /etc/rc.local /etc/profile.d/ 2>/dev/null | grep -iE 'curl|wget|base64|/tmp|/dev/shm'
2. Remove SSH backdoors (they are set immutable - deletion fails silently)
The attacker sets chattr +i on the planted authorized_keys, so a plain rm does nothing. Clear the flag first:

Code: [Select]

find / -name authorized_keys 2>/dev/null -exec lsattr {} \;   # look for the 'i' flag
chattr -R -i /root/.ssh /home/*/.ssh 2>/dev/null
rm -rf /var/lib/mysql/.ssh                                    # service accounts must NOT have .sshThen audit every remaining authorized_keys for keys you did not add. Known-bad key seen in these attacks: SHA256:w79EbEKrlqugvMc8n/i9dQ5QuvhFBdJZDA/UKdSek2o

3. Remove rogue accounts + sudo backdoors

Code: [Select]

awk -F: '($3==0 && $1!="root"){print "UID0:"$1} /^(__user|user__|login|imunify):/{print "ROGUE:"$1}' /etc/passwd
grep -REn 'NOPASSWD' /etc/sudoers /etc/sudoers.d/ 2>/dev/null
awk -F: '$3<1000 && $7 ~ /(ba)?sh$/ {print $1":"$7}' /etc/passwd   # service accts with a login shell = tamperedService accounts (bin, daemon, sshd, named ...) should be /sbin/nologin or /bin/false. If they have /bin/bash, the attacker edited /etc/passwd - reset them to nologin.

4. Clean the web injection (the cloaking that serves spam to visitors, clean pages to you)

Code: [Select]

grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home /usr/local/apache/htdocs 2>/dev/null
find / -type f \( -name '.x.php' -o -name '.r.php' -o -name 'cmd.php' -o -name 'shell.php' -o -name 'c99.php' -o -name 'r57.php' -o -name 'wso.php' \) 2>/dev/nullThat base64 string is the eval(base64_decode(...)) payload (it decodes to ini_set("display_errors",0) ...); it lands in index.php, wp-config.php, and a "defauit.php" typo file. Also check every .htaccess for RewriteCond on HTTP_USER_AGENT / HTTP_REFERER, and auto_prepend_file / auto_append_file in php.ini + any .user.ini. List files changed in your intrusion window (adjust the dates):

Code: [Select]

find /home /var/www /etc -type f -newermt "2026-06-01" ! -newermt "2026-07-15" 2>/dev/null
5. Check for trojaned system binaries

Code: [Select]

rpm -Va | grep -E '^..5'                 # '5' = checksum changed; scrutinise /usr/bin, /usr/sbin, /bin
find / -perm -4000 -type f 2>/dev/null   # unexpected SUID backdoorsThen run rkhunter, chkrootkit and a ClamAV / maldet scan.

6. Rotate EVERYTHING (assume total credential theft)
root + all CWP user passwords, MySQL root + every DB user, WordPress admins + regenerate the wp-config salts, all mail passwords, any API tokens. Regenerate the SSH host keys too.

Network IOCs to block / hunt: IPs 89.248.172.183, 89.248.172.118, 152.53.173.29 ; domain mars.imasync.com.

CWP gotcha - vanishing SSH keys: if your keys keep disappearing, that is NOT the attacker, it is CWP's own temp_hacker_check (ships from 0.9.8.1239) deleting keys for users whose home is /root (e.g. operator). Fix:

Code: [Select]

usermod -d /root/operator operator(credit Netino.)

Bottom line: with a root C2 AND an EOL OS I would rebuild on AlmaLinux/Rocky and migrate only scanned data. But if you clean in place: update_cwp x2, kill defunct FIRST, clear the chattr +i keys, purge the base64 injections, rotate everything - and put the panel + webmail behind an SSH tunnel so it can't recur. The full IOC list is in the "very serious security vulnerability in CWP right now" thread.

Good luck.

2

CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

« on: July 09, 2026, 06:41:48 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.

Changing SSH port is imperative IMO.

Definitely don't run on port 22, and even 2222 is not safe from FritzFrog:
https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/

You are right on the dates, and here is the detail that actually proves your point for me: I am on 0.9.8.1244, and my box carries /scripts/temp_hacker_check, which only ships from 1239 onward. So my panel is clearly auto-updating, which means I was patched against both CVE-2025-48703 (fixed 1205) and CVE-2026-57517 (fixed 1225) well before my June compromise. So neither of those was my entry point. Thanks for pushing on it.

Two quick corrections on the assumptions, though. My SSH runs on a custom port behind a firewall, not open on 22. And the boxes are not EOL CentOS 7: turin is AlmaLinux 8.10 and the others are fresh AlmaLinux and Rocky 9 installs. The "5 years" is how long I have run CWP, not the age of the OS.

To be honest, I do not know my exact entry point, and I am not going to pretend I do. The panel CVEs are ruled out, and the foothold was found too late to prove the vector (the June access logs had already rotated). It was likely something the panel does not patch, or an earlier window before I was current. The one lead I am still looking at is my own Roundcube, which was on an old version and exposed on 2095/2096, and which the panel updater does not keep current (even the version it ships is still behind on CVE-2025-49113). I have closed those ports either way. But that is a hypothesis, not a proven entry.

What I can say for certain is that being current on the panel did not protect me, and the backdoor that got planted survived everything. It is a gsocket reverse shell running as a systemd service disguised as a kernel thread, and CWP's own cleanup never removes it.

That cleanup is the tell. CWP shipped temp_hacker_check to the whole fleet in 1239. There is no CVE for it, because it is not a patch, it is an eviction script: it strips the IPCsi58x attacker key, null routes gsocket[.]io in /etc/hosts, and locks the operator account. You do not push that to every server unless you already know a lot of patched boxes are still carrying the backdoor. Patching closes the door. It does not evict someone already inside.

So I am dropping the claim that a CVE was my way in, you were right about that. I am not replacing it with another guess dressed up as fact. What holds is the persistence, the IOCs, and the detector, and the plain fact that a patched box is not a clean box. I have corrected the linked writeup accordingly.

3

CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

« 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.

4

CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

« 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.

5

CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

« 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

6

CentOS-WebPanel Bugs / CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

« 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):

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 -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