Recent Posts
31
Updates / Re: Unable to load dynamic library 'intl'
« Last post by venty on September 22, 2026, 05:36:43 PM »https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/fix-for-php-startup-unable-to-load-dynamic-library-intl-cwp-error-on-almalinux-9/
Hi,
I plan to follow the steps in article, but I didn't understand the explanations following the line:
"Thanks to @cyberspcae over at the CWP forums for the below"
(Has been modified if your server shows PHP 7.4.33 on AlmaLinux 9.
What should I execute—which lines should I run and which ones shouldn't I?
Thanks...
BR
Venty
32
CentOS-WebPanel Bugs / Re: OWASP Modsecurity rules showing warnings and does not block anithing
« Last post by Freespirits_GR_Host on September 22, 2026, 07:23:38 AM »I would verify the effective ModSecurity configuration rather than relying on what the CWP UI reports.
First confirm which ruleset Apache is actually loading, whether the active include points to the .conf file rather than .conf.example, and whether ModSecurity is running in blocking mode rather than detection-only mode. Then send a harmless request that should trigger a known CRS rule and confirm the event appears in the ModSecurity audit log.
That separates three different problems: the rules aren't being loaded, they're loaded but only detecting, or CWP is changing the configuration during an update/rebuild.
I'd also record the file timestamps before and after a CWP update/rebuild. If the working configuration is being replaced automatically, that gives you a much clearer point to investigate than repeatedly renaming the file.
I develop CWP7 Resource Shield, which is designed around this broader problem of coordinating CWP traffic protection instead of relying on a single defensive layer. It can combine traffic-pattern analysis with Cloudflare and optional CSF workflows. I'm mentioning it because this is directly related to the problem it was built for; I'd still verify the active ModSecurity configuration first before adding another layer.
First confirm which ruleset Apache is actually loading, whether the active include points to the .conf file rather than .conf.example, and whether ModSecurity is running in blocking mode rather than detection-only mode. Then send a harmless request that should trigger a known CRS rule and confirm the event appears in the ModSecurity audit log.
That separates three different problems: the rules aren't being loaded, they're loaded but only detecting, or CWP is changing the configuration during an update/rebuild.
I'd also record the file timestamps before and after a CWP update/rebuild. If the working configuration is being replaced automatically, that gives you a much clearer point to investigate than repeatedly renaming the file.
I develop CWP7 Resource Shield, which is designed around this broader problem of coordinating CWP traffic protection instead of relying on a single defensive layer. It can combine traffic-pattern analysis with Cloudflare and optional CSF workflows. I'm mentioning it because this is directly related to the problem it was built for; I'd still verify the active ModSecurity configuration first before adding another layer.
33
CSF Firewall / Re: Critical Vulnerability in CSF MESSENGER (CVE-2026-67402)-03/Sep/2026
« Last post by Freespirits_GR_Host on September 22, 2026, 07:21:54 AM »Thanks for posting this, especially the note that your own server was already attacked.
If exploitation actually reached the server, I wouldn't stop at upgrading CSF or setting MESSENGERV3 = 0. Those close the known entry point, but they don't establish whether anything was left behind.
I would also check recent systemd service creation/modification, unexpected cron entries, new or modified SSH authorized_keys, unusual listening ports/processes, recent executables in /tmp and similar writable locations, and suspicious processes that return after being killed.
Comparing timestamps around the suspected attack window can be particularly useful. If something was executed as the Apache user, I'd also inspect files/directories writable by that context and correlate them with the web/access logs.
I develop the CWP7 Security Audit Module, which automates a number of these evidence checks specifically for CWP7 servers and reports them as PASS / INFO / REVIEW / FAIL. I built it largely because checking these persistence indicators manually after CWP incidents became repetitive. If useful, I can explain the checks it performs — but regardless of the tool, I would definitely do a post-compromise review after applying the CSF fix.
If exploitation actually reached the server, I wouldn't stop at upgrading CSF or setting MESSENGERV3 = 0. Those close the known entry point, but they don't establish whether anything was left behind.
I would also check recent systemd service creation/modification, unexpected cron entries, new or modified SSH authorized_keys, unusual listening ports/processes, recent executables in /tmp and similar writable locations, and suspicious processes that return after being killed.
Comparing timestamps around the suspected attack window can be particularly useful. If something was executed as the Apache user, I'd also inspect files/directories writable by that context and correlate them with the web/access logs.
I develop the CWP7 Security Audit Module, which automates a number of these evidence checks specifically for CWP7 servers and reports them as PASS / INFO / REVIEW / FAIL. I built it largely because checking these persistence indicators manually after CWP incidents became repetitive. If useful, I can explain the checks it performs — but regardless of the tool, I would definitely do a post-compromise review after applying the CSF fix.
34
Backup / Re: Backup Manager Beta is not remembering password in destination
« Last post by adrianofnatal on September 21, 2026, 09:09:00 PM »Never worked after some update around 0.9.xxx.
I use S3.
Manually works, upload to S3.
Scheduled does not work.
I use S3.
Manually works, upload to S3.
Scheduled does not work.
35
Information / Re: Possible CWP Security Issue – Malicious JavaScript Injection
« Last post by Freespirits_GR_Host on September 19, 2026, 10:59:15 PM »That's an interesting finding, particularly because those accounts don't have active WordPress installations and the requests came from an IP you don't recognize.
Since you're already using Falco, I'd correlate the timestamp of those requests with several other persistence areas rather than concentrating only on the generated cwp_login_* files.
I'd check for unexpected systemd services/timers, cron entries, SSH keys, recently created executables, unusual listening processes/ports and modifications around the same timestamp. I'd also search the other CWP accounts for the same filenames and activity pattern. If the same IOC appears across unrelated accounts, that becomes particularly valuable evidence.
I've been working on exactly this problem on my own CWP servers because manually correlating all these checks takes a huge amount of time. I eventually developed a CWP7 Security Audit Module that automates the checks and exposes the evidence inside CWP. Full disclosure: I'm the developer.
In your particular case, though, I'd be especially interested in comparing the creation timestamps of those cwp_login_* files against systemd/cron/process activity. That could help distinguish a vulnerable CWP function being called remotely from persistence already present elsewhere on the server.
Since you're already using Falco, I'd correlate the timestamp of those requests with several other persistence areas rather than concentrating only on the generated cwp_login_* files.
I'd check for unexpected systemd services/timers, cron entries, SSH keys, recently created executables, unusual listening processes/ports and modifications around the same timestamp. I'd also search the other CWP accounts for the same filenames and activity pattern. If the same IOC appears across unrelated accounts, that becomes particularly valuable evidence.
I've been working on exactly this problem on my own CWP servers because manually correlating all these checks takes a huge amount of time. I eventually developed a CWP7 Security Audit Module that automates the checks and exposes the evidence inside CWP. Full disclosure: I'm the developer.
In your particular case, though, I'd be especially interested in comparing the creation timestamps of those cwp_login_* files against systemd/cron/process activity. That could help distinguish a vulnerable CWP function being called remotely from persistence already present elsewhere on the server.
36
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by Freespirits_GR_Host on September 19, 2026, 10:55:09 PM »Sorry to hear you were affected too. With this type of CWP compromise I would be careful about treating removal of the visible payload as confirmation that the server is clean.
I would check persistence separately: systemd units, cron entries, SSH authorized_keys, unexpected executables, suspicious listening ports/processes, /etc/ld.so.preload, unusual recently modified files and known IOC filenames. I would also compare the same checks across all three servers, because differences between an affected and apparently clean server can be extremely useful.
This exact problem — having to manually investigate all of these areas every time something suspicious happens — is actually why I developed my CWP7 Security Audit Module. Full disclosure: I'm the developer of it. It performs these CWP-focused checks and presents the evidence through the CWP GUI so an administrator can investigate much faster.
Even without using my module, though, I would definitely perform the persistence checks above before considering an affected machine clean.
I would check persistence separately: systemd units, cron entries, SSH authorized_keys, unexpected executables, suspicious listening ports/processes, /etc/ld.so.preload, unusual recently modified files and known IOC filenames. I would also compare the same checks across all three servers, because differences between an affected and apparently clean server can be extremely useful.
This exact problem — having to manually investigate all of these areas every time something suspicious happens — is actually why I developed my CWP7 Security Audit Module. Full disclosure: I'm the developer of it. It performs these CWP-focused checks and presents the evidence through the CWP GUI so an administrator can investigate much faster.
Even without using my module, though, I would definitely perform the persistence checks above before considering an affected machine clean.
37
Backup / Re: Backup Manager Beta is not remembering password in destination
« Last post by clight77 on September 19, 2026, 06:15:41 PM »Nope it is not saving the password.
I put in my password every afternoon and update it then my BU works while I sleep, then it is rinse and repeat everyday.
I put in my password every afternoon and update it then my BU works while I sleep, then it is rinse and repeat everyday.
38
Updates / Re: Unable to load dynamic library 'intl'
« Last post by Starburst on September 19, 2026, 02:02:52 AM »If that doesn't work, Sandeep has published a different fix at:
https://www.alphagnu.com/topic/632-update-roundcube-and-fix-php-intl-extension-in-cwp/#comment-1482
https://www.alphagnu.com/topic/632-update-roundcube-and-fix-php-intl-extension-in-cwp/#comment-1482
39
Updates / Re: Unable to load dynamic library 'intl'
« Last post by Martins-phpbb on September 18, 2026, 06:38:14 PM »40
Backup / Re: Backup Manager Beta is not remembering password in destination
« Last post by vox on September 18, 2026, 02:46:37 AM »Backup not working again. CWPpro version: 1.14
