WordPress SEO Spam Injection Cleanup: From Japanese Search Results to a Clean Wordfence Scan

The Site

Background: WordPress SEO Spam Injection Cleanup on CloudPanel

FreeExams.co.ke is a WordPress site hosted on a CloudPanel server that also hosts other websites. The important boundary was clear from the start: the work had to target only the FreeExams site, not every site on the server.

This was not a brand-new problem that appeared and disappeared in a single afternoon. The issue had been noticed since 2025, after CloudPanel was installed and a clean site migration file was uploaded. The clean migration made sense as a recovery attempt: if the compromised files were inside the old WordPress copy, replacing them should have removed the problem. But the spam behavior persisted through multiple attempts, which was the clue that something outside the normal WordPress file set was still alive.

That history also changed how the cleanup had to be approached. CloudPanel was the hosting control panel, not automatically the cause. The key question was whether something in the server account, process table, scheduler, or webroot was continuing to rewrite the site after clean files were restored.

The WordPress document root was:

The server was accessed over SSH as root, but the WordPress files themselves were owned by the CloudPanel site user and group:

This matters because malware persistence can live at several levels: in WordPress files, in plugin files, in database snippets, in scheduled WordPress cron jobs, in system cron jobs, or as a long-running process under the site account. The cleanup had to be careful enough to distinguish those layers.

What Google Showed

Visible Symptoms: Japanese E-commerce Spam in Search

The first obvious symptom was not a broken homepage. It was Google search results. The domain had started showing Japanese e-commerce titles and snippets, including product-style pages that had nothing to do with Kenyan exam materials. This is a classic SEO spam pattern: attackers inject doorway pages or cloaked responses so search engines index commercial spam under a legitimate domain.

The spam pages were not merely ugly. They were dangerous for the domain’s reputation. If Google continues to see spam content, the site can lose trust, search visibility, and user confidence. Search Console cleanup helps remove bad indexed URLs, but it does not fix the compromised server by itself.

The First Defense

What Had Already Been Tried Before the Final Cleanup

Before the final repair, several meaningful steps had already been taken. These were not foolish steps. They reduced damage and bought time. The problem was that they guarded the symptom rather than the source of reinfection.

1. Search Console Cleanup

The spam URLs had been removed from Google Search Console. This was visible in the newer search screenshot, where the domain showed legitimate FreeExams pages again instead of the earlier Japanese e-commerce entries.

2. Manual Removal of E-commerce Spam Footprints

The obvious e-commerce additions that had affected search results were cleaned up. This helped repair the search-facing side of the incident.

3. Clean Migration Attempt

After noticing the issue in 2025, a clean site migration file was uploaded after CloudPanel had been installed. This was a sensible step because many WordPress infections live inside plugin, theme, upload, or core files. A clean migration can wipe those away if the malware is only stored in the site files being replaced.

In this case, the infection persisted after the clean migration. That did not mean the migration was useless. It meant the remaining persistence was probably outside the migrated WordPress package. The final investigation proved that point: the writer was a long-running PHP process under the site user, not just a bad file inside the migration archive.

4. Repeated Manual Attempts

There had been many attempts to make the issue go away. Some improved the search results. Some hardened the visible file. But because the hidden PHP process was still running, the infection had a way to come back. This is the exhausting part of malware cleanup: when the persistence layer is missed, every visible fix feels temporary. After enough cycles of trying, waiting, and seeing the problem persist, it was understandable to feel like giving up.

5. Hardened index.php Workflow

Because Wordfence kept flagging index.php, the file had been protected with immutable filesystem attributes and read-only permissions. The workflow looked like this:

That workflow stopped a file from being changed while it was locked. But it also created a maintenance burden: every WordPress update required manual unlock, update, and relock steps. More importantly, the malicious writer still existed. It was simply blocked from modifying that one file while the immutable flag was active.

Scope Control

Hosting Context: Only One Site Needed Work

The CloudPanel server hosted several websites, but the target was only:

