[CRITICAL] Multiple CWP Servers Infected – Arbitrary PHP Code Execution via Publ

This is NOT a CWP bug.

PHP Injection Attacks will happen whenever.

You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4

You'll also need to configured the OWASP base rules for services you run on that server.

NOTE: The CWAF ruleset is dead, and the last update was over a year ago.
Which is sad, this was a great ruleset.

For the PHP Injection Attack that has been going around, there has been fixes here how to clean up your PHP-FPM.

Same problem here, someone fixed it?

You can Google the fix, it's a standard PHP Injection Attack due to an insure PHP configuration.
It also only affects people still using the EOL CentOS 7 OS.

But I think someone posted the fix here in one of the threads as well.

🛑 What I Found

On my server, inside /home/username/public_html/public/ and /home/username/public_html/, I found two suspicious files:
   •   nbpafebaef.jpg – Contains PHP code despite the .jpg extension:
<?php echo md5("gewafwaef1");die;?>

   •   defauit.php – A PHP script with a misleading name (looks like “default.php”).

i also found these two files in my public_html folder, what should i do with them should i deleted them both? how to make sure there is no other similar exploit?

Starburst already gave the answer above:

You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4

And he has guides for updating ModSecurity and the OWASP CRS ruleset (tested on both AlmaLinux 8 and 9):
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-12-running-cwp-and-apache-on-almalinux-9/
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-owasp-crs-ruleset-running-cwp-and-apache-on-almalinux-9/

i understand that is for the future prevention but what to do with the current infection . should i delete the below two file manually from all sites public_html directories ?

defauit.php
nbpafebaef.jpg

Oh for sure -- I thought you had already done that as a first step. They are likely what gives the attacker persistence on your server.

Since I don't need the user panel, I removed ports 2082 and 2083 from the firewall configuration file. This prevents access to the user panel.

To do this: log in to the admin panel, go to Firewall, and configure the "Opened TCP/UDP Ports". This will open the configuration file in edit mode. Remove ports 2082 and 2083 (you can find them under "Allow outgoing TCP ports" and "Allow incoming TCP ports") and then restart the firewall.

You will still be able to access the user panel if you need to perform actions that cannot be done through the admin panel, because when you log in as an admin in the admin panel, your IP is unrestricted by the firewall. Other users will experience connection timeouts.

I also recommend changing your users’ passwords, as the generated passwords are quite weak. Why the concern?
I discovered that long time ago I had created a username incorrectly by swapping two characters, then deleted it and created another one. Later, I removed that second user as well since it was not needed. Although these users are removed and non-operational, they still appear in the system, specifically in the "/etc/shells" file.
After checking the access logs, I saw that these two users had been exploited by the attacker. So I assume the attacker was able to read many files including "/etc/shells".
For testing, I logged in as a non-sudo user and confirmed that I could access and modify content in many parts of the server. So by the SSH access, you are not restricted only to the /home folder, you can explore almost all directories and content of the server. So It is also possible to extract password hashes for cracking. Or maybe your server can be ordered to brute force passwords and send it to the attacker.

Additionally, last night I turned off my httpd service, but by the morning it was running again. It was restarted at 4 AM. I am not sure what caused it to turn back on, but this behavior looks weird.

I do not intend to use my server for shared hosting, so I am not particularly concerned. However, granting this kind of shell access to regular users does not seem appropriate.