Remove Malware from Website on cPanel: Safe Fix

Google shows "This site may be hacked" under your domain. Customers visiting from their phones are redirected to a casino website. Or your hosting company emails you saying your account contains malicious PHP files.

These are common signs of a compromised website.

You can often remove malware from a website on cPanel without paying for a cleanup service, provided you have access to the affected files and the hosting server itself is trustworthy.

The order matters. Deleting the first infected file you find rarely solves the whole problem. Attackers frequently leave behind another backdoor, a malicious cron job or an administrator account that lets them return.

Quick answer: Preserve a backup of the infected website, contain the attack, secure your accounts, scan the files, identify every suspicious entry point, rebuild damaged components from trusted sources, and test the website before requesting a Google security review.

This guide covers WordPress, Laravel and ordinary PHP websites on cPanel shared hosting. Most commands are read-only until the cleanup stage.

Important: If your website processes payments, stores sensitive personal information or shows signs of server-level compromise, involve your hosting provider or a qualified incident responder. Cleaning files alone may not address every consequence of a security incident.

The first 30 minutes: confirm the hack and secure access

You do not need to identify the exact malware before starting containment.

First, look for evidence that the website is behaving differently from normal.

Warning sign	What it may indicate
"This site may be hacked" in Google Search	Google detected content suggesting the site was compromised
"This site may harm your computer" or a browser security warning	Malware, harmful downloads or other unsafe content
Unexpected casino, pharmaceutical or gambling pages in Google	Search spam or injected pages
Redirects affecting only mobile visitors	Conditional malicious redirects
Redirects occurring only after clicking a Google result	Referrer-based redirect rules or scripts
Unknown administrator accounts	Unauthorized access to the CMS
Suspicious PHP files appearing in uploads	Possible web shells or executable malware
Hosting suspension or malware notification	The hosting provider detected activity or files requiring investigation

A warning is evidence worth investigating, not definitive proof of how the attacker entered.

Step 1: Preserve a complete backup

Open:

cPanel → Files → Backup

Select Download a Full Account Backup, choose an available destination and generate the backup.

Download the finished archive to a safe location outside the affected hosting account.

Label it clearly:

INFECTED-BACKUP-DO-NOT-RESTORE-WITHOUT-SCANNING

Do not store your only backup inside public_html.

Also download the available partial backups:

• Home Directory
• Each affected MySQL database
• Email forwarders and filters, where relevant

According to cPanel's Backup documentation, a full account backup cannot be automatically restored from the ordinary cPanel interface. A complete automatic restore generally requires WHM access or assistance from the hosting provider.

Partial backups support more targeted recovery, although restoring one can overwrite current data.

Why this matters: An infected backup serves as evidence and a recovery reference. It is not automatically a clean restore point.

If an older, independently verified clean backup exists, preserve that separately too.

For future protection, see cPanel automatic backup to Google Drive.

Step 2: Contain the compromised website

If the website currently distributes malware, redirects visitors to dangerous pages or captures user credentials, restrict public access while investigating.

The safest containment method depends on the hosting configuration.

Ask the host to serve a clean temporary maintenance response, preferably HTTP 503, from outside the compromised application.

Avoid relying on a maintenance page generated by infected PHP code.

Changing nameservers simply to show a maintenance page is usually unnecessary and can disrupt email or other domain services.

If immediate isolation is impossible, ask the host to block the affected site while preserving files and logs.

Step 3: Secure administrator access

Use a clean device and trusted network for administrative work.

Rotate or disable compromised credentials, prioritizing accounts that can change files or DNS:

1. cPanel account and hosting customer portal.
2. SSH, FTP and SFTP accounts.
3. WordPress, Laravel or custom administration accounts.
4. Database users.
5. Domain registrar and DNS management accounts.
6. Relevant email accounts.
7. Deployment credentials and exposed API tokens.

In cPanel, password-management interfaces vary by version and hosting provider.