That meant the cleanup had to stay inside the FreeExams site unless system-level persistence was discovered. This is why the early commands focused on the site root, its owner, its logs, its WordPress files, and its PHP processes.

Initial Server Inspection

The first live inspection confirmed:

• The WordPress site root existed at /home/freeexams/htdocs/freeexams.co.ke.
• index.php was 22,534 bytes, far larger than the normal WordPress front controller.
• index.php was read-only and immutable.
• WP-CLI was installed at /usr/bin/wp.
• The site was running WordPress 7.0.

The Infected File

The Wordfence Finding: index.php Contained an Obfuscated Backdoor

Wordfence’s file viewer showed that index.php began with a massive obfuscated PHP block before the normal WordPress bootstrap. A clean WordPress index.php is tiny. It should define WP_USE_THEMES and require wp-blog-header.php. It should not contain goto mazes, dynamic variables, remote fetch logic, encoded strings, or @eval.

The first official checksum check confirmed the suspicion:

That was actually encouraging: WordPress core verification reported index.php as the failing file, not hundreds of modified core files. The visible core compromise was concentrated in the front controller.

The Wrong PHP Code Wordfence Showed

The bad file was not a normal WordPress front controller. Wordfence showed /home/freeexams/htdocs/freeexams.co.ke/index.php as a 22,534 byte file modified on Tuesday, June 16, 2026. A clean WordPress index.php for this install was only 405 bytes.

For the report, the dangerous PHP is shown below as a non-executable forensic excerpt. The original infected copy was preserved separately on the server as evidence, but this article does not need to publish the full working backdoor.

The final line is what made the infection easy to miss during casual browsing: after the malicious code ran, the file still loaded WordPress. That allowed the homepage to keep working while the payload handled special requests, search-engine traffic, referrer logic, and remote content behavior before handing normal visitors back to WordPress.

The Trap

The First Repair Attempt: Clean File, Immediate Reinfection

The first repair was careful and reversible. The infected file was copied into a root-only cleanup folder for evidence, then index.php was unlocked and replaced with a clean WordPress front controller.

To avoid relying on memory, a fresh WordPress 7.0 core package was downloaded into /tmp, and the official index.php from that package was used as the replacement.

At first, the hashes matched:

Then came the important discovery: the file reverted almost immediately. Within seconds, index.php was back to 22,534 bytes, read-only, and infected.

The Breakthrough

Root Cause Discovery: Three Hidden PHP Processes in Memory

The next step was to look outside the WordPress files. If a clean file was being rewritten without a browser request or WP-CLI command, the likely culprits were a background process, cron job, systemd service, or another persistent script.

The process list revealed the real issue:

Those processes were suspicious for several reasons:

• They were owned by the site user freeexams.
• They had been running since March 14, 2026.
• They were executing PHP from /tmp/httpd.conf, which is not a normal WordPress, CloudPanel, or php-fpm path.
• The process parent was PID 1, meaning the original launcher was gone and the processes had been adopted by init.
• The current working directory was the FreeExams webroot.

The command line and working directory confirmed it:

The source file itself no longer existed:

That explained why simple file scans did not find the writer. The original script had been deleted, but PHP was still running it in memory. As long as those processes lived, they could rewrite index.php again and again.

The Actual Fix

Final Remediation: Stop the Writer, Then Restore the File

The three malicious PHP processes were stopped:

After a short wait, they did not return:

The only later processes under freeexams were normal php-fpm workers:

With the active writer gone, index.php was repaired again using the official WordPress 7.0 file:

This time, the file stayed clean after a waiting period. The clean checksum remained:

Proof, Not Hope

Technical Verification After Cleanup

Cleanup is not finished when the malicious file is removed. It is finished when the site remains clean under repeated checks. Several verification layers were used.

1. WordPress Core Checksums

2. Plugin Checksums

Every installed public plugin was verified against the WordPress.org plugin repository:

3. Upload Directory PHP Check

Uploads are a common hiding place for web shells. A targeted search looked for PHP-like files under wp-content/uploads:

