[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.