CloudPanel version(s) affected
beginning from last year to date
Description
Hello CloudPanel Team,
I would like to report a security-related issue I experienced on a CloudPanel-managed WordPress site.
I have also docummented the whole proce here - https://joshwp.com/wordpress-seo-spam-injection-cleanup/
Site affected: freeexams.co.ke
Document root: /home/freeexams/htdocs/freeexams.co.ke
I first noticed the issue in 2025 after installing CloudPanel and uploading a clean WordPress migration. The site had been affected by Japanese SEO spam. I assumed the clean migration would remove the problem, but the issue persisted through multiple cleanup attempts.
Recently, Wordfence flagged this file:
/home/freeexams/htdocs/freeexams.co.ke/index.php
The file contained a large obfuscated PHP payload. Replacing it with the official clean WordPress index.php did not work at first, because it was being rewritten almost immediately.
After deeper investigation, the cause was three long-running PHP CLI processes owned by the CloudPanel site user:
php -f /tmp/httpd.conf
They were running under the freeexams user, with the working directory set to:
/home/freeexams/htdocs/freeexams.co.ke
The source file /tmp/httpd.conf no longer existed on disk, but the PHP processes were still alive in memory and kept rewriting index.php.
After killing those processes and restoring the clean WordPress file, the site stayed clean. WordPress core checksums passed, all plugin checksums passed, and a final Wordfence scan came back clean.
I am not claiming CloudPanel caused the compromise, but I would like to report this as a possible security/hardening issue or visibility gap:
A long-running PHP CLI process was able to persist under a CloudPanel site user.
The process was executing from /tmp.
The source file had been deleted, but the process continued running.
The process was not visible or flagged in CloudPanel.
It was able to repeatedly modify files in the site document root.
Could you please advise whether CloudPanel has, or could add, protections or visibility around this type of behavior? For example:
Detecting suspicious long-running PHP CLI processes under site users.
Warning when a site user runs PHP from /tmp.
Showing active processes per site in the CloudPanel UI.
Optionally restricting PHP CLI execution from /tmp.
Adding malware persistence checks for deleted-but-running scripts.
I would appreciate any guidance on whether this is expected behavior, a known issue, or something CloudPanel can improve from a security perspective.
I have attached the infected php file for reference
Thank you.
index.php.txt
How to reproduce
Hello CloudPanel Team,
I would like to report a security-related issue I experienced on a CloudPanel-managed WordPress site.
I have also docummented the whole proce here - https://joshwp.com/wordpress-seo-spam-injection-cleanup/
Site affected: freeexams.co.ke
Document root: /home/freeexams/htdocs/freeexams.co.ke
I first noticed the issue in 2025 after installing CloudPanel and uploading a clean WordPress migration. The site had been affected by Japanese SEO spam. I assumed the clean migration would remove the problem, but the issue persisted through multiple cleanup attempts.
Recently, Wordfence flagged this file:
/home/freeexams/htdocs/freeexams.co.ke/index.php
The file contained a large obfuscated PHP payload. Replacing it with the official clean WordPress index.php did not work at first, because it was being rewritten almost immediately.
After deeper investigation, the cause was three long-running PHP CLI processes owned by the CloudPanel site user:
php -f /tmp/httpd.conf
They were running under the freeexams user, with the working directory set to:
/home/freeexams/htdocs/freeexams.co.ke
The source file /tmp/httpd.conf no longer existed on disk, but the PHP processes were still alive in memory and kept rewriting index.php.
After killing those processes and restoring the clean WordPress file, the site stayed clean. WordPress core checksums passed, all plugin checksums passed, and a final Wordfence scan came back clean.
I am not claiming CloudPanel caused the compromise, but I would like to report this as a possible security/hardening issue or visibility gap:
A long-running PHP CLI process was able to persist under a CloudPanel site user.
The process was executing from /tmp.
The source file had been deleted, but the process continued running.
The process was not visible or flagged in CloudPanel.
It was able to repeatedly modify files in the site document root.
Could you please advise whether CloudPanel has, or could add, protections or visibility around this type of behavior? For example:
Detecting suspicious long-running PHP CLI processes under site users.
Warning when a site user runs PHP from /tmp.
Showing active processes per site in the CloudPanel UI.
Optionally restricting PHP CLI execution from /tmp.
Adding malware persistence checks for deleted-but-running scripts.
I would appreciate any guidance on whether this is expected behavior, a known issue, or something CloudPanel can improve from a security perspective.
I have attached the infected php file for reference
Thank you.
Possible Solution
No response
Additional Context
No response
CloudPanel version(s) affected
beginning from last year to date
Description
Hello CloudPanel Team,
I would like to report a security-related issue I experienced on a CloudPanel-managed WordPress site.
I have also docummented the whole proce here - https://joshwp.com/wordpress-seo-spam-injection-cleanup/
Site affected: freeexams.co.ke
Document root: /home/freeexams/htdocs/freeexams.co.ke
I first noticed the issue in 2025 after installing CloudPanel and uploading a clean WordPress migration. The site had been affected by Japanese SEO spam. I assumed the clean migration would remove the problem, but the issue persisted through multiple cleanup attempts.
Recently, Wordfence flagged this file:
/home/freeexams/htdocs/freeexams.co.ke/index.php
The file contained a large obfuscated PHP payload. Replacing it with the official clean WordPress index.php did not work at first, because it was being rewritten almost immediately.
After deeper investigation, the cause was three long-running PHP CLI processes owned by the CloudPanel site user:
php -f /tmp/httpd.conf
They were running under the freeexams user, with the working directory set to:
/home/freeexams/htdocs/freeexams.co.ke
The source file /tmp/httpd.conf no longer existed on disk, but the PHP processes were still alive in memory and kept rewriting index.php.
After killing those processes and restoring the clean WordPress file, the site stayed clean. WordPress core checksums passed, all plugin checksums passed, and a final Wordfence scan came back clean.
I am not claiming CloudPanel caused the compromise, but I would like to report this as a possible security/hardening issue or visibility gap:
A long-running PHP CLI process was able to persist under a CloudPanel site user.
The process was executing from /tmp.
The source file had been deleted, but the process continued running.
The process was not visible or flagged in CloudPanel.
It was able to repeatedly modify files in the site document root.
Could you please advise whether CloudPanel has, or could add, protections or visibility around this type of behavior? For example:
Detecting suspicious long-running PHP CLI processes under site users.
Warning when a site user runs PHP from /tmp.
Showing active processes per site in the CloudPanel UI.
Optionally restricting PHP CLI execution from /tmp.
Adding malware persistence checks for deleted-but-running scripts.
I would appreciate any guidance on whether this is expected behavior, a known issue, or something CloudPanel can improve from a security perspective.
I have attached the infected php file for reference
Thank you.
index.php.txt
How to reproduce
Hello CloudPanel Team,
I would like to report a security-related issue I experienced on a CloudPanel-managed WordPress site.
I have also docummented the whole proce here - https://joshwp.com/wordpress-seo-spam-injection-cleanup/
Site affected: freeexams.co.ke
Document root: /home/freeexams/htdocs/freeexams.co.ke
I first noticed the issue in 2025 after installing CloudPanel and uploading a clean WordPress migration. The site had been affected by Japanese SEO spam. I assumed the clean migration would remove the problem, but the issue persisted through multiple cleanup attempts.
Recently, Wordfence flagged this file:
/home/freeexams/htdocs/freeexams.co.ke/index.php
The file contained a large obfuscated PHP payload. Replacing it with the official clean WordPress index.php did not work at first, because it was being rewritten almost immediately.
After deeper investigation, the cause was three long-running PHP CLI processes owned by the CloudPanel site user:
php -f /tmp/httpd.conf
They were running under the freeexams user, with the working directory set to:
/home/freeexams/htdocs/freeexams.co.ke
The source file /tmp/httpd.conf no longer existed on disk, but the PHP processes were still alive in memory and kept rewriting index.php.
After killing those processes and restoring the clean WordPress file, the site stayed clean. WordPress core checksums passed, all plugin checksums passed, and a final Wordfence scan came back clean.
I am not claiming CloudPanel caused the compromise, but I would like to report this as a possible security/hardening issue or visibility gap:
A long-running PHP CLI process was able to persist under a CloudPanel site user.
The process was executing from /tmp.
The source file had been deleted, but the process continued running.
The process was not visible or flagged in CloudPanel.
It was able to repeatedly modify files in the site document root.
Could you please advise whether CloudPanel has, or could add, protections or visibility around this type of behavior? For example:
Detecting suspicious long-running PHP CLI processes under site users.
Warning when a site user runs PHP from /tmp.
Showing active processes per site in the CloudPanel UI.
Optionally restricting PHP CLI execution from /tmp.
Adding malware persistence checks for deleted-but-running scripts.
I would appreciate any guidance on whether this is expected behavior, a known issue, or something CloudPanel can improve from a security perspective.
I have attached the infected php file for reference
Thank you.
Possible Solution
No response
Additional Context
No response