The only PHP file found there was a small index.php placeholder in a logs directory, a common “silence is golden” style file rather than a payload.

4. Database Snippet Review

Because the site used a code-snippet plugin, the database was checked for suspicious stored PHP. This mattered because database-stored snippets can execute during WordPress requests even when the file system looks clean.

The review found seven wpcode snippets. Two were published. They were ordinary snippets: one added noindex behavior for spam-like paths, and one disabled generated image sizes. No snippet contained the reinfection payload or an index.php writer.

5. WordPress Cron Review

The serialized cron option was checked for obvious payload strings, file-writing functions, and malware indicators. It contained normal scheduled hooks for WordPress, LiteSpeed Cache, Wordfence, WooCommerce, Rank Math, and other plugins. It did not contain the reinfection payload.

6. System Persistence Review

The usual respawn locations were checked:

• Root crontab
• freeexams user crontab
• /etc/cron.d
• /etc/cron.hourly
• /etc/cron.daily
• Systemd timers
• Systemd service files
• Shell histories for references to /tmp/httpd.conf

No obvious respawner was found. The active persistence had been the three already-running PHP processes.

7. HTTP Smoke Tests

The live site was checked after the cleanup:

8. Homepage Source Check

The homepage source was fetched with a Googlebot user agent and checked for the payload indicators and visible Japanese spam terms. Nothing matched.

Updateable Security

Permissions Cleanup Without Breaking WordPress Updates

The goal was not to freeze WordPress forever. The goal was to remove the active infection so WordPress could operate normally again. After the fix, index.php was intentionally left as a normal writable-by-owner WordPress file:

A permissions review found one world-writable directory:

That directory was changed to 755. A group of top-level WordPress PHP files also had executable permissions. PHP files do not need executable bits to run through php-fpm, so they were normalized to 644:

After that, there were no world-writable paths in the site tree:

The Clean Bill

Final Wordfence Verification

After the server-side cleanup and command-line verification, a Wordfence Security scan was run from inside WordPress. It came back clean.

Incident Timeline

Incident Timeline

What This Teaches

Lessons Learned

1. A Clean Search Result Does Not Prove a Clean Server

The updated Google screenshot looked much better, but the server still had an active malware process. Search Console cleanup repairs the public index. It does not prove that the backend is clean.

2. A Clean Migration Does Not Remove a Live Server Process

Uploading a clean migration file can fix an infection when the infection lives only inside the WordPress files or database being migrated. It cannot stop a separate process that is already running under the hosting account. That is why the problem persisted after the clean migration attempt in 2025.

3. Immutable Files Are Emergency Brakes, Not Root-Cause Fixes

chattr +i can be useful during an emergency, but it should not become the permanent security model. If a file must be immutable forever to stay clean, something else is still wrong.

4. WP-CLI Checksums Are Excellent for Core and Public Plugins

The core checksum check quickly confirmed that the main WordPress core issue was index.php. Plugin checksums later confirmed that all 11 public plugins matched their expected source files.

5. Reinfection Speed Is Evidence

The clean file was replaced and then reverted almost instantly. That timing ruled out a passive stale file and pointed toward an active writer.

6. Deleted Files Can Still Be Running

The suspicious /tmp/httpd.conf file no longer existed on disk, but PHP was still running it. This is why process inspection mattered as much as file scanning.

7. Database Snippets Must Be Reviewed

Any site with a code-snippet plugin deserves database inspection during a malware cleanup. In this case, the snippets were not the root cause, but checking them closed an important gap.

8. Permission Cleanup Should Be Conservative

The final cleanup did not blindly chmod the entire site. It fixed clearly unsafe items: a world-writable directory and executable bits on top-level PHP files. The site remained compatible with CloudPanel and normal WordPress updates.

Further Reading

Related Guides

These related guides cover practical WordPress, performance, hosting, and implementation topics that connect naturally to site maintenance after a cleanup like this.

Questions

Frequently Asked Questions

Evidence Notes

Evidence Kept and Evidence Removed