Turkey (Turkish)
Germany (German)
Worldwide (English)
WordPress LayerKernel, theme and plugin behavior.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
WordPress may be running malicious code conditionally if it is being redirected from Google, a mobile device, or a casino/advertisement site at intervals. Safe cleaning; requires inspecting the site in isolation, evidence and backup, core checksum, plugin/theme comparison, database, user, and cron persistence.
Unexpected redirect to casino domain
wp-content/uploads/2026/07/cache.php
base64_decode(gzinflate(...))
Unknown administrator accountThe attacker may appear as a lone configuration file, but can also leave a backdoor, cron, fake plugin, administrator account, or database record to re-infect.
Conditional malware can run based on Google referer, mobile user-agent, cookie, or IP. Administrators may not see issues on the dashboard while visitors are redirected; different client and curl user-agent tests are required.
PHP files in uploads directory, unknown mu-plugin, wp-config/index.php injection, and theme functions.php modifications are common persistence points. However, every base64 encoded file is not malicious; content context should be examined.
WP-CLI core verify-checksums finds core changes but does not clean wp-content. Plugin/theme files should be compared with reliable original packages.
After cleaning, all passwords, WordPress salts, hosting/SSH/FTP/database user IDs should be updated; the current but outdated entry point or stolen password should be corrected.
Deleting all files without live evidence gathering may hide attack source and persistence. Take isolated backup and file timeline first.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: Visitor request is being redirected by a malicious rule or code.
Possible cause: htaccess, PHP, JS, DB or CDN injection.
Meaning: Malware is running with a referer condition.
Possible cause: SEO spam/backdoor conditional code.
Meaning: Executable backdoor may exist in the media directory.
Possible cause: File upload gap or seized account.
Meaning: Aggressive permanent panel access has been created.
Possible cause: Weak password or backdoor.
Meaning: Spam URLs are indexed or cloaking has been applied.
Possible cause: DB content injection or dynamic spam generation.
Meaning: WordPress core file has been modified or is missing.
Possible cause: Malware or half update.
Meaning: Malicious code may be rewritten periodically.
Possible cause: WordPress cron or system cron persistence.
Meaning: Code may be hidden but is not conclusive malware evidence.
Possible cause: Obfuscation or legitimate package.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
wp core verify-checksums --include-rootDisplays unexpected changes in WordPress core and root files.
wp user list --fields=ID,user_login,user_email,roles,user_registeredDetects unknown admin accounts.
wp cron event list --fields=hook,next_run_gmt,recurrenceLists suspicious or unknown scheduled tasks.
find wp-content/uploads -type f -iname '*.php' -o -iname '*.phtml'Finds executable files in the media directory.
grep -RInE 'base64_decode|gzinflate|eval\(|shell_exec|passthru|assert\(' wp-content --include='*.php' | head -n 100Audit candidate codes list; not used for automatic deletion.
find . -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %u:%g %p\n' | sortDisplays files changed in the last seven days in chronological order.
wp plugin verify-checksums --allChecks the checksum status of WordPress.org plugins.
The root cause of the WordPress error is the same, but log paths, PHP settings screens and service management vary depending on the hosting infrastructure used.
File Manager, Imunify/virus scan, Cron Jobs, and Raw Access are used together in cPanel.
cd /home/KULLANICI/public_html && wp core verify-checksums --include-rootPlesk WP Toolkit Security, ImunifyAV, and Scheduled Tasks support the cleaning process.
cd /var/www/vhosts/ALANADI/httpdocs && wp core verify-checksums --include-rootOn a panel-less server, vhost isolation, file timestamps, and service logs are directly reviewed.
find /var/www/html -type f -mtime -7 -ls | head -n 100Isolate the site, obtain evidence/backups, define the scope of infection, compare files with clean sources, and close all persistence points.
Stop visitors from spreading malware; do not delete logs and files.
Save a backup for review and rollback in a separate secure area before cleaning.
wp db export olay-oncesi.sqlClassify changed files with checksum and clean package comparison.
wp core verify-checksums --include-rootUploads PHP, mu-plugins, cron, admin users, wp-config and database options.
wp cron event listReplace suspicious components with a clean official package only; do not use nulled themes/plugins.
WordPress, hosting, FTP, SSH, DB, SMTP passwords and salts must be renewed.
wp config shuffle-saltsMobile user-agent conditional malware or ad script is examined.
curl -A 'Mozilla/5.0 (Linux; Android 13)' -sSIL https://example.com/A referer-based cloaking test is performed.
curl -e 'https://www.google.com/' -sSIL https://example.com/Backdoor, cron, fake admin, and compromised FTP/SSH account remain.
wp cron event listIndexed URLs, sitemap, DB, and Search Console security report are reviewed.
Investigate web user, cron, and exploit endpoint access logs.
find . -type f -mmin -60 -lsMalicious .htaccess, PHP/JS code, database injection, plugin or CDN rule redirection can be created.
Yes; Malware user-agent control can only work with mobile visitors.
No. Checksum core verifies; wp-content, database, user, and cron should also be examined.
Generally, PHP is not expected in the media directory; the file should be carefully examined.
No. It is not definitive proof on its own; the source and behavior of the file should be verified.
WordPress users, hosting panel, FTP/SFTP, SSH, database, SMTP, and API keys.
After removing the root cause and returning correct 404/410 or clean content URLs, Google will re-crawl and fix.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.