How to Fix a Hacked WordPress Site: Malware Removal and Store Recovery (2026)

A hacked WordPress store creates two emergencies at once: someone may still have access to your website, and customers may still be placing orders through it. Deleting the file your scanner flagged doesn’t resolve either problem on its own.

The safer approach is to contain the incident, preserve evidence, remove the attacker’s access, and recover without losing legitimate orders. For a WooCommerce restaurant, that also means checking what reached the kitchen—not just whether the homepage looks normal.

Is Your WordPress Site Hacked? Check the Warning Signs

An unexpected redirect deserves investigation, but it isn’t automatically proof of malware. Incorrect site URLs, caching rules, expired certificates, and broken plugin updates can produce alarming symptoms. The difference is in the evidence: what changed, who changed it, and whether you can explain the behavior.

Look beyond the homepage

Record affected URLs, timestamps, screenshots, and the steps that triggered the problem. Some malicious redirects target only mobile visitors, logged-out users, or people arriving from search results. A normal visit from your administrator account proves very little.

Don’t enter passwords or payment details while investigating a suspicious page. Avoid repeatedly opening malicious destinations; your hosting provider or security specialist can inspect redirects and scripts in a controlled environment.

In WordPress, check Users → All Users for unfamiliar administrators and unexpected role changes. An account you don’t recognize needs verification, especially on sites maintained by several agencies. A legitimate developer account and an attacker-created administrator can look remarkably similar.

On checkout pages, investigate unfamiliar payment fields, new scripts, altered payment instructions, and unexplained gateway changes. Payment-page tampering warrants immediate checkout suspension while you establish what happened.

Check independent signals

Open Google Search Console and look under Security & Manual Actions → Security issues. Browser warnings and Search Console findings can reveal malware, phishing, or injected content, but an empty report doesn’t certify the site as safe.

Check your hosting dashboard and support messages for malware alerts, unusual resource use, unexpected file changes, or outbound spam. Ask where access logs, error logs, and available authentication or activity logs are stored—and how long they’re retained.

A PHP error alone usually says “something broke,” not “someone broke in.” Conversely, a clean scanner result isn’t conclusive: scanners have different coverage, and malicious behavior may depend on visitor conditions, database content, or code outside the scanned directory.

Contain the Attack Without Losing Evidence or Customer Orders

Contact your host immediately. Explain that this is a suspected compromise involving an active WooCommerce store, not simply a broken page. Ask about account isolation, log preservation, snapshots, and signs of activity beyond the WordPress installation.

If checkout integrity is uncertain, stop accepting website payments. A short interruption is preferable to exposing more customers while you investigate. Publish a simple service notice through a trusted channel, with an approved alternative ordering method if one is available.

Restrict access at a trusted layer

Use hosting-level access restrictions or another control outside the compromised WordPress installation where possible. A maintenance plugin may hide the storefront while leaving direct checkout endpoints, APIs, or administrator access reachable.

Coordinate restrictions with your host so that essential payment callbacks aren’t accidentally lost. If complete isolation is necessary, document the cutoff time and reconcile payment events afterward. Also pause scheduled marketing that could send customers into a broken or unsafe checkout.

Preserve the incident before changing it

Before cleanup, request a dated snapshot of website files and the database, plus available access, error, and authentication logs. Record the timezone and each containment action. Preserve evidence promptly, but don’t delay stopping an active threat just to collect a perfect archive.

Store these materials in restricted, encrypted storage—not in a publicly accessible folder beside the website. Incident copies can contain malware, credentials, and personal information. Label them clearly as compromised evidence, not approved for restoration.

A trusted recovery point is different: it has been assessed as predating the compromise and checked for the known indicators. “Yesterday’s backup” isn’t automatically clean.

Protect orders already in progress

Securely record recent order IDs, timestamps, totals, payment transaction references, payment status, and fulfillment status. Include only operational details needed to prevent lost or duplicated orders; don’t create unnecessary copies of customer profiles or addresses.

Cross-check these records against your payment provider and the team handling fulfillment. For restaurants, identify orders already cooking, awaiting pickup, or out for delivery. Keep the recovery ledger access-controlled and agree on a retention period rather than leaving an emergency spreadsheet around indefinitely.

[IMAGE: Incident containment workflow showing checkout suspension, hosting isolation, a restricted evidence snapshot, and a separate ledger of paid and unfulfilled WooCommerce orders]

Find the Entry Point and Choose a Recovery Method

Restoring the visible website without closing the entry point invites a repeat incident. Start a timeline using the earliest suspicious activity, recent software changes, account activity, and hosting alerts. File modification times are clues, not definitive evidence; attackers can alter them.

