I think there is a very serious security vulnerability in CWP right now.

[Logician]

I think I found another issue with the security problem:

awk -F: '{print $1 ":" $7}' /etc/passwd

root:/bin/bash
bin:/bin/bash
daemon:/bin/bash
adm:/bin/bash
lp:/bin/bash
sync:/bin/sync
shutdown:/sbin/shutdown
halt:/sbin/halt
mail:/bin/bash
operator:/sbin/nologin
games:/bin/bash
ftp:/bin/bash
nobody:/bin/bash
systemd-network:/bin/bash
dbus:/bin/bash
polkitd:/bin/bash
sshd:/bin/bash
postfix:/bin/bash
chrony:/bin/bash
mysql:/sbin/nologin
saslauth:/bin/bash
dovecot:/bin/bash
dovenull:/bin/bash
tss:/bin/bash
named:/bin/bash
cwpsrv:/bin/bash
cwpsvc:/bin/bash
clamupdate:/bin/bash
amavis:/bin/bash
clamscan:/bin/bash
vmail:/bin/bash
vacation:/bin/bash
opendkim:/bin/bash
rpc:/bin/bash
firebird:/bin/nologin
ldap:/bin/bash
redis:/bin/bash
tcpdump:/bin/bash

I don't know if this was default configuration but it might be the attacker who set all these services to /bin/bash so I did this:

for user in bin daemon adm lp mail games ftp nobody systemd-network dbus polkitd sshd chrony saslauth tss rpc tcpdump; do
    usermod -s /sbin/nologin "$user"
done

[overseer]

FYI, the named default shell assignment is /bin/false.

All of my users don't have shell access, so they too are /sbin/nologin. root, sync, shutdown, halt, and apache are some of the few that have a valid shell assignment. Even cbpolicyd has the /sbin/nologin shell assignment.

[overseer]

- Creates users. Random letters or something similar, such as __user, user__, login, imunify. Check—there is a .ssh directory inside.

Just to clear up for the record, the user "login" is a legitimate CWP-created user -- it is created with the package "cwpphp". If you delete the user and re-install the cwpphp package, it will recreate the "login" user.

[overseer]

Code Select Expand


check /home dir if this dirs exists: (login chromeuser) delete:
sudo chattr -R -i /home/login
sudo chattr -R -i /home/chromeuser
rm -rf /home/login
rm -rf /home/chromeuser


Note that the "login" user is a legitimate CWP user created by the "cwpphp" package. The default user home is /home/login but doesn't exist by default. Shell assignment is /sbin/nologin. So yes, do check if something is trojaning files in /home/login, but don't delete the "login" user. If you delete the login user, you could open yourself up to 502 Gateway errors with Roundcube or other CWP services.

[Freespirits_GR_Host]

Unauthorized keys across accounts and suspicious files like defauit.php should be treated as signs of a possible compromise, but they don't by themselves identify a CWP vulnerability or the entry point. Preserve relevant logs and file metadata before changing anything, and don't execute the suspicious files.

Check the unexpected keys' fingerprints and owners, then compare them with SSH login activity. Review the files' contents, timestamps, ownership, and locations, and correlate those times with authentication and web-server logs. Unexpected successful logins or file changes may help narrow down how access was gained. Rotate credentials that may be exposed from a trusted device, and involve your host or CWP support if compromise appears ongoing.

I maintain CWP7 Security Audit Module, which helps organize evidence-based checks of SSH keys, persistence, listening ports, and other indicators.

Do you know when the keys and files first appeared, or whether the logs show successful logins around that time?