Recent Posts

21

CentOS 9 Problems / User Panel login at 2083 error 'Failed'

« Last post by Anthony@fixingit on September 01, 2026, 12:52:10 AM »

You may have already found this fix but, it has taken me a few years to figure it out so, I thought I would share. Yes, I didn't do alone. Grok actually helped me get there.

Highest-probability fix for CentOS Stream / Alma / Rocky 9
Run these exact commands:

Code: [Select]

# 1. Comment out the SHA rounds limit
sed -i 's/^SHA_CRYPT_MAX_ROUNDS/#SHA_CRYPT_MAX_ROUNDS/' /etc/login.defs

# Verify it is commented
grep SHA_CRYPT /etc/login.defsYou should now see a line starting with #SHA_CRYPT_MAX_ROUNDS.

Then reset every user’s password from the CWP admin panel (User Accounts → edit each account → set a new password → Save).

Just changing the password in the panel is required after the /etc/login.defs change — the old hashes are incompatible.
After resetting passwords, try logging into a user panel again on port 2083.

Here’s exactly what those two commands did and why they fixed the user-panel logins on CentOS Stream 9.
1. The problem on EL9 (CentOS Stream 9 / AlmaLinux 9 / Rocky 9)
Modern RHEL-based systems (EL9) ship with a high value for password hashing rounds in /etc/login.defs:
BashSHA_CRYPT_MAX_ROUNDS 100000
This tells the system to use a very large number of rounds when creating SHA-512 password hashes (the format used by passwd, chpasswd, and CWP when it sets a user’s password).
CWP’s user-panel authentication code was written (and compiled) against the older, lower-round hashing behaviour that was standard on CentOS 7 / EL8. When the number of rounds is extremely high:

The password hash that CWP stores (or expects) no longer matches the hash the system generates.
Admin-panel login still works because it uses a different authentication path (root credentials / different code).
Every normal user account fails with a generic “Failed” message.

2. What the commands actually did
Bashsed -i 's/^SHA_CRYPT_MAX_ROUNDS/#SHA_CRYPT_MAX_ROUNDS/' /etc/login.defs

sed -i = edit the file in place.
s/^SHA_CRYPT_MAX_ROUNDS/#SHA_CRYPT_MAX_ROUNDS/ = find any line that starts with SHA_CRYPT_MAX_ROUNDS and put a # in front of it.
Result: the line becomes a comment:Bash#SHA_CRYPT_MAX_ROUNDS 100000

Once the line is commented out, the system falls back to the default (much lower) number of rounds that CWP expects.
Bashgrep SHA_CRYPT /etc/login.defs
This simply showed you the current state so you could confirm the line was now commented.
3. Why you still had to reset the passwords
Existing password hashes in /etc/shadow (and in CWP’s internal records) were already created with the high-round setting. Changing /etc/login.defs only affects new hashes.
When you went into the CWP admin panel and set a new password for each user, CWP re-hashed the password using the now-correct (lower-round) method. After that, the user-panel login code could verify the password successfully.

Summary

You disabled the overly aggressive SHA-512 rounds that EL9 enables by default. That made the password hashes CWP creates compatible with the authentication logic used by the user panel on port 2083.
This is a well-known workaround on all EL9-based CWP installations. The permanent long-term fix would be for CWP to update its password-handling code to support the higher round counts, but the /etc/login.defs change is the standard and reliable solution for now.

22

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by adrianofnatal on August 31, 2026, 03:00:05 PM »

After long time researching and testing, confirmed that server was a processe called "-cpanel" that connects to IP 152.53.173.29.
That files mentioned earlier in this thread was found in home directories with root permissions. All deleted.
IP was blocked and connections was closed.
Server infected, probably some was not updated. It's a Centos 8 Stream.
Will be reinstalled.

This problem was caused due a Centos without updates, but, CWP needs to be fixed too due a vulnerabilities mentioned by Netino.

Just posting here cause someone facing same problem.

Thanks!

23

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by adrianofnatal on August 31, 2026, 12:31:26 PM »

(...)

Same issue here, with Iang.php and ur1.php files.

What's the fix for these attacks? Just delete files?
Was not clear if this was created using FileManager vulnerability. Is this correct?

Various sites affected here.
Backups was disabled too, withoout any command.
Some Nodejs apps was down too, no reason.

Distro is Centos 8 Stream.


Thanks!

The issue lay with the file manager. The attacker used the DELETE method to send a request containing a long string, appended a semicolon (";"), and executed a series of commands with root privileges. I was able to confirm—based on the attack timestamp, the timestamps of the injected files, and log entries the attacker failed to delete—that this was the method used.

Therefore, you should restrict the DELETE method by adding the following configuration to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, placing it between the `server {` and `location / {` directives:

Code: [Select]

# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
        return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}

Additionally, you should disable the file manager:

Code: [Select]

mv /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php{,.disabled}

The attacker exploited the file manager to gain root access to the server using a standard user account. Consequently, you should also remove the following configuration block wherever it appears:

Code: [Select]

location ~ ^/~(.+?)(/.*)?$ {
        internal;
        proxy_pass http://IP.AD.DR.ESS:8181;
        include proxy.inc;
}