For WordPress, inspect all administrator accounts. Remove unauthorized accounts only after preserving evidence.

In Google Search Console, open:

Settings → Users and permissions

Review users and verified owners.

An attacker may have added ownership verification through an HTML file, DNS record or another supported verification method. Removing a user from the interface alone may not revoke access if their verification token remains valid.

Remove unauthorized verification methods and verify the legitimate owners retain access.

Rotate critical credentials again after the malicious code has been removed, because an active backdoor may read credentials from configuration files.

Step 4: Preserve logs and identify the likely entry point

Ask the host to retain available access logs, error logs, FTP logs and malware-scanner reports.

Look for:

• Successful logins from unexpected sources.
• File uploads before the first malicious redirect.
• Requests to vulnerable plugin or administration endpoints.
• Unknown changes to scheduled tasks.
• Newly created administrator accounts.
• Suspicious files appearing shortly before the incident.

The goal is to determine what allowed the intrusion.

Without fixing that entry point, even a completely rebuilt website can become infected again.

Scan the website with ImunifyAV, Search Console and SiteCheck

Start with scanners, but do not assume a clean scan proves the entire hosting account is safe.

ImunifyAV and Imunify360

Many cPanel hosting providers offer an Imunify security product, although the exact edition and available controls vary.

Look in:

cPanel → Security → ImunifyAV or Imunify360

Depending on the product and host configuration, you may find:

• Lists of suspicious or infected files.
• Malware signatures.
• Detection timestamps.
• Scan history.
• Options to inspect files.
• Manual or automatic cleaning actions.

The basic ImunifyAV product provides malware scanning. ImunifyAV+ and Imunify360 provide additional cleaning features.

Do not assume every edition has the same buttons.

For example, ImunifyAV+ can clean certain infected files by removing their contents. A file may become empty rather than being restored to its original legitimate code.

That is dangerous when the affected file belongs to an essential plugin, theme or application component.

Before applying automatic cleanup, ensure that a separate backup exists and record every file the scanner flagged.

Where the interface provides a Start scanning button, use it to scan the affected account. Some hosts disable user-initiated scanning.

A detected signature is useful evidence, but it should be reviewed in context.

See the ImunifyAV documentation for the edition-specific behavior.

Google Search Console

Open the affected property in Google Search Console.

Navigate to:

Security & Manual Actions → Security issues

This report may identify:

• Hacked content injection.
• Hacked URL injection.
• Malware.
• Harmful downloads.
• Deceptive pages.
• Other security problems.

Google sometimes provides example URLs that triggered the warning.

Save those URLs and test them later.

The examples are not necessarily a complete list of affected pages. If Google reports five infected URLs, there may be more.

The separate Manual actions report concerns Google Search policy enforcement and should also be checked if search visibility has been affected.

Sucuri SiteCheck

Open:

https://sitecheck.sucuri.net/

Enter the website URL and run the free external scan.

SiteCheck can help identify suspicious public content, known blocklist status and certain website security concerns.

It cannot inspect every server-side PHP file or private database record.

A hidden web shell that only activates when a secret parameter is supplied may remain invisible to an external scanner.

Which scanner should you trust?

Tool	Inspects server files	Automatically repairs malware	Cost
ImunifyAV	Yes, within its scanning scope	Basic edition: no automatic cleanup	Often included by hosts
ImunifyAV+ / Imunify360	Yes	Supported cleanup features	Usually licensed through host
Google Search Console	Reports observed security issues	No	Free
Sucuri SiteCheck	Publicly accessible website content	No	Free external scan

Use more than one source of evidence.

If Search Console shows malicious pages but Imunify reports nothing, continue the investigation instead of declaring the site clean.

Find malicious files and backdoors over SSH

If the hosting provider allows shell access, open:

cPanel → Advanced → Terminal

Otherwise connect through SSH.

The following examples assume that the affected website lives in ~/public_html.