Common entry points include vulnerable plugins or themes, stolen administrator credentials, exposed hosting access, and compromised computers used to manage the store. An unauthorized administrator may be how the attacker maintains access rather than how they originally entered.

Compare installed software versions with official security advisories and maintenance releases. Check inactive extensions, unused themes, staging installations, and other sites sharing the hosting account. Inactive software still sitting on disk shouldn’t be assumed harmless.

Restore a verified clean backup

A clean backup can shorten recovery when you can establish that it predates the incident. Restore it into an isolated environment first, then patch the vulnerability and verify the installation before allowing public traffic.

The database is the tricky part. Restoring Monday’s database on Thursday can remove Tuesday’s and Wednesday’s legitimate orders, customer changes, refunds, and stock adjustments. Restoring files alone preserves current records but won’t remove malicious database content or unauthorized accounts.

WooCommerce stores may use High-Performance Order Storage, so orders aren’t necessarily contained in the older posts and postmeta tables. Don’t copy a few tables and assume you’ve recovered the business. Order migration and reconciliation need to account for the store’s actual storage configuration and extensions.

Choose cleanup or a clean rebuild

Professional cleanup can preserve current business data while examining files, database records, persistence mechanisms, and account access. It’s especially appropriate when orders are arriving daily and an older database would create substantial reconciliation work.

A clean rebuild is often safer when you can’t trust the existing environment. Install fresh software on a verified environment and migrate only reviewed content and business data—not the entire suspicious installation.

Suspected payment-page tampering, repeated reinfection, or server-level compromise warrants specialist help. If the hosting account itself is compromised, replacing WordPress files inside that account isn’t enough.

Remove WordPress Malware and Close the Security Gap

Perform cleanup in a restricted environment, with preserved evidence and a written change log. If you’re unsure whether a file is legitimate, don’t guess with a delete button. Custom restaurant integrations can contain unusual code without being malicious.

1. Replace executable software with trusted copies

Replace WordPress core with files from the official distribution, following the documented replacement process. Preserve the configuration and site-specific content for separate inspection. Core checksum verification can help identify altered or missing core files, but it doesn’t validate the whole installation.

Reinstall affected plugins and themes from their official distribution channels or the developer’s authenticated customer account. Remove the old extension directory before installing its replacement; simply overwriting files can leave attacker-added files behind.

Move to supported, patched versions and test compatibility. Remove unused extensions and themes after recording what was installed. Avoid unofficial downloads: an unknown source is a poor foundation for a recovery.

2. Inspect files that replacements won’t fix

Review uploads for executable files, strange extensions, and recently created directories. PHP files in a typical uploads directory deserve scrutiny, although context matters. Also inspect must-use plugins, WordPress drop-ins, root-level files, and directories outside the normal installation.

Check wp-config.php, .htaccess where applicable, .user.ini, and relevant server configuration for unauthorized includes, redirects, or execution settings. An injected directive that automatically loads another file can reintroduce malicious code even after core replacement.

Ask the host to inspect sibling sites, temporary directories, and hosting-level scheduled tasks when the scope is unclear. Block script execution in uploads where supported and compatible with the site’s setup; don’t paste server rules blindly between different hosting stacks.

3. Review the database and persistence mechanisms

Inspect administrator accounts, roles, application passwords, site URLs, active plugin settings, widgets, and content containing unexpected scripts or redirects. Review custom-code tools and header/footer injection settings. Those features can store executable or browser-delivered code without modifying a theme file.

Review WordPress scheduled events and WooCommerce Scheduled Actions for unfamiliar callbacks or suspicious activity. Legitimate extensions also create background jobs, so verify ownership before removing them. Database cleanup should be targeted; broad search-and-replace operations can damage serialized settings and legitimate content.

Remove unauthorized accounts and code after documenting them. If an account owns legitimate content, handle content reassignment carefully rather than deleting business records along with the account.

4. Close the entry point and revoke access

Patch or remove the vulnerable component, correct unsafe access permissions, and secure the hosting environment. Restrict known-compromised accounts immediately during containment. Then complete credential rotation from a trusted device after cleanup so fresh secrets aren’t entered into an environment the attacker still controls.

Rotate relevant hosting, SFTP/SSH, WordPress administrator, and database credentials, updating dependent configuration securely. Review email accounts used for password resets, deployment credentials, and stored recovery methods.

Replace exposed payment, email, delivery, POS, and other API secrets; revoke the old credentials at their providers. Regenerate WordPress authentication salts and invalidate sessions. Existing application passwords, API keys, and provider tokens require separate review and revocation.