However, there is no guarantee that it did not access your information and collect any sensitive or confidential data from your server. You should take measures to mitigate the impact of the server data compromise, should such an event have occurred.

Regards,
Netino

Thanks! I'll block.

The attack happened again. I got a process running called "-cpanel" conecting to ip 152.53.173.29, from Germany.

Cannot confirm if it comes from filemanager.

Thanks!

24

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by Netino on August 31, 2026, 03:25:01 AM »

(...)

Same issue here, with Iang.php and ur1.php files.

What's the fix for these attacks? Just delete files?
Was not clear if this was created using FileManager vulnerability. Is this correct?

Various sites affected here.
Backups was disabled too, withoout any command.
Some Nodejs apps was down too, no reason.

Distro is Centos 8 Stream.


Thanks!

The issue lay with the file manager. The attacker used the DELETE method to send a request containing a long string, appended a semicolon (";"), and executed a series of commands with root privileges. I was able to confirm—based on the attack timestamp, the timestamps of the injected files, and log entries the attacker failed to delete—that this was the method used.

Therefore, you should restrict the DELETE method by adding the following configuration to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, placing it between the `server {` and `location / {` directives:

Code: [Select]

# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
        return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}

Additionally, you should disable the file manager:

Code: [Select]

mv /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php{,.disabled}

The attacker exploited the file manager to gain root access to the server using a standard user account. Consequently, you should also remove the following configuration block wherever it appears:

Code: [Select]

location ~ ^/~(.+?)(/.*)?$ {
        internal;
        proxy_pass http://IP.AD.DR.ESS:8181;
        include proxy.inc;
}

However, there is no guarantee that it did not access your information and collect any sensitive or confidential data from your server. You should take measures to mitigate the impact of the server data compromise, should such an event have occurred.

Regards,
Netino

25

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by murad99 on August 30, 2026, 11:08:44 PM »

For a while, I’m going to check the `/home` directory daily for files modified within the last 24 hours. Since my server has relatively few users but receives a high number of attacks, I’m more likely to notice suspicious activity. If I find anything suspicious, I’ll share it here.

This is the command I’m using:

Code: [Select]

find /home -type f -cmin -1440
-printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' 2>/dev/null |
grep -v 'sess_' |
sort -r

26

Backup / Re: Backup Manager Beta is not remembering password in destination

« Last post by xenios on August 30, 2026, 08:52:00 PM »

With every update, something breaks.

27

Backup / Re: Backup Manager Beta is not remembering password in destination

« Last post by adrianofnatal on August 30, 2026, 06:55:17 PM »

Same here.

Scheduled backups does not work.
Manual backup work.

There are recurrent problems with backup these last updates.

28

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by adrianofnatal on August 30, 2026, 04:00:29 PM »

Very strange behaviour here.

Found a directory inside user's home in wordpress site with root permission

drwxr-xr-x  4 root     root     4096 Aug 30 12:59 .conf

Where did come from?

29

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by emerysteele on August 30, 2026, 02:46:00 PM »

Cleanup:

Code: [Select]

rm -f  /home/*/public_html/test123zz
rm -f /home/*/public_html/cwp_login_*.php

No test123zz file for me, but I did have a few cwp_login_ files. They were on a wordpress site, that I also found a wp2shell file 'wp-content/plugins/fm-rxadmy.php' from Jul 28th. Ended up just restoring this site from an early backup, instantly updating & rotating creds.


It won't let me put the full code, but the top of the file starts with this:

Code: [Select]

<?php
/**
 * AIOWPM Shell Deployer v2 Ã¢Â€Â” auto WAF-variant detect
 * wrapped payload, random creds, emit-mode self-test
 */
@error_reporting(0);
@ini_set("display_errors",0);
@set_time_limit(0);

$pass_file = __DIR__ . "/.lil_tmp2";
if (file_exists($pass_file)) {
    $st = json_decode(file_get_contents($pass_file), true);
} else {
    $st = array(
        "pass" => substr(str_shuffle("abcdefghijklmnopqrstuvwxyz0123456789"), 0, 12),
        "name" => "wp-obj-" . substr(str_shuffle("abcdefghijklmnopqrstuvwxyz"), 0, 6) . ".php",
        "ax"   => substr(str_shuffle("abcdefghijklmnopqrstuvwxyz0123456789"), 0, 20),
        "emit" => "",
    );
    @file_put_contents($pass_file, json_encode($st));
}
It uses gzinflate to decompress a base64 blob. I would double check for these kinds of files with

Code: [Select]