Change that path when the installation uses an addon domain, separate document root or a Laravel project structure.

All commands in this section are investigative. They do not intentionally modify application files.

1. Find recently modified PHP files

Run:

cd ~/public_html

find . -type f -iname '*.php' -mtime -7 -print

This lists PHP files whose contents were modified during the last seven 24-hour periods.

If you know the approximate date of the intrusion, adjust the time range accordingly.

Also check file metadata changes:

find . -type f -iname '*.php' -ctime -7 -print

Important distinction: On Linux, ctime means inode-status change time, not file creation time.

It can change because of permission changes, ownership changes or other metadata operations.

Neither mtime nor ctime reliably proves that a file is malicious. Attackers may manipulate timestamps, and ordinary website updates produce legitimate changes.

Look for unexpected file names, unusual directories and clusters of modifications that do not match authorized maintenance.

2. Search upload directories for executable files

For WordPress:

cd ~/public_html

find wp-content/uploads -type f \( \
  -iname '*.php' -o \
  -iname '*.php[0-9]' -o \
  -iname '*.phtml' -o \
  -iname '*.phar' \
\) -print

A normal media-upload directory should not need publicly executable PHP scripts.

An unfamiliar file such as wp-content/uploads/2026/10/loader.php deserves investigation.

Do not immediately delete every result. Some poorly designed plugins may create files there, although the safer design is to keep executable code outside user-upload locations.

For Laravel, start from the actual project root:

find public -type f \( \
  -iname '*.php' -o \
  -iname '*.phtml' -o \
  -iname '*.phar' \
\) -print

In a standard Laravel installation, public/index.php is the expected application entry point.

Other PHP files require review against the trusted project release.

Also inspect public/storage and the directories exposed by any additional symbolic links.

The correct location depends on the application's storage configuration.

3. Search for suspicious code patterns

Malware may hide executable code behind encoding or compression functions.

Run:

grep -RInE \
  --include='*.php' \
  'eval\(|base64_decode\(|gzinflate\(|str_rot13\(|strrev\(' \
  .

This prints matching file paths and line numbers.

These functions are not automatically malicious.

For example, a legitimate library may use base64_decode() to decode ordinary data.

A stronger warning sign is untrusted request data reaching a dangerous execution function.

You can search for obvious patterns:

grep -RInE \
  --include='*.php' \
  '(eval|assert|system|shell_exec|passthru|exec|popen|proc_open)[[:space:]]*\([[:space:]]*\$_(GET|POST|REQUEST|COOKIE)' \
  .

Review the context of every match.

This command does not find every backdoor. Attackers can disguise code through variable functions, concatenated strings, indirect calls, encoded payloads and other techniques.

Never delete files automatically from grep output.

If a library or application file looks suspicious, compare it with a known-good copy from the official release or trusted Git commit.

4. Check .htaccess, .user.ini and PHP configuration

A malicious redirect may live in .htaccess rather than in PHP code.

Search common configuration files:

find . -type f \( \
  -name '.htaccess' -o \
  -name '.user.ini' -o \
  -name 'php.ini' \
\) -print

Review the results for suspicious rules.

A focused search is:

find . -type f \( \
  -name '.htaccess' -o \
  -name '.user.ini' -o \
  -name 'php.ini' \
\) -exec grep -nHE \
  'HTTP_REFERER|HTTP_USER_AGENT|auto_prepend_file|auto_append_file' \
  {} +

Check for:

• Redirects to unknown domains.
• Rules that only affect Google visitors.
• User-agent checks targeting mobile devices.
• Unexpected PHP files loaded through auto_prepend_file.
• Suspicious code in custom error handlers.
• Configuration pointing to unfamiliar directories.

auto_prepend_file deserves particular attention because PHP can execute the referenced file before the requested script.

However, legitimate applications and security software can also use these directives.

Compare suspicious rules with the original application and hosting configuration before changing them.

