Recent Posts
31
PHP / Re: CWP system PHP 8.3.36 UPDATE (CVE)
« Last post by prakash7610 on October 25, 2026, 05:02:02 PM »https://www.alphagnu.com/topic/633-standalone-cwp-php-cli-build-manager-build-php-7485-php-fpm-selector-switcher-and-pie-extensions/
i used AlphaGnu ,method for update php version is far better than cwp inbuilt selector or switcher they are still have bugs once the automatic update is enabled cwp will start the update but the problem is pcre failure so php will not start will givea fatal error
so install the alphagnu and select the autoupdate disabled in cwp php selector for both cli and fpm
i used AlphaGnu ,method for update php version is far better than cwp inbuilt selector or switcher they are still have bugs once the automatic update is enabled cwp will start the update but the problem is pcre failure so php will not start will givea fatal error
so install the alphagnu and select the autoupdate disabled in cwp php selector for both cli and fpm
32
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by Gani Karaoğlu on October 25, 2026, 04:17:15 PM »Fileless XMRig Miner on CWP Detection, Cleanup, and Prevention Guide
Selam. AlmaLinux 8 + CWP çalışan sunucumda bu kampanyadan ben de nasibimi aldım; paylaşayım dedim, gördüğüm kadarıyla aynı dertten muzdarip çok kişi var. Kısaca olay: diskte dosyası bile olmayan, root yetkisiyle çalışan bir XMRig (Monero) madencisi. Kendini çekirdek thread'i ve sahte systemd servisleri gibi gösterdiği için haftalarca gözüme çarpmadı. İşin iyi tarafı, CSF'de giden portları kısıtlı tuttuğum için madenci havuzuna hiç bağlanamamış; yani adam benden tek kuruş kazanamadı
Aşağıya nasıl fark ettiğimi, nasıl temizlediğimi ve neler önerdiğimi yazdım.
Bu ne, nasıl çalışıyor ?
Yakaladığım şey XMRig'di; config.json'ındaki RandomX algoritmasından Monero kazdığı belli. Bunu aylarca görememimin üç sebebi vardı:
Diskte dosyası yok. memfd denen bellek içi bir dosyadan çalışıyor, yani ls ile göremezsin, ClamAV/maldet gibi imza tarayıcıları bulamaz, rpm -V bile temiz der.
Ayrı bir network namespace (netns) içinde çalışıyor. Bu yüzden normal ss/netstat çıktısında bağlantısı görünmüyor.
Süreç listesinde kendini [kworker/...], [netns], [kaluad] gibi çekirdek thread'i sanacağın isimlerle gizliyor. Kalıcılık için de sistem servisi gibi duran sahte systemd birimleri açıyor.
En kötüsü: bu şey root (UID 0) olarak çalışıyor. Yani olay tek bir sitenin hacklenmesi değil, sunucu çekirdek seviyesinde ele geçiriliyor. Madenci sürekli havuzuna bağlanmaya çalışıyordu ama güvenlik duvarı giden bağlantıyı kestiği için başaramamış.
Neye bakın (IOC'ler) ?
Şu IOC'ler benim olayımdan. Ama bunlar isim/IP'yi sık değiştiriyor, o yüzden adları birebir aramak yerine kalıba bakın: sistem servisi gibi duran sahte isimler, port 3333, root'tan dışarı giden ama engellenen bağlantılar.
Tür - Değer / Belirti
Madencilik havuzu 146.103.45.130:3333 (Singapur)
C2 sunucusu 212.132.98.170
Giden port 3333/tcp (stratum)
Sahte systemd servisleri dbus-monitor-srv, systemd-logind-helpers, polkitd-helpers, auth-policykit, defunct
Sahte ikili dosyalar /usr/bin/dbus-monitor-srv, /usr/bin/polkitd-helpers, /usr/bin/config.json, /usr/sbin/netd, /usr/sbin/authd, /usr/sbin/udevd-sync, /usr/lib/systemd/system/defunct.dat
Süreç listesinde [kworker/...], [netns], [kaluad] gibi, ebeveyni PID 2 (kthreadd) olmayan sahte çekirdek thread'leri
En net belirti CSF loglarında port 3333'e giden on binlerce *TCP_OUT Blocked* kaydı, UID=0
Web shell dosyaları test123zz, 404.php, cwp_login_********.php (müşteri public_html içinde)
Ek sahte ikili /usr/sbin/bootcfg
Ek sahte thread'ler [kstrp], [card0-crtc8]
İndirme / kalıcılık kaynakları raw.githubusercontent.com (Kyy-Shell), gs.thc.org, memek.cc
Exfiltrasyon host 184.107.106.86
Şüpheli giriş portu 2304 (CWP External API)
Tablonun alt yarısı kampanyanın web shell + GSocket ayağına ait. Bir kısmını kendi sunucumda gördüm, bir kısmı da aynı kampanyadan muzdarip başkalarının paylaştığı; birebir hepsi sizde olmayabilir.
Nasıl bulursunuz ?
Sizde de benzer şeyler varsa, şu kontroller madenciyi ortaya döker. Hepsi salt-okunur, bir şeyi bozmaz, gönül rahatlığıyla çalıştırın.
1. Giden bağlantı loglarına bak (en hızlı yol). Tek bir porta ve tek IP'ye, UID=0'dan giden büyük sayı madenci beacon'ıdır:
grep -h 'TCP_OUT Blocked' /var/log/messages* | grep -oE 'DPT=[0-9]+' | sort | uniq -c | sort -rn | head
2. Silinmiş veya memfd ikilisinden çalışan süreçler (fileless madencinin en belirgin izi):
ls -l /proc/*/exe 2>/dev/null | grep -iE 'deleted|memfd'
3. Sahte çekirdek thread'leri (adı köşeli parantezli ama ebeveyni PID 2 / kthreadd değil):
ps -eo pid,ppid,user,cmd --no-headers | awk '$4 ~ /^\[/ && $2 != 2 && $1 != 2'
4. Çalıştırılabilir dosyası pakete ait olmayan systemd servisleri:
for f in /etc/systemd/system/*.service /usr/lib/systemd/system/*.service; do b=$(grep -m1 -oP '^ExecStart=[-@+!]*\K\S+' "$f" 2>/dev/null); [ -n "$b" ] && [ -e "$b" ] && ! rpm -qf "$b" >/dev/null 2>&1 && echo "$f -> $b"; done
5. Yüksek CPU ve anlık dış bağlantılar (madenci CPU'yu kemirir):
ps -eo pid,user,pcpu,etimes,comm --sort=-pcpu | head
ss -tnp state established | grep -vE '127.0.0.1|::1'
6. Çekirdek seviyesi arka kapı kontrolü (bu dosya normalde olmamalı):
cat /etc/ld.so.preload 2>/dev/null || echo 'yok - iyi'
Nasıl temizledim ?
Sırası önemli: önce kanıt al, sonra öldür. Tersini yaparsan süreci öldürürsün ama kalıcılık mekanizması beş dakika sonra geri getirir, üstüne izini de kaybedersin. Komutlardaki <PID> yerine kendi bulduğun süreci koy.
1. Dondur ve kanıt al. Süreci SIGSTOP ile dondurup /proc'unu kopyala:
IR=/root/ir-$(date +%F-%H%M); mkdir -p $IR && chmod 700 $IR
kill -STOP <PID>
cp /proc/<PID>/exe $IR/miner.bin; sha256sum $IR/miner.bin | tee $IR/sha256.txt
cat /proc/<PID>/maps > $IR/maps; tr '\0' '\n' < /proc/<PID>/environ > $IR/environ
ss -tunap > $IR/ss.txt; ps auxwwf > $IR/ps.txt
2. Sahte servisleri durdur ve mask'le (reboot'ta geri gelmesinler):
for s in dbus-monitor-srv systemd-logind-helpers polkitd-helpers auth-policykit defunct; do systemctl disable --now $s.service; systemctl mask $s.service; done
3. Süreçleri öldür (önce CONT, sonra KILL):
for p in <PID listesi>; do kill -CONT $p 2>/dev/null; kill -9 $p; done
4. Zararlı dosyaları karantinaya al (silme; kanıt ve hash kalsın):
Q=$IR/quarantine; mkdir -p $Q
for f in /usr/bin/dbus-monitor-srv /usr/bin/polkitd-helpers /usr/bin/config.json /usr/sbin/netd /usr/sbin/authd /usr/sbin/udevd-sync /usr/lib/systemd/system/defunct.dat; do [ -e "$f" ] && mv "$f" $Q/; done
chmod -R 000 $Q
5. Havuz ve C2 IP'lerini engelle:
csf -d 146.103.45.130 "XMRig havuz"
csf -d 212.132.98.170 "C2"
6. Kalıntı kontrolü ve yeniden başlatma. systemctl daemon-reload çalıştır, kalan şüpheli süreç/referans olmadığını doğrula, sonra planlı bir reboot yap. memfd süreçleri yalnızca bellekte yaşar; yeniden başlatma onları kesin temizler ve kalıcılığın gerçekten kaldırılıp kaldırılmadığını geri gelmemesiyle kanıtlar.
Uyarı: Root bir kez ele geçtiyse o makineye artık yüzde yüz güvenemezsin. Temizlik acil tehlikeyi kaldırır ama en sağlıklısı temiz bir sunucuya geçip eskisini kapatmak.
Nereden girmiş ?
Açıkçası nereden girdiğini kesin çıkaramadım (olay haftalara yayılmış, loglar dönmüş). Ama forumda bu işi tartışanların en çok şüphelendiği yer CWP External API, yani port 2304. Bir de olay tek parça değil: önce bir web shell düşüyor (public_html'e test123zz, 404.php, cwp_login_********.php), sonra GSocket tabanlı bir root arka kapısı (defunct, auth-policykit), en son madenci. Giriş kapısı adayları şunlar:
CWP panel açıkları. CWP arayüzü root olarak koşuyor, dolayısıyla buradaki bir RCE direkt root veriyor. Aktif sömürülen, bilinen kritikler:
CVE-2022-44877 (https://thehackernews.com/2023/01/alert-hackers-actively-exploiting.html) Kimlik doğrulaması gerektirmeyen RCE; giriş (login/index.php) parametresine komut enjeksiyonu. CVSS 9.8. Ocak 2023'ten beri yabanda aktif sömürülüyor. Yaklaşık 0.9.8.1147 ile yamalandı kendi sürümünüzü doğrulayın.
CVE-2025-48703 (https://www.helpnetsecurity.com/2025/11/05/control-web-panel-cve-2025-48703-exploited/) filemanager changePerm API'sindeki t_total parametresinde OS komut enjeksiyonu (CWE-78). CVSS 9.0. 0.9.8.1205'ten (Haziran 2025) önceki tüm sürümleri etkiler. Enjeksiyon için kimlik doğrulaması gerekmez; yalnızca geçerli (root olmayan) bir kullanıcı adı gerekir, ki hosting sunucularında bu adlar kolayca tahmin edilir. CISA tarafından 4 Kasım 2025'te aktif sömürülenler listesine eklendi.
CVE-2023-42121 (https://nvd.nist.gov/vuln/detail/CVE-2023-42121) gibi başka CWP RCE'leri de var. Kısacası: CWP'yi her zaman en güncel sürümde tutmak kritik.
CWP External API (port 2304). Forumda herkesin parmak bastığı yer burası. Servis root olarak 0.0.0.0:2304'te dinleyebiliyor; kullanmıyorsan CWP panelinden kapat, kullanıyorsan sadece güvendiğin IP'ye aç, CSF TCP_IN'de de 2304 dışarıya kapalı olsun (zaten varsayılanda listede olmamalı).
PHP / site tarafı. Linux'ta PHP'nin kendisi nadiren direkt giriş kapısı olur (ör. CVE-2024-4577 daha çok Windows/CGI'yi vuruyor). Asıl bela güncellenmemiş WordPress ve eklentiler: oradan bir PHP web shell düşüyor, adam önce site kullanıcısı olarak kod çalıştırıyor, sonra yerel bir açıkla root'a tırmanıyor. disable_functions ile exec, system, shell_exec, passthru, proc_open, popen gibileri kapatmak, bir web shell ele geçse bile verebileceği zararı epey kısar.
Ne öneririm?
Giden trafiği kısıtlayan bir güvenlik duvarı, madenci root bile olsa kazançsız kalır. Önem sırasına göre yapılacaklar:
CSF'de giden bağlantıları kısıtla. Varsayılan "her yere izin ver" yerine TCP_OUT/UDP_OUT'u yalnızca gereken portlarla sınırla. Madencilik havuzları 3333, 4444, 5555, 7777, 14444 gibi portlar kullanır; bunlar kapalıysa madenci havuza ulaşamaz. Bu olayda kazancı sıfırda tutan tek şey buydu.
CWP'yi güncel tut. Panel RCE'leri en büyük kapı. Otomatik güncellemeyi aç, sürümü düzenli kontrol et.
PHP disable_functions. Tehlikeli exec fonksiyonlarını kapat (bir önceki bölüm). Her PHP sürümü için ayrı ayrı.
auditd ile kritik dosyaları izle /etc/audit/rules.d/hardening.rules içine:
-w /etc/passwd -p wa -k identity
-w /root/.ssh/ -p wa -k rootssh
-w /etc/systemd/system/ -p wa -k systemd
-w /var/spool/cron/ -p wa -k cron
Çekirdek sertleştirme (sysctl): kernel.yama.ptrace_scope=1, fs.protected_regular=2, fs.protected_fifos=2 süreçler arası bellek okumayı ve /tmp saldırılarını zorlaştırır.
SSH: yalnızca anahtar (PermitRootLogin prohibit-password), standart dışı port, düşük MaxAuthTries.
Davranış tabanlı izleme. İmza tabanlı tarayıcılar (ClamAV/maldet) fileless/memfd madencisini göremez. Wazuh (dosya bütünlüğü + log) ve Falco (anormal syscall/süreç davranışı) bu tür tehditleri yakalamakta çok daha etkilidir.
Temiz kurulum. Root ele geçirildiyse, uzun vadede en güvenli yol temiz bir sunucuya taşınıp eskisini kapatmaktır.
Kaynaklar:
CVE-2022-44877 CWP kritik RCE aktif sömürülüyor (The Hacker News): https://thehackernews.com/2023/01/alert-hackers-actively-exploiting.html
CVE-2025-48703 Control Web Panel aktif sömürülüyor (Help Net Security): https://www.helpnetsecurity.com/2025/11/05/control-web-panel-cve-2025-48703-exploited/
CVE-2025-48703 teknik detay (Wiz): https://www.wiz.io/vulnerability-database/cve/cve-2025-48703
CVE-2023-42121 NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-42121
CWP forum bu kampanyanın IOC tartışması (root compromise, XMRig, port 2304): https://forum.centos-webpanel.com/centos-webpanel-bugs/possible-cwp-security-issue-root-compromise-omrig-miner-and-port-2304-exposed/msg54340/#msg54340
Selam. AlmaLinux 8 + CWP çalışan sunucumda bu kampanyadan ben de nasibimi aldım; paylaşayım dedim, gördüğüm kadarıyla aynı dertten muzdarip çok kişi var. Kısaca olay: diskte dosyası bile olmayan, root yetkisiyle çalışan bir XMRig (Monero) madencisi. Kendini çekirdek thread'i ve sahte systemd servisleri gibi gösterdiği için haftalarca gözüme çarpmadı. İşin iyi tarafı, CSF'de giden portları kısıtlı tuttuğum için madenci havuzuna hiç bağlanamamış; yani adam benden tek kuruş kazanamadı
Aşağıya nasıl fark ettiğimi, nasıl temizlediğimi ve neler önerdiğimi yazdım.Bu ne, nasıl çalışıyor ?
Yakaladığım şey XMRig'di; config.json'ındaki RandomX algoritmasından Monero kazdığı belli. Bunu aylarca görememimin üç sebebi vardı:
Diskte dosyası yok. memfd denen bellek içi bir dosyadan çalışıyor, yani ls ile göremezsin, ClamAV/maldet gibi imza tarayıcıları bulamaz, rpm -V bile temiz der.
Ayrı bir network namespace (netns) içinde çalışıyor. Bu yüzden normal ss/netstat çıktısında bağlantısı görünmüyor.
Süreç listesinde kendini [kworker/...], [netns], [kaluad] gibi çekirdek thread'i sanacağın isimlerle gizliyor. Kalıcılık için de sistem servisi gibi duran sahte systemd birimleri açıyor.
En kötüsü: bu şey root (UID 0) olarak çalışıyor. Yani olay tek bir sitenin hacklenmesi değil, sunucu çekirdek seviyesinde ele geçiriliyor. Madenci sürekli havuzuna bağlanmaya çalışıyordu ama güvenlik duvarı giden bağlantıyı kestiği için başaramamış.
Neye bakın (IOC'ler) ?
Şu IOC'ler benim olayımdan. Ama bunlar isim/IP'yi sık değiştiriyor, o yüzden adları birebir aramak yerine kalıba bakın: sistem servisi gibi duran sahte isimler, port 3333, root'tan dışarı giden ama engellenen bağlantılar.
Tür - Değer / Belirti
Madencilik havuzu 146.103.45.130:3333 (Singapur)
C2 sunucusu 212.132.98.170
Giden port 3333/tcp (stratum)
Sahte systemd servisleri dbus-monitor-srv, systemd-logind-helpers, polkitd-helpers, auth-policykit, defunct
Sahte ikili dosyalar /usr/bin/dbus-monitor-srv, /usr/bin/polkitd-helpers, /usr/bin/config.json, /usr/sbin/netd, /usr/sbin/authd, /usr/sbin/udevd-sync, /usr/lib/systemd/system/defunct.dat
Süreç listesinde [kworker/...], [netns], [kaluad] gibi, ebeveyni PID 2 (kthreadd) olmayan sahte çekirdek thread'leri
En net belirti CSF loglarında port 3333'e giden on binlerce *TCP_OUT Blocked* kaydı, UID=0
Web shell dosyaları test123zz, 404.php, cwp_login_********.php (müşteri public_html içinde)
Ek sahte ikili /usr/sbin/bootcfg
Ek sahte thread'ler [kstrp], [card0-crtc8]
İndirme / kalıcılık kaynakları raw.githubusercontent.com (Kyy-Shell), gs.thc.org, memek.cc
Exfiltrasyon host 184.107.106.86
Şüpheli giriş portu 2304 (CWP External API)
Tablonun alt yarısı kampanyanın web shell + GSocket ayağına ait. Bir kısmını kendi sunucumda gördüm, bir kısmı da aynı kampanyadan muzdarip başkalarının paylaştığı; birebir hepsi sizde olmayabilir.
Nasıl bulursunuz ?
Sizde de benzer şeyler varsa, şu kontroller madenciyi ortaya döker. Hepsi salt-okunur, bir şeyi bozmaz, gönül rahatlığıyla çalıştırın.
1. Giden bağlantı loglarına bak (en hızlı yol). Tek bir porta ve tek IP'ye, UID=0'dan giden büyük sayı madenci beacon'ıdır:
grep -h 'TCP_OUT Blocked' /var/log/messages* | grep -oE 'DPT=[0-9]+' | sort | uniq -c | sort -rn | head
2. Silinmiş veya memfd ikilisinden çalışan süreçler (fileless madencinin en belirgin izi):
ls -l /proc/*/exe 2>/dev/null | grep -iE 'deleted|memfd'
3. Sahte çekirdek thread'leri (adı köşeli parantezli ama ebeveyni PID 2 / kthreadd değil):
ps -eo pid,ppid,user,cmd --no-headers | awk '$4 ~ /^\[/ && $2 != 2 && $1 != 2'
4. Çalıştırılabilir dosyası pakete ait olmayan systemd servisleri:
for f in /etc/systemd/system/*.service /usr/lib/systemd/system/*.service; do b=$(grep -m1 -oP '^ExecStart=[-@+!]*\K\S+' "$f" 2>/dev/null); [ -n "$b" ] && [ -e "$b" ] && ! rpm -qf "$b" >/dev/null 2>&1 && echo "$f -> $b"; done
5. Yüksek CPU ve anlık dış bağlantılar (madenci CPU'yu kemirir):
ps -eo pid,user,pcpu,etimes,comm --sort=-pcpu | head
ss -tnp state established | grep -vE '127.0.0.1|::1'
6. Çekirdek seviyesi arka kapı kontrolü (bu dosya normalde olmamalı):
cat /etc/ld.so.preload 2>/dev/null || echo 'yok - iyi'
Nasıl temizledim ?
Sırası önemli: önce kanıt al, sonra öldür. Tersini yaparsan süreci öldürürsün ama kalıcılık mekanizması beş dakika sonra geri getirir, üstüne izini de kaybedersin. Komutlardaki <PID> yerine kendi bulduğun süreci koy.
1. Dondur ve kanıt al. Süreci SIGSTOP ile dondurup /proc'unu kopyala:
IR=/root/ir-$(date +%F-%H%M); mkdir -p $IR && chmod 700 $IR
kill -STOP <PID>
cp /proc/<PID>/exe $IR/miner.bin; sha256sum $IR/miner.bin | tee $IR/sha256.txt
cat /proc/<PID>/maps > $IR/maps; tr '\0' '\n' < /proc/<PID>/environ > $IR/environ
ss -tunap > $IR/ss.txt; ps auxwwf > $IR/ps.txt
2. Sahte servisleri durdur ve mask'le (reboot'ta geri gelmesinler):
for s in dbus-monitor-srv systemd-logind-helpers polkitd-helpers auth-policykit defunct; do systemctl disable --now $s.service; systemctl mask $s.service; done
3. Süreçleri öldür (önce CONT, sonra KILL):
for p in <PID listesi>; do kill -CONT $p 2>/dev/null; kill -9 $p; done
4. Zararlı dosyaları karantinaya al (silme; kanıt ve hash kalsın):
Q=$IR/quarantine; mkdir -p $Q
for f in /usr/bin/dbus-monitor-srv /usr/bin/polkitd-helpers /usr/bin/config.json /usr/sbin/netd /usr/sbin/authd /usr/sbin/udevd-sync /usr/lib/systemd/system/defunct.dat; do [ -e "$f" ] && mv "$f" $Q/; done
chmod -R 000 $Q
5. Havuz ve C2 IP'lerini engelle:
csf -d 146.103.45.130 "XMRig havuz"
csf -d 212.132.98.170 "C2"
6. Kalıntı kontrolü ve yeniden başlatma. systemctl daemon-reload çalıştır, kalan şüpheli süreç/referans olmadığını doğrula, sonra planlı bir reboot yap. memfd süreçleri yalnızca bellekte yaşar; yeniden başlatma onları kesin temizler ve kalıcılığın gerçekten kaldırılıp kaldırılmadığını geri gelmemesiyle kanıtlar.
Uyarı: Root bir kez ele geçtiyse o makineye artık yüzde yüz güvenemezsin. Temizlik acil tehlikeyi kaldırır ama en sağlıklısı temiz bir sunucuya geçip eskisini kapatmak.
Nereden girmiş ?
Açıkçası nereden girdiğini kesin çıkaramadım (olay haftalara yayılmış, loglar dönmüş). Ama forumda bu işi tartışanların en çok şüphelendiği yer CWP External API, yani port 2304. Bir de olay tek parça değil: önce bir web shell düşüyor (public_html'e test123zz, 404.php, cwp_login_********.php), sonra GSocket tabanlı bir root arka kapısı (defunct, auth-policykit), en son madenci. Giriş kapısı adayları şunlar:
CWP panel açıkları. CWP arayüzü root olarak koşuyor, dolayısıyla buradaki bir RCE direkt root veriyor. Aktif sömürülen, bilinen kritikler:
CVE-2022-44877 (https://thehackernews.com/2023/01/alert-hackers-actively-exploiting.html) Kimlik doğrulaması gerektirmeyen RCE; giriş (login/index.php) parametresine komut enjeksiyonu. CVSS 9.8. Ocak 2023'ten beri yabanda aktif sömürülüyor. Yaklaşık 0.9.8.1147 ile yamalandı kendi sürümünüzü doğrulayın.
CVE-2025-48703 (https://www.helpnetsecurity.com/2025/11/05/control-web-panel-cve-2025-48703-exploited/) filemanager changePerm API'sindeki t_total parametresinde OS komut enjeksiyonu (CWE-78). CVSS 9.0. 0.9.8.1205'ten (Haziran 2025) önceki tüm sürümleri etkiler. Enjeksiyon için kimlik doğrulaması gerekmez; yalnızca geçerli (root olmayan) bir kullanıcı adı gerekir, ki hosting sunucularında bu adlar kolayca tahmin edilir. CISA tarafından 4 Kasım 2025'te aktif sömürülenler listesine eklendi.
CVE-2023-42121 (https://nvd.nist.gov/vuln/detail/CVE-2023-42121) gibi başka CWP RCE'leri de var. Kısacası: CWP'yi her zaman en güncel sürümde tutmak kritik.
CWP External API (port 2304). Forumda herkesin parmak bastığı yer burası. Servis root olarak 0.0.0.0:2304'te dinleyebiliyor; kullanmıyorsan CWP panelinden kapat, kullanıyorsan sadece güvendiğin IP'ye aç, CSF TCP_IN'de de 2304 dışarıya kapalı olsun (zaten varsayılanda listede olmamalı).
PHP / site tarafı. Linux'ta PHP'nin kendisi nadiren direkt giriş kapısı olur (ör. CVE-2024-4577 daha çok Windows/CGI'yi vuruyor). Asıl bela güncellenmemiş WordPress ve eklentiler: oradan bir PHP web shell düşüyor, adam önce site kullanıcısı olarak kod çalıştırıyor, sonra yerel bir açıkla root'a tırmanıyor. disable_functions ile exec, system, shell_exec, passthru, proc_open, popen gibileri kapatmak, bir web shell ele geçse bile verebileceği zararı epey kısar.
Ne öneririm?
Giden trafiği kısıtlayan bir güvenlik duvarı, madenci root bile olsa kazançsız kalır. Önem sırasına göre yapılacaklar:
CSF'de giden bağlantıları kısıtla. Varsayılan "her yere izin ver" yerine TCP_OUT/UDP_OUT'u yalnızca gereken portlarla sınırla. Madencilik havuzları 3333, 4444, 5555, 7777, 14444 gibi portlar kullanır; bunlar kapalıysa madenci havuza ulaşamaz. Bu olayda kazancı sıfırda tutan tek şey buydu.
CWP'yi güncel tut. Panel RCE'leri en büyük kapı. Otomatik güncellemeyi aç, sürümü düzenli kontrol et.
PHP disable_functions. Tehlikeli exec fonksiyonlarını kapat (bir önceki bölüm). Her PHP sürümü için ayrı ayrı.
auditd ile kritik dosyaları izle /etc/audit/rules.d/hardening.rules içine:
-w /etc/passwd -p wa -k identity
-w /root/.ssh/ -p wa -k rootssh
-w /etc/systemd/system/ -p wa -k systemd
-w /var/spool/cron/ -p wa -k cron
Çekirdek sertleştirme (sysctl): kernel.yama.ptrace_scope=1, fs.protected_regular=2, fs.protected_fifos=2 süreçler arası bellek okumayı ve /tmp saldırılarını zorlaştırır.
SSH: yalnızca anahtar (PermitRootLogin prohibit-password), standart dışı port, düşük MaxAuthTries.
Davranış tabanlı izleme. İmza tabanlı tarayıcılar (ClamAV/maldet) fileless/memfd madencisini göremez. Wazuh (dosya bütünlüğü + log) ve Falco (anormal syscall/süreç davranışı) bu tür tehditleri yakalamakta çok daha etkilidir.
Temiz kurulum. Root ele geçirildiyse, uzun vadede en güvenli yol temiz bir sunucuya taşınıp eskisini kapatmaktır.
Kaynaklar:
CVE-2022-44877 CWP kritik RCE aktif sömürülüyor (The Hacker News): https://thehackernews.com/2023/01/alert-hackers-actively-exploiting.html
CVE-2025-48703 Control Web Panel aktif sömürülüyor (Help Net Security): https://www.helpnetsecurity.com/2025/11/05/control-web-panel-cve-2025-48703-exploited/
CVE-2025-48703 teknik detay (Wiz): https://www.wiz.io/vulnerability-database/cve/cve-2025-48703
CVE-2023-42121 NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-42121
CWP forum bu kampanyanın IOC tartışması (root compromise, XMRig, port 2304): https://forum.centos-webpanel.com/centos-webpanel-bugs/possible-cwp-security-issue-root-compromise-omrig-miner-and-port-2304-exposed/msg54340/#msg54340
33
PHP / Re: Update your PHP ASAP 🚨
« Last post by overseer on October 25, 2026, 03:23:11 PM »In my case most servers updated properly, but one server was very problematic. Maybe it was my provider doing scheduled network maintenance Thursday night, or there may have been a conflict with Sandeep's php-manager. Somehow the upgrade to PHP 8.3 on the backend failed. There was a mismatch of Ioncube loader versions and bad PHP syntax keeping CWP from loading. Admin panel just read:
Quote
No Loader is installed, please try to run this command or contact support: sh /scripts/update_ioncubeI tried emerysteele's PCRE workaround, but that just resulted in a 500 error due to PHP syntax version differences between the old CWP 7.2 backend and the new 8.3.36. So I had to revert back to the previous ldconfig:
Code: [Select]
mv /root/pcre2_local_backup/* /usr/local/lib/ && ldconfigMy self-help fix was to remove the MARK file from the filesystem and edit.the PHP 8.3 upgrade script:Code: [Select]
/scripts/update_cwpphp83I just commented out the MARK logic to get the script to re-run manually. After a while running, it worked to reinstall the admin panel! This is probably an edge case, but maybe it will help someone else.34
PHP / Re: CWP system PHP 8.3.36 UPDATE (CVE)
« Last post by overseer on October 25, 2026, 03:19:33 PM »Look at /usr/local/cwpsrv/logs/error_log
In my case I had a 500 error recently due to the BIG update failing in the transition to the backend being on 8.3. Maybe it was my provider doing scheduled network maintenance Thursday night, or there may have been a conflict with Sandeep's php-manager. There was a mismatch of Ioncube loader versions and bad PHP syntax keeping CWP from loading. Admin panel just read:
In my case I had a 500 error recently due to the BIG update failing in the transition to the backend being on 8.3. Maybe it was my provider doing scheduled network maintenance Thursday night, or there may have been a conflict with Sandeep's php-manager. There was a mismatch of Ioncube loader versions and bad PHP syntax keeping CWP from loading. Admin panel just read:
Quote
No Loader is installed, please try to run this command or contact support: sh /scripts/update_ioncubeI tried emerysteele's PCRE workaround in the other main PHP thread, but that just resulted in a 500 error due to PHP syntax version differences between the old CWP 7.2 backend and the new 8.3.36. So I had to revert back to the previous ldconfig:
Code: [Select]
mv /root/pcre2_local_backup/* /usr/local/lib/ && ldconfigMy self-help fix was to remove the MARK file and edit.the PHP 8.3 upgrade script:Code: [Select]
/scripts/update_cwpphp83I just commented out the MARK logic to get the script to re-run manually. After a while, it worked to reinstall the admin panel!35
CentOS 8 Problems / Re: sed: can't read /usr/local/cwpsrv/conf.d/api.conf: No such file or directory
« Last post by overseer on October 25, 2026, 03:10:14 PM »I have that file on my running AlmaLinux 8 servers. Maybe Starburst or others could confirm it is present on AL9.
Are you using the FULL DVD installer for AlmaLinux? You can't use the Minimal installer to spin up a CWP server.
Are you using the FULL DVD installer for AlmaLinux? You can't use the Minimal installer to spin up a CWP server.
36
Other / Re: This file popped up in the cwp audit run notification
« Last post by overseer on October 25, 2026, 03:08:09 PM »I think you will see many false positives during this transition from the CWP backend going from PHP 7.2 to 8.3.36. Just ignore and it should straighten out in short order.
37
Updates / Re: Cant access admin area - 500 error
« Last post by overseer on October 25, 2026, 03:06:25 PM »Look at /usr/local/cwpsrv/logs/error_log
In my case I had a 500 error recently due to the BIG update failing in the transition to the backend being on 8.3. There was a mismatch of Ioncube loader versions and bad PHP syntax keeping CWP from loading.
In my case I had a 500 error recently due to the BIG update failing in the transition to the backend being on 8.3. There was a mismatch of Ioncube loader versions and bad PHP syntax keeping CWP from loading.
38
Updates / Cant access admin area - 500 error
« Last post by anandmys on October 25, 2026, 02:43:08 PM »I am unable to access admin area.
I guess, it is related to the topic at https://wiki.centos-webpanel.com/cwp-expired-error-500
But instructions look outdated.
Can someone please help me resolve this
I guess, it is related to the topic at https://wiki.centos-webpanel.com/cwp-expired-error-500
But instructions look outdated.
Can someone please help me resolve this
39
PHP / Re: Update your PHP ASAP 🚨
« Last post by djprmf on October 25, 2026, 01:48:20 PM »As others who run cwppro 1.24 and thereby also the 8.3.36 for the cwp internal php, I see that the error reported by others with not showing emailaccounts is present - the following error is reported by the panel:
DataTables warning: table id=m_table_1 - Ajax error. For more
information about this error, please see http://datatables.net/tn/7
Appears to be a bug in the latest versions 1.23 and above.
Still no one knows when will be fixed.
40
Other / This file popped up in the cwp audit run notification
« Last post by audept on October 25, 2026, 01:11:18 PM »File:
/usr/lib64/gconv/gconv-modules.cache
CWP-Security-Audit - Unknown File
Popped out with a audit notification on the cwp main display this morning. (ALMA 8 instance, cwp version 1.24)
Right now I am assuming no impact, but important enough to run up the flag pole here just in case..?..
Thanks...
/usr/lib64/gconv/gconv-modules.cache
CWP-Security-Audit - Unknown File
Popped out with a audit notification on the cwp main display this morning. (ALMA 8 instance, cwp version 1.24)
Right now I am assuming no impact, but important enough to run up the flag pole here just in case..?..
Thanks...
