- MY WEBSITE IS ALREADY COMPROMISED
Malware
Redirects
Spam pages
Unknown users
Reinfection
Hosting suspension
My Website Has Been Hacked →
- I WANT TO PREVENT A COMPROMISE
Security audit
Vulnerability remediation
Hardening
Custom-code review
Ongoing protection
Book My $500 Security Audit →
WordPress security backed by WordPress engineering
WordPress core
Plugins & themes
Custom PHP
AJAX / REST
Capabilities & roles
Database
WooCommerce
Server & hosting
Common WordPress Security Problems We Investigate
These are the symptoms site owners actually arrive with. Each one can have more than one cause, which is why investigation comes before cleanup.
Unexpected Redirects
Visitors are sent to spam, scam or unrelated domains, sometimes only on mobile, search traffic or selected pages.
Spam Pages in Google
Search results show casino, pharma, Japanese-keyword or other spam URLs and titles that are not visible in the normal WordPress admin.
Malware Keeps Coming Back
Files are cleaned, but malicious code reappears because the entry point, stolen credentials, hidden backdoor or persistence mechanism remains.
Unknown Administrator Accounts
New privileged users appear without authorization, or legitimate admin accounts show unexpected changes.
Injected JavaScript or PHP
Unexpected scripts, obfuscated code, unfamiliar PHP files or modified legitimate files appear in themes, plugins, uploads or other locations.
Hosting Account Suspended
A host disables the website because it detects malware, phishing, outbound spam, resource abuse or infected files.
WordPress Admin Access Problems
Passwords, emails or privileges change unexpectedly, or administrators are locked out after a compromise.
High CPU / Resource Usage
Malicious jobs, bots, cryptomining, spam processes or infected scripts can create abnormal server load.
Server Sending Spam Email
A compromised website or account may be abused to send unauthorized email, damaging deliverability or causing hosting restrictions.
.htaccess / Rewrite Rules Changing
Redirect or access rules repeatedly change, sometimes recreating malicious behavior after a basic cleanup.
Checkout or Customer Account Anomalies
WooCommerce stores may show suspicious checkout behavior, unauthorized modifications, fake users, injected scripts or compromised integrations.
Security Scanner Alerts With No Clear Cause
Automated scanners can identify suspicious files or known vulnerabilities, but determining exploitability, root cause and safe remediation may require engineering review.
We Do Not Just Run a Malware Scanner
A scanner is useful evidence, not the entire investigation. The objective is not to make a scanner show green — it is to understand what happened, remove malicious persistence, close the route back in and verify the site still works correctly.
BASIC CLEANUP
Scan
↓
Delete flagged files
↓
Install security plugin
↓
Assume resolved
The symptoms are gone. The cause has not been established.
SLEEKALGO
01
Contain
02
Investigate
03
Identify entry point
04
Find persistence
05
Clean
06
Patch
07
Harden
08
Verify
09
Monitor
Two stages a scanner cannot perform — identify entry point and find persistence — are what determine whether the problem returns.
What We Actually Inspect
Eight layers, each capable of holding a cause or a persistence mechanism that the others do not reveal.
LAYER 01
WordPress Core Integrity
Check for unexpected or modified core files and, where appropriate, compare known WordPress core files against trusted distributions and checksums. Core changes need context: a mismatch is evidence to investigate, not automatically proof of malware.
LAYER 02
·
PRIORITY
Plugins & Themes
Review versions, known vulnerabilities, abandoned components, suspicious modifications, unexpected executable files, vulnerable dependencies and components that can no longer be safely maintained.
LAYER 03
·
PRIORITY
Custom PHP / Plugin Code
Review application-specific code paths for authorization mistakes, missing nonce checks, unsafe database access, input handling, output escaping, file handling and insecure AJAX/REST behavior where in scope.
LAYER 04
·
PRIORITY
WordPress Database
Inspect suspicious options, injected scripts and content, rogue users, altered settings, spam URLs or other persistence that may not exist as an obvious file on disk.
LAYER 05
·
PRIORITY
Users, Roles & Authentication
Review privileged users, unexpected role changes, weak access paths and whether administrator, hosting or API credentials may require rotation.
LAYER 06
·
PRIORITY
Scheduled Tasks
Inspect WordPress cron and relevant scheduled jobs for suspicious or unexpected tasks capable of recreating deleted malware or repeatedly calling attacker-controlled endpoints.
LAYER 07
·
PRIORITY
Web Server / Hosting Layer
Review relevant server rules, logs, file ownership and permissions, PHP configuration, exposed services and neighboring account risk where access and hosting architecture allow.
LAYER 08
Integrations & Secrets
Review exposed API keys, webhooks, application passwords, SMTP credentials and third-party integrations relevant to the incident or security posture.
WORDPRESS FILESYSTEM & DATABASE MAP
Malware Can Hide in More Places Than You Think
A file-only cleanup examines a fraction of the places persistence can live. Nine locations, each requiring a different kind of inspection.
INSTALLATION ROOT
Files, configuration, database and scheduled jobs each need separate examination. So does the account the site shares.
FILES
DATABASE
SCHEDULE
NEIGHBORS
wp-content/uploads/
Unexpected executable or disguised files can appear in media directories. On many sites, PHP execution in upload locations is unnecessary and can be restricted at the server layer when compatible with the stack.
mu-plugins/
Must-use plugins load automatically and may be overlooked in quick cleanups. Unexpected files here deserve investigation.
themes/
functions.php, templates and unfamiliar PHP files can contain injected code or attacker persistence.
plugins/
Attackers may modify legitimate plugin files, add new files, abuse writable code, or exploit a vulnerable component without leaving a simple scanner signature.
wp-config.php
Unexpected code, altered settings or exposed credentials can create both compromise and persistence risk.
.htaccess / server rules
Injected rewrite rules can create conditional redirects, hide malicious behavior or interfere with normal access.
database
Malicious scripts, spam content, modified options, rogue users and payloads can persist without an obvious malicious PHP file.
WP-Cron / scheduled jobs
Scheduled persistence may recreate malicious files, accounts or content after a superficial cleanup.
server / sibling sites
On shared accounts or poorly isolated environments, another compromised application can sometimes reinfect a cleaned WordPress installation.
Why Does WordPress Malware Keep Coming Back?
Malware often returns because visible symptoms were removed while the original vulnerability or persistence mechanism remained. Reinfection can also come from credentials or infrastructure outside the WordPress codebase.
NINE COMMON ROOT CAUSES
01
Vulnerable plugin or theme remains installed.
02
Compromised administrator, hosting, FTP/SFTP or API credentials were never rotated.
03
A hidden backdoor or modified legitimate file was missed.
04
A malicious scheduled task recreates deleted files or users.
05
An abandoned plugin has no safe vendor patch.
06
Custom code still contains the exploitable authorization or input-handling flaw.
07
Another website under the same hosting account is compromised.
08
An infected backup, deployment package or developer machine reintroduces malicious files.
09
Incorrect permissions or server configuration leave unnecessary write or execute paths exposed.
We do not stop when the malware disappears. We look for why it was possible and what could bring it back.
WordPress Vulnerability Remediation — Detection Is Only the Start
A vulnerability alert is useful only if somebody decides what to do about it without breaking the business. Five situations, five different responses.
VULNERABILITY IDENTIFIED
The right response depends on whether a safe patch exists, whether the feature is genuinely exposed, and whether compromise has already occurred.
PATH A
Patch Available
Update the affected component, account for compatibility risk, test the site and verify the vulnerable version or path is no longer exposed.
UPDATE → TEST → VERIFY
PATH B
No Vendor Patch Yet
Assess the vulnerable functionality, exposure and exploit conditions. Depending on the case, restrict or disable the affected feature, add a temporary mitigation, replace the component or remove it.
ASSESS → MITIGATE
PATH C · ENGINEERING
Custom Code Vulnerability
Inspect the vulnerable code path, remediate the authorization, input, output, file or database issue, test the affected business functionality and deploy safely.
INSPECT → REMEDIATE
PATH D
Abandoned Plugin / Theme
Evaluate whether the component should be replaced, isolated, rewritten or removed rather than leaving an unmaintained dependency in the attack surface.
REPLACE → REMOVE
PATH E · ESCALATION
Compromised Component
Do not rely only on updating. Investigate whether malicious modifications, users, scheduled tasks or database persistence remain after the software is patched.
PATCH → INVESTIGATE
Custom Code Is Part of Your Attack Surface
Security plugins can detect many known issues. They cannot automatically understand the authorization and business logic of every custom plugin, API endpoint or WooCommerce customization.
WHAT A SECURE REQUEST PATH LOOKS LIKE
Request
Nonce / auth
Capability / ownership
Validation
Business action
Escaped output
A nonce mitigates certain request-forgery and replay scenarios. It is not an authorization system — capability and ownership checks remain necessary. A security plugin cannot know which capability your custom endpoint should have required.
REQUIRES · CAPABILITY CHECK
AJAX Actions
Is the request authenticated where required? Is capability or ownership checked, or can a lower-privilege user trigger an administrative action?
REQUIRES · AUTHORIZATION
REST API Endpoints
Does the permission callback actually enforce who can read or change the resource? Are object-level authorization checks present?
REQUIRES · NONCE + CAPABILITY
Admin Actions
Are nonces used to protect state-changing browser requests, and are capabilities checked separately? A nonce is not an authorization system by itself.
REQUIRES · PREPARED QUERIES
Database Queries
Is untrusted input safely handled with appropriate WordPress APIs and prepared queries? Are identifiers and dynamic query structures constrained?
REQUIRES · VALIDATION
File Uploads
Are file types, content, filenames, destinations and execution behavior controlled rather than trusting extensions alone?
REQUIRES · CONTEXT ESCAPING
Output Rendering
Is dynamic output escaped for the correct context to reduce cross-site scripting risk?
REQUIRES · TYPE VALIDATION
Input Handling
Is input validated and sanitized according to its intended type and use rather than relying on a single generic sanitization step?
REQUIRES · SERVER-SIDE AUTHORIZATION
WooCommerce Business Logic
Can pricing, discounts, order actions, account data or privileged store operations be manipulated through client-controlled values or insufficient authorization?
Security Hardening After Cleanup
Hardening should be appropriate to the website. We do not blindly disable WordPress features that legitimate plugins, APIs, mobile apps or integrations require.
Privileged Access
Remove unused privileged accounts, enforce least privilege, strengthen administrator authentication and use 2FA where appropriate.
Credential & Secret Rotation
Rotate credentials, WordPress salts and security keys, and exposed API or integration secrets when compromise scope suggests they may be affected.
Dashboard File Editing
Disable built-in theme and plugin file editing where it is not required as part of the operational workflow.
File Permissions & Execution
Correct unsafe ownership and permissions, and restrict executable code in locations that should contain static or user-uploaded content where the server stack allows.
XML-RPC / API Exposure
Restrict unnecessary functionality when the site does not depend on it, while preserving integrations that legitimately require access.
Login & Bot Abuse Controls
Apply rate limiting, bot or WAF rules, or other controls appropriate to credential stuffing, brute-force or abusive traffic patterns.
Supported Software Stack
Keep WordPress, plugins, themes, PHP and server components within supported and security-maintained versions where practical.
Remove Dead Attack Surface
Delete unused themes and plugins, abandoned components, stale users and unnecessary integrations rather than simply deactivating everything indefinitely.
Backups & Recovery
Maintain tested, protected backups and a recovery path that does not depend on restoring an already compromised snapshot.
Monitoring & Change Visibility
Use vulnerability, uptime, site-health, file-change or security monitoring appropriate to the site so future problems are detected earlier.
WooCommerce Security Needs Extra Care
WooCommerce sites add customer accounts, order data, payment integrations, webhooks, APIs, store-manager privileges and often more custom code. Security work must protect those workflows without casually breaking checkout or fulfillment.
SECURITY CHECKPOINTS ACROSS THE STORE FLOW
01
→
Customer
02
→
Storefront
03
→
Checkout
04
→
Payment integration
05
→
Webhook / API
06
→
Order / admin
Customer & Account Security
Review privileged roles, account abuse, authentication and access to customer and order data.
Checkout & Front-End Scripts
Investigate unexpected script injection and changes around checkout, cart and account flows. We do not make unsupported claims about payment-card compromise without evidence.
Payment Integrations
Review plugin versions, configuration, webhook endpoints and exposed credentials relevant to the payment architecture. Payment gateways typically handle sensitive card data outside WordPress, but the integration still needs secure configuration.
Webhooks & APIs
Validate authentication and signatures where supported, endpoint authorization, replay and abuse considerations, and secrets used by connected systems.
Custom Pricing / Order Logic
Review custom endpoints and server-side validation so client-controlled values cannot improperly alter prices, discounts, order state or privileged actions.
Incident Recovery: From Compromised to Trusted Again
Seven stages. Evidence is preserved where practical before destructive cleanup, because scope cannot be established from a site that has already been wiped.
01
→
Triage & Contain
Preserve useful evidence where possible, identify active malicious behavior and reduce immediate exposure without destroying information needed for investigation.
02
→
Investigate
Review symptoms, files, database, users, logs, components, scheduled tasks and relevant infrastructure to determine scope and likely entry and persistence paths.
03
→
Clean
Remove malicious files, code, content and users, and restore affected legitimate components from trusted sources or known-good versions where appropriate.
04
→
Patch the Cause
Update, replace, restrict or repair the vulnerable component, code or configuration and rotate affected credentials and secrets.
05
→
Harden
Reduce unnecessary attack surface and implement controls appropriate to the site and hosting environment.
06
→
Verify
Re-scan, inspect suspicious areas, test key WordPress and WooCommerce functionality and confirm obvious indicators of compromise are resolved.
07
→
Monitor
Watch the recovered site for recurrence, new vulnerability alerts and abnormal behavior, ideally through an ongoing maintenance and security plan.
BEFORE AN INCIDENT · FIXED PRICE
Complete WordPress Security Audit — $500
Not every customer arrives after an incident. The audit puts an engineer on the site before a weakness becomes an emergency, covering the WordPress application and the relevant hosting environment accessible within the agreed scope.
$500
one-time
01
Technical Security Review
02
Prioritized Findings
03
Remediation Roadmap
04
Quick Fixes Included
01
Technical WordPress + hosting security assessment
02
Prioritized security findings and remediation roadmap
03
Quick, low-risk fixes included at no additional charge
ALREADY HACKED?
THE AUDIT COVERS
WordPress, plugin and theme version and vulnerability review
Privileged users, roles and access paths
Custom plugin and theme code review for high-risk flows where included in scope
Authentication, admin and API exposure review
File permissions and unexpected executable locations
WordPress configuration and sensitive file exposure
WooCommerce, payment, webhook and integration security considerations
Backup and recovery posture
Logging and monitoring visibility
Prioritized remediation plan separating urgent risks from hardening improvements
INCLUDED AT NO ADDITIONAL CHARGE
Quick, Low-Risk Security Fixes Included at No Additional Charge
If we discover a small security issue that is safe and practical to correct while auditing the website, we will fix it rather than charging separately just to make a minor change.
EXAMPLES MAY INCLUDE
Removing an unused privileged account
Disabling dashboard file editing
Correcting simple file permissions
Removing unused plugins/themes
Rotating WordPress security keys/salts
Straightforward configuration hardening
Updating an obviously vulnerable component where compatibility risk is minimal
Larger remediation is quoted separately.
Malware recovery, hacked-site cleanup, significant custom-code remediation, complex server work, component replacement or fixes requiring substantial development/testing are not included in the fixed $500 audit.
Ongoing Protection After the Security Work
A one-time cleanup or audit reduces current risk; it does not freeze WordPress in time. New plugin vulnerabilities, updates, credential incidents and infrastructure changes continue after the project.
SECURITY REMEDIATION · THIS PROJECT
INVESTIGATE
CLEAN
PATCH
HARDEN
VERIFY
WORDPRESS MAINTENANCE & SUPPORT · CONTINUOUS
MONITOR
UPDATE
DETECT VULNERABILITIES
BACK UP
SUPPORT
IMPROVE
Why SleekAlgo for WordPress Security?
THE CENTRAL DIFFERENCE
WordPress Engineering + Security
We understand the application being secured: hooks, plugins, themes, database behavior, REST and AJAX, WooCommerce and custom code.
Root-Cause Mindset
A successful cleanup should answer more than “what file was infected?” We look for entry points, persistence, affected credentials and vulnerable components.
Custom Code Capability
When the problem is inside custom functionality, we can inspect and remediate the code rather than telling the customer to wait for a plugin vendor.
Careful Remediation
Security changes can break business workflows. We test important functionality and avoid blanket hardening rules that conflict with legitimate site requirements.
Clear Next Actions
Findings should translate into prioritized fixes: compromise response, urgent vulnerability remediation, hardening and ongoing monitoring.
Long-Term WordPress Support
After the immediate problem is resolved, the same WordPress team can maintain and improve the site instead of handing it back without a continuity plan.
WordPress Security FAQ
Symptoms rarely have one certain cause. These answers describe what each can indicate and what needs investigating.
Unexpected redirects can indicate injected JavaScript or PHP, malicious database content, altered rewrite rules, a compromised plugin or theme, or another issue. Some attacks are conditional and only redirect mobile visitors, search traffic or selected users, so the site needs investigation rather than assuming a single cause.
Common reasons include an unpatched vulnerable component, compromised credentials, a hidden backdoor, malicious scheduled task, infected backup or deployment source, unsafe custom code, or another compromised site in the same hosting environment. Removing visible malware without closing the route back in can lead to reinfection.
A compromised site can inject or dynamically serve spam content and URLs, modify metadata or conditionally show different output to crawlers. Search indexes can also retain previously discovered spam URLs after cleanup, so both the website and the search-engine cleanup process may need attention.
Treat it as an incident: investigate and clean the compromise, remediate the entry point, verify the site and then use the appropriate Google or Search Console review process once the affected content or behavior is genuinely resolved.
An unexpected privileged user can be evidence of compromise or an unauthorized operational change. Removing the account is not enough if you do not determine how it was created, review other privileged users and rotate affected credentials.
Yes. Vulnerable, outdated, abandoned or poorly coded plugins can create exploitable attack paths. The appropriate response depends on whether a secure update exists, whether the feature is actually exposed, and whether compromise has already occurred.
Yes. Keeping software current is important but does not eliminate risks such as stolen credentials, vulnerable custom code, insecure server configuration, supply-chain issues, newly disclosed vulnerabilities, unsafe integrations or application-logic flaws.
Security plugins can provide valuable scanning, firewall, login and monitoring controls. They are one layer, not a substitute for secure code, supported components, correct access control, safe server configuration and proper incident investigation.
If the website does not use features or integrations that rely on XML-RPC, restricting unnecessary access may reduce exposure. It should not be disabled blindly because some legitimate applications and workflows may still depend on it.
Backdoors can be hidden in modified legitimate files, unfamiliar PHP files, plugins, themes, uploads, must-use plugins, database content, scheduled tasks or server configuration. A basic scanner may help, but reliable investigation requires looking at the wider compromise and persistence paths.
Hosts may suspend a compromised site when they detect malicious files, phishing or spam activity, outbound email abuse, resource consumption or behavior that threatens infrastructure or other customers. Recovery usually requires cleaning the site and satisfying the host’s reactivation requirements.
Yes. We can review in-scope custom code for issues such as missing capability checks, insecure AJAX or REST actions, nonce misuse, unsafe database queries, weak file handling, improper input validation and sanitization, and incorrect output escaping, then remediate and test the affected functionality.
Yes. WooCommerce introduces customer accounts, order data, payment integrations, webhooks, APIs and often additional plugins and custom code. Security work should examine those layers without assuming that every incident involves payment-card data.
Often recovery is still possible, but it depends on the damage, available server access and whether legitimate files and data can be reconstructed from trusted sources. A known-clean backup usually makes recovery safer and faster, but restoring a backup alone does not fix the vulnerability that caused the compromise.
Unexpected repeated changes can indicate malware, a plugin or server process rewriting rules, or another configuration issue. If malicious code is recreating the file, simply replacing .htaccess will not resolve the persistence mechanism.
High resource usage can come from legitimate traffic, inefficient plugins or database work, aggressive bots, scheduled jobs or malicious activity. Security investigation should correlate the load with processes, requests, files, logs and recent changes instead of assuming every performance spike is a hack. Where the cause turns out to be inefficiency rather than compromise, page speed optimization may be the more useful path.
Yes. Injected scripts, modified options, spam content, rogue users and attacker-controlled settings can persist in the database. File-only cleanup may therefore miss part of a compromise.
Malware removal addresses malicious code or content already present. Hardening reduces future attack surface through access controls, software hygiene, configuration, permissions, monitoring and other preventive measures. A compromised site often needs both remediation and hardening.
No responsible provider can guarantee that. Security is risk reduction, not absolute immunity. The goal is to remove known compromise, close identified weaknesses, reduce attack surface, improve detection and maintain the site as new vulnerabilities and threats emerge.
The audit reviews the WordPress installation and the relevant hosting/security environment within scope, including core and file integrity, plugins and themes, users and authentication, database and persistence risks, configuration, scheduled tasks, common hidden execution locations, targeted custom-code risks, WooCommerce and integrations where applicable, and backup, recovery and monitoring readiness. You receive a prioritized technical report and a remediation roadmap.
Yes — quick, low-risk security fixes that can be safely completed during the audit are included at no additional charge. The audit does not include open-ended remediation such as malware recovery, significant custom-code changes, complex server work, component replacement or fixes requiring substantial testing and development; those are documented and quoted separately based on the findings.
TWO WAYS TO START
Secure the WordPress Website — and the Code Behind It
Whether the site is already compromised or you want to find weaknesses before an attacker does, bring in a WordPress engineering team that can investigate beyond the scanner and fix what it finds.
INVESTIGATE · REMEDIATE · HARDEN · VERIFY · MONITOR