5. Inspect cron jobs

In cPanel:

Advanced → Cron Jobs → Current Cron Jobs

With shell access:

crontab -l

Look for tasks you do not recognize.

Examples include jobs that download remote files, execute scripts in temporary directories or run PHP code unrelated to the application.

Do not remove a scheduled task merely because it invokes PHP.

Laravel's scheduler, for example, legitimately runs:

php artisan schedule:run

The relevant question is whether the job belongs to the intended application and points to the correct project.

Check with the hosting provider for scheduled tasks outside your cPanel user's crontab if there is evidence of broader compromise.

6. Search WordPress database content

Malware can be stored in the database even when all infected PHP files have been removed.

Open phpMyAdmin and select the affected database.

First inspect the primary website URLs:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Next inspect administrator candidates and recently registered users:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;

Search posts for suspicious embedded scripts or frames:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
   OR post_content LIKE '%<iframe%';

Replace wp_ with the actual database table prefix.

A script or iframe in a post does not necessarily indicate malware. Trusted embeds and custom content may contain them.

These queries are only initial checks.

Malicious content may also be stored in:

• wp_options
• wp_postmeta
• Widget settings
• Plugin-specific tables
• User metadata
• Custom tables

Serialized PHP data stored in WordPress options must be handled carefully.

Do not run blanket SQL REPLACE() statements against serialized values without a serialization-aware tool. Changing string lengths incorrectly can corrupt those settings.

For Laravel or custom PHP systems, inspect user accounts, administrator-role assignments, settings tables and content modified around the suspected incident.

Also check whether unknown scheduled jobs or automated actions were stored in the database.

Clean infected files: WordPress, Laravel and custom PHP

Once the investigation identifies the compromised components, rebuild them from trusted sources.

Removing one suspicious line from an infected file may leave other changes behind.

A verified clean backup or trusted source release is generally safer than trying to reconstruct compromised code manually.

WordPress: verify and replace core files

If WP-CLI is available, go to the WordPress root:

cd ~/public_html

wp core verify-checksums --include-root

This compares installed WordPress core files with the official WordPress.org checksums.

The --include-root option also warns about unexpected entries in the installation root.

These extra entries are not automatically malicious. Some websites legitimately contain additional files.

Check plugin integrity where possible:

wp plugin verify-checksums --all

The plugin command verifies supported WordPress.org plugins.

Premium plugins, custom plugins and components not covered by official checksums need separate verification against their trusted sources.

A passing core checksum test does not prove the entire website is clean.

It does not verify every upload, database record, custom theme or server configuration file.

Before replacing files:

1. Preserve the infected files and database backup.
2. Record the installed WordPress version and locale.
3. Inventory active themes, plugins and must-use plugins.
4. Obtain fresh files from WordPress.org or legitimate vendors.
5. Confirm compatibility and build the replacement in a clean staging location where possible.

WP-CLI supports:

wp core download --force --skip-content

This downloads and overwrites standard WordPress core files without downloading default themes and plugins.

Critical limitation: It does not guarantee removal of additional malicious files already present in the directories.

For a confirmed compromise, rebuild the core directories from clean source files and review unexpected files separately.

Do not treat a successful WP-CLI download as complete malware removal.

Avoid deleting wp-content, wp-config.php or application-specific files without a verified recovery plan.

Restore themes and plugins from trusted sources

Inspect all installed plugins and themes, including inactive ones.

Replace compromised components with clean official packages or legitimate vendor downloads.

Remove abandoned and unauthorized software.

Nulled or pirated plugins and themes are especially risky because their code cannot be trusted simply because the site appears to work.

For commercial plugins, obtain the package from the original vendor account rather than from an unknown third-party mirror.

Also inspect:

• wp-content/mu-plugins
• wp-content/uploads
• wp-content/cache
• Custom plugin directories
• Theme functions and included PHP files
• Drop-in files such as advanced-cache.php or object-cache.php