grep -r "gzinflate(base64_decode" /home/*/public_html/Legit files could potentially use this function, so double check the contents, especially files modified recently.

I am on AlmaLinux 8. But I found out my kernel wasn't running the updated version :/ It was getting updated & installed via YUM/DNF, but the boot/uefi partitions weren't getting mounted properly, so they were not updating in the right spot for it to be run on boot.

Code: [Select]

uname -r
ls -1 /boot/vmlinuz*to double check your running kernel version is the latest one you've downloaded.

30

Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection

« Last post by adrianofnatal on August 30, 2026, 12:52:47 PM »

I discovered another file.
And the method used.

The file `

Code: [Select]

/usr/local/cwpsrv/var/services/users/login/conf/Iang.php` was created on the same date as `ico.php`.

* Anatomy of the attack

The method used was this one, detected by ModSecurity (I protect my `cwpsrv` with ModSecurity), whose logs modsec_audit.log the attacker forgot to delete:

---vsWUH37C---A--
[15/Nov/2025:08:06:12 -0300] 176320477298.529591 127.0.0.1 42932 127.0.0.1 2083
---vsWUH37C---B--
[very long string, unfortunately forum is not allowing to post]

---vRkASqMp---H--

---vRkASqMp---I--

---vRkASqMp---J--

---vRkASqMp---Z--



He deleted all the other logs.

File data:

Code: [Select]

# stat ico.php
    Arquivo: ico.php
    Tamanho: 1477      Blocos: 8          bloco de E/S: 4096   arquivo comum
Dispositivo: fd01h/64769d Inode: 2892154     Links: 1
     Acesso: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
     Acesso: 2026-08-27 10:18:13.727189654 -0300
Modificação: 2025-11-28 06:17:52.883868313 -0300
  Alteração: 2026-08-24 21:59:57.435060346 -0300
    Criação: 2025-11-15 08:06:12.856741480 -0300

# stat Iang.php
    Arquivo: Iang.php
    Tamanho: 1891      Blocos: 8          bloco de E/S: 4096   arquivo comum
Dispositivo: fd01h/64769d Inode: 3019261     Links: 1
     Acesso: (0644/-rw-r--r--)  Uid: (  971/  cwpsvc)   Gid: (  970/  cwpsvc)
     Acesso: 2026-08-27 20:53:36.488199001 -0300
Modificação: 2025-11-15 08:06:14.962752159 -0300
  Alteração: 2026-08-27 20:51:53.481791997 -0300
    Criação: 2025-11-15 08:06:12.432739330 -0300

If you are familiar with ModSecurity, you can use the HTTP data above to create a rule and protect your server.
ModSecurity was active, but the DELETE method was used; the attacker appended a ";" to the command and added further commands for execution.

* Why is the use of the DELETE method a crucial detail?

Firewall (WAF) Rule Bypass: Most administrators and default WAF/ModSecurity rules strictly monitor POST and GET requests, as these are the most common methods for sending data and commands. DELETE requests targeting public files often slip through without deep content inspection.

Exploiting Application Logic: The CWP script targeted in the attack (`/contsist/index.php?module=filemanager&acc=emptyTrash`) was originally designed to delete files (empty the trash). Consequently, the panel's API likely required or natively accepted the HTTP DELETE method for this specific function. The attacker exploited this legitimate permission to inject the `;` character into the URL and append the Linux commands that created the malicious file.

* Steps you can take:

Although the `filemanager` module appears to have been used, you should immediately restrict the methods allowed by Nginx and `cwpsrv`:
Add the following to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, inside the `server {` directive and before the `location / {` block:

Code: [Select]

# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
    return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}

If you discover the presence of any of the files mentioned above, you should run a scan using the following command:

Code: [Select]

# maldet -a /usr/local/cwpsrv/htdocs/admin/

Critic:
To use the filemanager module, it was necessary to know the username.

But he managed to use the username because it's extremely simple to find the username in CWP: Just use http://IP.AD.DR.ESS/~username
Just associate it with the user's domain name, and the damage is done.

This feature needs to be disabled immediately in CWP.

There are other possible ways to test a website before it's published, and this is the worst method.

Once you have the username, all that's missing is the password to break the login of any active service on your server.

In my opinion, you should remove or comment out this section of the file /etc/nginx/conf.d/IP.AD.DR.ESS.conf

Code: [Select]

location ~ ^/~(.+?)(/.*)?$ {
    internal;
    proxy_pass http://IP.AD.DR.ESS:8181;
    include proxy.inc;
}
If you don't use the proxy, you should remove it anyway.

I discovered today that in nginx, using alias in a prefixed location that doesn't end with directory separator could lead to path traversal vulnerability.
Additional info: https://gixy.getpagespeed.com/checks/alias-traversal/
The alias directive is used to replace path of the specified location. For example, with the following configuration:

location /i/ {
    alias /data/w3/images/;
}
On request of /i/top.gif, the file /data/w3/images/top.gif will be sent.
But if the location doesn't end with directory separator (i.e. /):

location /i {
    alias /data/w3/images/;
}
On request of /i../app/config.py, the file /data/w3/app/config.py will be sent.
In other words, the incorrect alias configuration could allow an attacker to read files stored outside the target folder.

There are more things that can be done, but for now I need to focus on fixing my server and exploring other possibilities.

Same issue here, with Iang.php and ur1.php files.

What's the fix for these attacks? Just delete files?
Was not clear if this was created using FileManager vulnerability. Is this correct?

Various sites affected here.
Backups was disabled too, withoout any command.
Some Nodejs apps was down too, no reason.

Distro is Centos 8 Stream.


Thanks!