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

@mrgreen Thank you for this valuable feedback and GitHub link!

On our end, since Maldet's signature is from February and Rkhunter is discontinued since 2018, we actually ran Thor Lite w/ a collection of YARA custom rules to find and clean everything across the server.

Besides that, we blocked access to "module=filemanager&acc=findFiles" through CloudFlare only allowing our Whitelist of IPs to access it.

Would you be so kind as to share the inotify script for the .php files?

My Approach to Stopping the CWP File‑Manager Exploit

• 1. Scan & Identify Malware
      • Searched for obfuscated PHP payloads 
     

Code: [Select]

    grep -rniE "(eval\s*\(|base64_decode|gzinflate|str_rot13|shell_exec|proc_open|passthru|system)" \
        /home/*/public_html/
   
    • Caught the classic pair in every account:
      nbpafebaef.jpg  (PHP in disguise) 
      defauit.php     (web‑shell)

    • Found tmp propagators reported in the forum thread: 
      /tmp/.auto_monitor and /tmp/.tmp_baf[/li]

[li]2. Clean & Quarantine
   

Code: [Select]

    mkdir /root/quarantine
    mv /home/*/public_html/{nbpafebaef.jpg,defauit.php} /root/quarantine 2>/dev/null
    mv /tmp/.auto_monitor /tmp/.tmp_baf /root/quarantine
        • Manually opened every recently‑modified functions.php; all were clean, so no theme replacement required.[/li]

[li]3. Global Block via ModSecurity (NOT .htaccess)
    Added to /usr/local/apache/modsecurity-cwaf/custom_user.conf:
   

Code: [Select]

# Put your custom ModSecurity directives here
# Please don't remove this file
# Block CWP filemanager exploit attempts (CVE-2025-48703)
SecRule REQUEST_URI "@contains /user/index.php" \
    "id:4870301,phase:2,deny,status:403,log,msg:'[CWP Exploit Block] Block access to module=filemanager&acc=findFiles',\
    chain"
    SecRule ARGS:module "@streq filemanager" \
        "chain"
        SecRule ARGS:acc "@streq findFiles"

        Restart Apache:
   

Code: [Select]

systemctl restart httpd[/li]

[li]4. Verification (cURL)
   

Code: [Select]

    curl -X POST "https://your-domain.com/user/index.php?module=filemanager&acc=findFiles" \
         -A "Mozilla" -I
    # Expected: HTTP/1.1 403 Forbidden
   

403 confirms ModSecurity now blocks the exploit endpoint for every vHost.[/li]

Result: Infection removed, endpoint sealed, and logfile shows only blocked attempts. 
Hope this helps anyone still cleaning up from the same CVE!

I saw that a new version was released 0.9.8.1207, did this update fix the filemanager exploit?

CWP team is doing a really bad job, no official reply no information, completely unreal.

I saw that a new version was released 0.9.8.1207, did this update fix the filemanager exploit?

CWP team is doing a really bad job, no official reply no information, completely unreal.

Sure would be nice to know.

Can someone test the latest version to see if the exploit still works?

just checked it, fixed. can someone also please validate the same.

just checked it, fixed. can someone also please validate the same.

I checked on my server. IT fixed on version 1207

I just saw I was affected by this issue. The php file was in each of my /home/ directories public_html folder.  The modified date for the file was July 6 but my CWPpro version is currently 0.9.8.1207. Is there a way to find out exactly when this version was released?

🛡️ REAL-TIME MALWARE PROTECTION FOR CWP/CENTOS – Auto-remove defauit.php & nbpafebaef.jpg

This guide helps you automatically detect and remove dangerous PHP backdoors named:

- defauit.php (typo: not default)
- nbpafebaef.jpg (a disguised PHP file)

These are known malware injected in CWP-based servers. We will:
- Quarantine existing files
- Monitor /home in real-time
- Auto-remove any newly created malicious files

Works on CentOS / AlmaLinux / CloudLinux using systemd + inotify.

---

✅ STEP 1 – Install inotify-tools

Code: [Select]

yum install -y inotify-tools

---

✅ STEP 2 – Create the watcher script

Code: [Select]

nano /usr/local/bin/watch_defauit.sh

Paste this content:

Code: [Select]

#!/bin/bash

WATCH_DIR="/home"
LOGFILE="/var/log/defauit_watch.log"
QUARANTENA="/root/quarantena_php"
mkdir -p "$QUARANTENA"

echo "### START $(date) - Initial scan" >> "$LOGFILE"

# PHASE 1 – Find and move existing malicious files
find "$WATCH_DIR" -type f \( -name "defauit.php" -o -name "nbpafebaef.jpg" \) | while read FILE; do
  echo "[!] FOUND EXISTING: $FILE → Moved to quarantine" | tee -a "$LOGFILE"
  mv "$FILE" "$QUARANTENA/" 2>/dev/null