Some of these files are legitimate components. Compare them with the intended application configuration before removal.

Reset WordPress authentication keys

Review wp-config.php for unauthorized includes, unusual constants or encoded code.

After securing the application, rotate the WordPress authentication keys and salts.

Generate new values using WordPress's official secret-key service or another trusted source, and update the corresponding definitions in wp-config.php.

This invalidates existing authentication cookies.

Also reset administrator passwords and remove unauthorized administrator access.

Do not expose the generated keys in publicly accessible files or screenshots.

Laravel: rebuild from trusted Git and Composer sources

Laravel cleanup needs a different approach.

A Laravel application typically contains project-specific code, dependencies, environment secrets and persistent storage.

The ideal recovery source is a verified trusted Git commit or previously approved deployment artifact.

Start with read-only checks:

git status --short

Review changes to tracked files:

git diff --name-status

List untracked files not ignored by Git:

git ls-files --others --exclude-standard

These commands help identify unexpected differences from the checked-out revision.

However, Git status is not a complete malware scanner.

Ignored files, database content, generated assets and malicious code already present in a repository or commit may not appear as unexpected changes.

Also inspect application areas outside version control.

Recommended recovery process:

1. Obtain a clean copy of the trusted application release.
2. Verify the source commit and deployment package.
3. Review composer.json, composer.lock and installation scripts.
4. Reinstall dependencies from the trusted lock file.
5. Restore only verified clean persistent files.
6. Rotate exposed credentials.
7. Deploy into a clean application directory after testing.

From the verified clean project directory, a normal production dependency installation may use:

composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

Composer can execute configured scripts and plugins. Do not run it inside an untrusted compromised checkout without first inspecting the project and its dependencies.

Where appropriate, build the deployment package in an isolated trusted environment.

Check the document root.

For a normal Laravel installation, web requests should be served from the application's public directory, not the project root.

The .env, vendor, storage and application source directories should not be directly web-accessible.

Verify:

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/.env

The response must not disclose the environment file.

A 403 or 404 is expected in a properly protected setup. However, an HTTP status code alone is not enough to verify every possible exposure; inspect web-server configuration as well.

Ensure production configuration contains:

APP_DEBUG=false

Laravel warns that enabling debug mode in production can expose sensitive information.

Rotate secrets that may have been exposed, including database credentials, mail credentials and third-party API keys.

Do not automatically regenerate Laravel's APP_KEY.

Changing that key can invalidate encrypted application data, cookies and other protected values.

If the key was exposed, plan the rotation with an understanding of existing encrypted data and available key-rotation support.

For additional hosting considerations, see Deploy Laravel on cPanel.

Remove malicious database records and redirects

Do not stop after cleaning application files.

Remove confirmed malicious records, unauthorized users, injected links, redirects and persistence mechanisms.

Keep copies of affected records for investigation before making destructive database edits.

If attackers created hundreds of spam URLs, ensure the underlying generator or route is removed.

For content that should no longer exist, return an appropriate HTTP 404 or 410 response.

Do not redirect all hacked spam URLs to the homepage simply to hide them.

Finally, check every website hosted under the same cPanel account.

Multiple websites sharing one Unix user and writable directory structure may be affected by the same compromise.

Close the vulnerability and prevent reinfection

Cleaning the visible malware is only half the job.

If the original vulnerability remains, the attacker may return immediately.

Common entry points include:

• Outdated WordPress plugins or themes.
• Vulnerable PHP applications.
• Stolen FTP, SFTP or administrator credentials.
• Unsafe file-upload handlers.
• Exposed environment or backup files.
• Compromised developer devices.
• Incorrect file permissions.
• Unauthorized scheduled jobs.
• Vulnerable applications elsewhere in the same hosting account.

Update supported software

Update the CMS and its extensions from trusted sources.

Use a supported PHP version compatible with the application and still receiving security fixes.