Deleting suspicious files is only one part of recovery. A stolen credential, hidden scheduled task, or unpatched extension can let the attacker put everything back.

[IMAGE: WordPress cleanup checklist separating core and extension replacement, uploads and configuration inspection, database and scheduled-task review, and credential revocation]

Test WooCommerce Before Reopening Your Store

A functioning homepage isn’t a recovery test. You need to confirm that customers can order safely, money reaches the correct account, and fulfillment receives accurate instructions. Test as a logged-out visitor as well as an administrator.

Reconcile orders before sending anything

Compare WooCommerce records with payment-provider transactions across the incident and recovery window. Match transaction IDs, totals, currency, capture status, and refunds. An authorization isn’t necessarily a captured payment, and a paid transaction without a local order needs investigation—not an automatic second charge.

Check for duplicate orders, missing orders, and payments received while the site was unavailable. Reconcile stock, refunds, and fulfillment separately. If you recreate an order, control automated emails and kitchen notifications so the recovery doesn’t produce a second meal or shipment.

Run a complete ordering test

• Catalog and cart: Check product prices, variations, add-ons, stock, coupons, taxes, delivery charges, and totals on mobile and desktop.
• Checkout and payments: Verify enabled gateways, connected merchant accounts, credentials, payment instructions, and return URLs. Check for unexpected fields or destinations.
• Webhooks and background jobs: Confirm legitimate endpoints, signing-secret configuration where supported, delivery records, and scheduled processing. Review unfamiliar integrations.
• Customer access: Test login, password resets, order history, and account permissions. Confirm one customer cannot access another customer’s order details.
• Emails and fulfillment: Verify sender settings, recipients, order emails, delivery slots, pickup times, and fulfillment notifications.

For a store using FoodMaster’s WooCommerce restaurant ordering system, extend testing to the features you actually run: delivery, pickup, QR table ordering, POS, kitchen display, and automatic printing. Confirm printer routing and table identification, not merely that an order appears in WordPress.

Use your payment provider’s test mode in an isolated environment first. If a live transaction is needed, follow the provider’s rules, use an authorized payment method, and account for fees and any refund. Don’t use real customer cards as test data.

Verify security signals too

Inspect representative pages for injected scripts, unfamiliar network requests, and redirects, including mobile and search-entry visits. Clear site, server, and CDN caches after cleaning the origin so compromised cached pages aren’t still served. Repeat file-integrity and malware checks without treating them as the only evidence.

If Google flagged the site, request a review through Search Console’s Security issues report after remediation. Follow the relevant review process for other warning services or hosting blocks. Document what was fixed; restoring the site doesn’t automatically remove every warning.

Prevent Reinfection and Handle Customer Data Concerns

Recovery should leave you with fewer access paths and better visibility—not just a new security plugin. Give each staff member an individual account with only the permissions their work requires. Kitchen staff rarely need administrator access.

Enable two-factor authentication for privileged WordPress users, hosting, and associated email accounts. Remove abandoned accounts and review agency access. Maintain supported software, test consequential updates in staging, and don’t postpone critical security fixes indefinitely because the restaurant is busy.

Keep encrypted, access-controlled backups off the production hosting account, with retention long enough to offer recovery choices. Test restoration, including recent order reconciliation. A successful backup notification doesn’t prove you can rebuild a working store.

Investigate exposure without making promises

A compromise doesn’t automatically prove customer data was stolen. It also doesn’t justify telling customers that nothing was exposed because orders look normal. Review attacker access, affected dates, database access, payment integration, and available logs; missing logs may limit what you can conclude.

Even when card processing is handled by a payment provider, compromised checkout code may affect what customers see or where information is sent. Contact the provider promptly if payment-page tampering is suspected, and involve qualified privacy or legal support to assess notification duties and deadlines.

Keep an incident-response contact list covering hosting, your developer or security specialist, the payment provider, privacy support, and the person authorized to suspend ordering. Make it available outside WordPress.

Your first-week monitoring checklist

• Review security alerts, new users, role changes, and unexpected file modifications daily.
• Check redirects, checkout behavior, payment destinations, and unfamiliar outbound connections.
• Reconcile orders and payments daily; investigate missing callbacks or duplicate fulfillment.
• Review scheduled tasks, failed logins, email delivery, and hosting resource anomalies.
• Confirm fresh backups complete and validate a restoration in isolation.

Keep heightened monitoring beyond that first week when the incident warrants it. Reopen when you can explain what happened, what access was removed, and how orders were verified—not simply when the warning disappears. That’s the difference between making a hacked store look fixed and returning it to trustworthy operation.