done

# PHASE 2 – Live monitoring
inotifywait -mr -e create -e moved_to --format '%w%f' "$WATCH_DIR" | while read FILE; do
  BASENAME=$(basename "$FILE")
  if [[ "$BASENAME" == "defauit.php" || "$BASENAME" == "nbpafebaef.jpg" ]]; then
    echo "[!] NEW FILE DETECTED: $FILE → Moved to quarantine" | tee -a "$LOGFILE"
    mv "$FILE" "$QUARANTENA/" 2>/dev/null
  fi
done

Make it executable:

Code: [Select]

chmod +x /usr/local/bin/watch_defauit.sh

---

✅ STEP 3 – Create the systemd service

Code: [Select]

nano /etc/systemd/system/watch-defauit.service

Paste this config:

Code: [Select]

[Unit]
Description=Live watch for defauit.php & nbpafebaef.jpg
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/watch_defauit.sh
Restart=always
RestartSec=5
User=root

[Install]
WantedBy=multi-user.target

Enable and start the service:

Code: [Select]

systemctl daemon-reexec
systemctl daemon-reload
systemctl enable --now watch-defauit.service

---

✅ STEP 4 – Increase inotify watch limit (if needed)

If you get "upper limit on inotify watches reached" error:

Code: [Select]

echo fs.inotify.max_user_watches=524288 >> /etc/sysctl.conf
sysctl -p

---

✅ RESULT

- All existing and new files named defauit.php or nbpafebaef.jpg under /home will be moved to:
  /root/quarantena_php/

- A log of all detections is saved in:
  /var/log/defauit_watch.log

---

Stay safe!

In the server-world, blindly following advice & installing scripts from people with a total of ONE post on this forum is the equivalent of taking candy from strangers.

If you keep your server updated, this was fixed 2 weeks ago by the CWP dev team. And by now if the perpetrators have any sense, the IOC has changed and it won't do any good to look for files named those strings.

I also see this file in atleast one of my sites.

Now what is the proper solution to fix this?

I have AL 8 with latest CWP

Are you running malware detection scans on your system?

ClamAV Maldet Scan do not detect these 2 files

I am running 3 VPS with AL8

All 3 are affected.

Have manually removed these files
Have the latest CWP

Anthing else to be done? Please suggest

See @overseer Reply #39

As long as your AL is up2date run:

Code: [Select]

dnf --refresh updateand you are running 0.9.8.1210 you should be fine.

But also having a secure PHP helps, by default CWP leaves nothing disabled so users can configure their server as they need.

ModSecurity has also been catching this, which again, needs to be kept updated.

I have 3 servers running Alma 8 with CWP Pro updated as of today. I install updates every day as they are released.
In addition to all CWP security features being active, I use Fail2ban, but clearly nothing stopped the malware injection, since an exploit in the file manager was used.

On some sites, I found both files (defauit.php and the .jpg), and in the /home directories where there were no hosted files, only defauit.php was present. I manually deleted the files from each home directory one by one, then searched across all servers for any remaining ones using this command, and double-checked by reviewing the logs — keeping in mind that if an account has subdomains, it's also necessary to search and delete defauit.php and the .jpg from those folders too.

COMMON DATA:
The Attacker’s IP
Initial Date: July 4th

grep "defauit.php" /usr/local/apache/logs/access_log*

and it will show us ::

198.144.182.13 - - [06/Jul/2025:12:27:39 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:12:50:56 -0300] "GET /defauit.php?id=1 HTTP/1.0" 200 1
198.144.182.13 - - [06/Jul/2025:12:50:56 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:13:00:05 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:14:36:03 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:15:59:39 -0300] "POST /defauit.php?id=1 HTTP/1.0" 301 255

I didn't find the files .auto_monitor and/or .tmp_baf on any server

find /home/*/tmp -type f -name ".auto_monitor" 2>/dev/null

find /home/*/tmp -type f -name ".auto_monitor" -exec ls -l {} \; 2>/dev/nul

As an additional measure, I added the source IP (198.144.182.13) to the blocked IPs in CSF, since I see it's the same for all cases. I also inserted the mentioned rule in ModSecurity, correcting the last line (the \ was missing)

/usr/local/apache/modsecurity-cwaf/custom_user.conf:
# Block CWP filemanager exploit attempts (CVE-2025-48703)
SecRule REQUEST_URI "@contains /user/index.php" \
    "id:4870301,phase:2,deny,status:403,log,msg:'[CWP Exploit Block] Block access to module=filemanager&acc=findFiles',chain"
    SecRule ARGS:module "@streq filemanager" \
        "chain"
        SecRule ARGS:acc "@streq findFiles" \

I also made sure everything was up to date using dnf --refresh update.

Remember to check the subdomains and make sure this doesn't happen again!