Review the PHP security update guide for cPanel and XAMPP for related considerations.

Test major application upgrades in staging before applying them to production.

Remove unsupported components that cannot be secured.

A newer version is not automatically a safe replacement if it breaks an essential application or introduces incompatible dependencies.

Fix file permissions without breaking ownership

WordPress documentation gives commonly used permission examples such as:

• Directories: 755 or 750.
• Ordinary files: 644 or 640.
• Sensitive configuration files: more restrictive permissions where supported.

The correct permissions depend on how the hosting server runs PHP and which user owns each file.

Avoid automatically running recursive chmod commands across the entire hosting account.

Those commands may change permissions on directories that legitimately require different access controls.

Review ownership and existing permissions first.

For an ordinary file:

ls -l wp-config.php

For a directory:

ls -ld wp-content/uploads

If ownership or access requirements are unclear, consult the hosting provider before making changes.

Do not use 777 permissions as a general solution to upload or cache errors.

Also restrict unnecessary write access to application code.

Block executable PHP files in WordPress uploads

On an Apache 2.4 server where the relevant .htaccess directives are permitted, place the following in:

wp-content/uploads/.htaccess

<FilesMatch "(?i)\.(php[0-9]?|phtml|phar|phps)(\..*)?$">
    Require all denied
</FilesMatch>

This denies direct HTTP access to common PHP-like file extensions in the uploads directory.

It also catches several double-extension patterns.

The rule is only a defense-in-depth measure.

It does not replace server-level file-upload validation, and it will not cover every executable file type or unusual PHP handler configuration.

Important: Nginx does not use .htaccess. LiteSpeed and Apache configurations may vary, and some hosts restrict which directives are permitted.

Confirm the active web server and test the rule.

To perform a harmless test, create a temporary text-only file with a .php extension:

printf 'deny-check\n' > wp-content/uploads/hnt-deny-test.php

Then request it:

curl -sS -o /dev/null -w '%{http_code}\n' \
  https://example.com/wp-content/uploads/hnt-deny-test.php

A 403 response normally indicates that direct access was denied by the rule.

If the response is 200, the intended protection did not work and needs investigation.

Remove the temporary file immediately:

rm -- wp-content/uploads/hnt-deny-test.php

Do not perform this test while malicious executable code remains in the target directory.

For other Apache configuration tasks, see the HeadsNTail .htaccess generator.

Restrict WordPress administration features

Enable two-factor authentication for administrator accounts wherever supported.

WordPress also provides a configuration constant that disables the built-in theme and plugin file editors.

Add this to wp-config.php if it is not already present:

define('DISALLOW_FILE_EDIT', true);

Place it before the line indicating that WordPress editing is complete.

This removes a convenient route for an attacker who compromises an administrator account to edit PHP through the dashboard.

It does not prevent malicious file uploads or attacks through vulnerable plugins.

Restrict unnecessary administrator accounts and review account-recovery settings.

Apply database privileges carefully

For normal WordPress data operations, a database user commonly needs privileges such as SELECT, INSERT, UPDATE and DELETE.

Additional privileges may be required during installation, database migrations, plugin upgrades and schema changes.

Do not remove ALTER or CREATE privileges without verifying the application's operational requirements.

Use least privilege while maintaining a documented process for legitimate database maintenance.

For Laravel, privilege requirements depend on the application's database migrations and runtime behavior.

Keep independent backups and monitor changes

Store backups outside the compromised hosting account.

A useful backup process includes:

• Scheduled file and database backups.
• Protected storage separate from the web server.
• Multiple restore points.
• Restricted access to backup credentials.
• Periodic restore testing.

For file monitoring, start with a simple read-only daily check.

For example:

find /home/USERNAME/public_html -type f -iname '*.php' -mtime -1 -print

Replace USERNAME with the correct hosting account name.

This reports PHP files modified during the last day.

