Something is intercepting bots and loading a different page for them.

I’m facing a very strange issue.
Something on the server is intercepting all web requests from bots that have "bot," "crawler," or "spider" in their user-agent string (there may be others, but these are the ones I've noticed). I spotted this because social sharing links stopped loading correctly, and my already meager AdSense earnings plummeted.
The strangest part is that it isn't a standard block; instead, when a bot is detected, it loads a basic HTML page that says "Welcome Loading..."
I’ve checked everything: there are no filters in Nginx or PHP, and ModSecurity is disabled. I reviewed the Nginx and Apache configuration files and found nothing unusual. I even searched the entire server for that "Welcome" file—or any file containing that text—but couldn't find it.
What could be happening? I would appreciate any help. Thanks.
 

Did you search your sites root folder for any suspicious files or code, redirects or recent changes?

What do the logs tell you? You can view in the UI (File Management > CWP->Log Viewer or below)

Apache Main Access Logs: /usr/local/apache/logs/access_log
Apache/Nginx Domain Logs: /usr/local/apache/domlogs/DOMAIN.COM
Nginx Access Logs: /var/log/nginx/access.log

IMO you should also keepModSec enabled (other than disabling for troubleshooting) you are on PHP 7.3 which you might choose to upgrade if your sites allow.

I’m facing a very strange issue.
(...)

You are a very brave man.
We all need to be constantly paranoid to keep any web server secure.
It is practically unfeasible these days to keep a web server exposed to the internet—using closed-source software like CWP—without ModSecurity, Coraza, or similar tools.
Avoid doing this unless you know exactly what you are doing or want to deal with big major headaches involving clients.
Therefore, enable ModSecurity and use a WAF like Comodo (specifically with the latest updates available for the 'sminozzi' user) or OWASP CRS4, and always monitor your logs to keep your rules up to date.

Regards,
Netino

I’ve already checked the logs and configuration—nothing suspicious there. That server had been running fine for about 10 years until the CWP admin File Manager was hacked a few months ago; I’m 99.9% sure that’s where the malicious code got in. I recall the index file being overwritten with a page identical to that "welcome" page; we cleaned everything up, but clearly, something was left behind.
I’ll have to find the time to wipe the drive and do a clean reinstallation from scratch, but that’s tricky since it’s a production server.

I've pasted a couple of threads below for you to read up on, are also many different threads on the issues. There were 2 issues in the past few months (both patched now). As your finding though they can be difficult to find and persistant in nature. Searching for defauit.php (spelt with an i) is worth searching for, it was common in the 1st issue.

But as you've already stated if you can't locate/nullify the issue IMO a fresh install is the answer. Just do your reseach on upgrades you will need to do on a fresh install, maybe even a practice run before moving the prod server.

https://forum.centos-webpanel.com/centos-webpanel-bugs/cve-2025-48703-cve-2026-57517-the-gsocket-systemd-backdoor-cwp-s/

https://forum.centos-webpanel.com/centos-webpanel-bugs/critical-multiple-cwp-servers-infected-arbitrary-php-code-execution-via-publ/

for some reason I cannot post the whole answer here, so I made an external post about your case which I came across on one of my servers too

https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them

Thanks for your replies; they are valuable for understanding the issue.
It turns out to be the same case Geodim described; I followed the steps outlined on his blog, and the problem was resolved. Many thanks!   
That leads me to ask: isn't CWP supposed to show an alert if a system file is modified? Does the fact that it didn't show one mean something else has been altered?

Did you check the .htaccess file? Make sure your sites don’t contain any suspicious or obfuscated code. This could also happen if your website loads files or resources from a compromised third-party site.

If you identified the user agents that trigger the redirect, try searching the web server configs and website files for those user agents.

As I mentioned in my previous response, the cause of the hack has been located; it's in geodim's answer.
It was infected with a backdoor Python script running as a fake ntpd process. The redirection is handled by a fake Apache module, mod_auth_form.so, which links to the libcurl library.

I'm almost certain that these fake files were uploaded to my server during the last CWP File Manager breach.
The link geodim provided (https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them) contains the steps to verify whether the files are real or fake, and to proceed with terminating the hacker's service and deleting those files.

In my case, the strings check didn't find any suspicious strings within mod_auth_form.so, but it failed the RPM integrity check, resulting in a checksum indicating a fake mod_auth_form.so file.

Similarly, the fake /usr/bin/ntpd file was enormous, many megabytes in size, while the originals are small.
By killing the service, deleting those files, and restarting Apache, the selective redirection disappeared.