It does not prove infection or detect every attack, but unexpected changes can trigger further investigation.

Configure monitoring only after confirming the correct paths and expected scheduled updates.

The cPanel website security checklist covers additional hardening measures.

Common mistakes that cause repeated infections

Mistake	Why it fails
Restoring an infected backup	The malware returns with the restored files
Removing only index.php malware	Other backdoors remain active
Trusting one antivirus scan	Scanners may miss custom or inactive malware
Deleting files without preserving evidence	The original entry point becomes harder to investigate
Ignoring unknown administrator accounts	The attacker retains legitimate-looking access
Leaving malicious cron jobs active	Scheduled tasks may download malware again
Keeping exposed credentials	The attacker can reconnect after cleanup
Cleaning only one site in a shared account	Another compromised site may reinfect it
Updating software without rebuilding compromised files	Extra malicious files may remain
Rotating secrets before eliminating active backdoors	Malware may capture the replacement credentials

If the same malicious files reappear, investigate persistence rather than repeating the same deletion procedure.

A recurrence may indicate a surviving backdoor, exposed credentials, vulnerable software or a broader account compromise.

Get Google's hacked-site warning removed

After cleanup, test the website from the perspective of different visitors.

A common mistake is checking only the homepage while logged in as the site owner.

Some malware deliberately avoids redirecting administrators.

Test mobile and Google-referrer behavior

Run a request that simulates a mobile visitor arriving from Google:

curl -sS -D - -o /dev/null \
  --referer "https://www.google.com/" \
  --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
  https://example.com/

This prints the response headers from a GET request.

Look for suspicious Location headers or unexpected redirects.

To follow redirects and show the final destination:

curl -sS -L -o /dev/null \
  -w 'HTTP: %{http_code}\nFinal URL: %{url_effective}\n' \
  --referer "https://www.google.com/" \
  --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
  https://example.com/

Repeat the test without the Google referrer and with a desktop user agent.

Compare the results.

The final URL should be your intended destination, not an unfamiliar third-party website.

Check the actual affected URLs listed in Search Console, not only the homepage.

Also inspect HTML output when the original attack involved injected content rather than redirects.

A normal HTTP 200 response is not proof that the returned page is free of malicious JavaScript.

Confirm the site is ready for Google's review

Before requesting a review:

1. Verify every issue listed in Search Console has been addressed.
2. Check affected URLs and related pages for remaining malicious content.
3. Remove unauthorized redirects and spam generators.
4. Verify important application functionality.
5. Ensure Google can access pages it needs to inspect.
6. Confirm that legitimate pages are not accidentally blocked by maintenance rules.
7. Verify the site's security controls are active.
8. Confirm the vulnerable entry point has been fixed.

Do not leave the entire public site blocked by a maintenance rule during review unless Google's instructions for the specific issue require otherwise.

Avoid adding noindex or restrictive robots.txt rules merely to conceal hacked URLs.

These measures do not replace removing malware.

Request a security review

Open:

Google Search Console → Security & Manual Actions → Security issues

Select Request Review when the report offers that option.

Explain:

• What security problem affected the website.
• Which malicious files or content were removed.
• What caused the compromise, if known.
• What changes were made to prevent recurrence.
• How you verified that the site is clean.

Keep the explanation factual.

Do not claim an entry point was fixed if it has not been identified or sufficiently addressed.

Google requires the issues to be fixed throughout the site; cleaning only the example URLs is insufficient.

How long does Google take to remove the warning?

Google's current Search Console guidance says security reviews may take from a few days to a few weeks.

There is no reliable fixed 72-hour guarantee for every case.

The time depends on the nature of the issue and the review process.

Google normally provides status information through Search Console and email.

Do not repeatedly submit new review requests while an existing review is pending.

You can also inspect the domain's status using Google's Safe Browsing Site Status tool:

https://transparencyreport.google.com/safe-browsing/search

Search Console security warnings and manual actions are different processes. Check both reports when relevant.

Monitor the site after the warning disappears

Continue checking for:

• Unexpected PHP file modifications.
• New administrator accounts.
• Unknown cron jobs.
• Suspicious outbound requests.
• Unexpected changes to .htaccess or PHP configuration.
• New spam pages appearing in Google.
• Repeated login attempts.
• Fresh malware alerts.

Keep access and error logs for incident analysis, subject to your host's retention capabilities.

If the site processes customer information, assess whether the incident exposed personal data or credentials and whether contractual or legal notification obligations apply.

If your hosting provider reports evidence of server-level compromise, ordinary cPanel file cleanup may not be sufficient.

When to involve a professional

A professional incident response or hosting-security investigation is appropriate when:

• The website processes payments or sensitive records.
• You cannot identify or eliminate the persistence mechanism.
• Multiple hosting accounts are affected.
• The attacker appears to have server-level access.
• Malware repeatedly returns after a verified clean deployment.
• Critical business data may have been stolen.
• You cannot safely verify or restore the application.

Paid cleanup is not a requirement for every small website infection.

However, free scanners and manual commands have limitations. The right choice depends on the site's risk, technical complexity and available recovery evidence.

FAQ

How do I know if my cPanel website has malware?

Start with Google Search Console's Security issues report, your hosting provider's malware alerts and unexpected website behavior.

Look for unfamiliar redirects, injected spam pages, unknown administrators, executable files in upload directories and suspicious scheduled tasks.

You can also run an available Imunify scanner and Sucuri SiteCheck.

A clean scanner result does not prove that the site is safe. Compare files against trusted application releases and investigate suspicious access logs.

Can I remove malware from a cPanel website for free?

Often, yes.

If the host provides ImunifyAV scanning, Terminal or SSH access, backups and ordinary file-management tools, you may be able to investigate and clean an uncomplicated compromise without buying software.

WordPress.org packages, WP-CLI, Git, Composer, Search Console and Sucuri SiteCheck can assist in the process.

However, free cleanup is not guaranteed to succeed in every case.

A complex intrusion, server-level compromise or sensitive-data incident may require specialist assistance.

Why does my website get infected again after cleaning?

Usually because the attacker still has a way back in.

Common causes include an undiscovered backdoor, a vulnerable plugin, an unauthorized admin account, an exposed password, a malicious cron job or another infected application in the same hosting account.

A cleanup that deletes visible malware without identifying and fixing the entry point may only provide temporary relief.

Investigate repeated changes, compare new files with your clean deployment and ask the host to inspect activity beyond the website directory if necessary.

How long does Google take to remove a malware warning?

After the security problem has been fixed, submit a review through Google Search Console's Security issues report.

Google states that reviews can take a few days to a few weeks.

The duration is not guaranteed, and repeated requests while a review is pending do not help.

Keep the website clean, accessible for verification and free from the security problems described in the report.

---

Sources and official documentation

Google website security and recovery:

• Google Search Console: Security issues report
• Google: This site may be hacked
• Google: This site may harm your computer
• Google web.dev: Quarantine your site
• Google web.dev: Hacked with malware
• Google web.dev: Clean and maintain your site
• Google web.dev: Request a review

cPanel and malware scanning:

• cPanel: Backup documentation
• cPanel: Backup Wizard
• cPanel: Terminal interface
• cPanel: Cron Jobs
• cPanel: Two-Factor Authentication
• ImunifyAV documentation
• Imunify360 user interface
• Sucuri SiteCheck

WordPress and Laravel:

• WordPress: Hardening WordPress
• WordPress: Changing File Permissions
• WP-CLI: Core checksum verification
• WP-CLI: Download WordPress core
• WP-CLI: Plugin checksum verification
• Laravel: Deployment documentation
• OWASP: File Upload Cheat Sheet
• Apache HTTP Server: Upgrading to Apache 2.4