Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Persistence Reinfection

An Old Staging Site Is the Entry Point for Repeated Malware

Find and contain an abandoned WordPress staging site that reinfects production through shared credentials, files or databases.

Production is patched, yet malicious files return. A forgotten staging subdomain still runs an old WordPress core, vulnerable plugin or copied administrator account. If it shares hosting ownership, database credentials or deployment paths, compromise can move back into production.

Treat staging as a full application, not a harmless duplicate hidden from search.

Discover every staging copy

Inventory subdomains, addon domains, directories, databases, DNS records, SSL certificates and hosting backups. Search control-panel document roots rather than relying only on visible links.

Check names beyond staging: dev, test, old, backup, date-stamped directories and temporary migration hosts.

Do not probe domains or servers you do not own. Confirm account scope with the host.

Preserve and restrict access

If an abandoned site is infected, take a filesystem/database snapshot and immediately restrict it at the web server or hosting layer. A noindex tag is not security and does not stop bots.

Avoid logging into its WordPress dashboard from a normal browser. Work through recovery access or an isolated copy.

Keep a clean static response so monitoring and staff do not mistake the subdomain for an outage.

Compare compromise indicators

Hash suspicious files and compare paths, payload strings and modification times with production. Review access logs for the vulnerable endpoint and subsequent writes.

Matching payloads support a relationship but do not prove direction. Both sites may have been compromised through a shared panel account.

Correlate with SFTP/panel sessions, cron and filesystem ownership.

Identify shared trust

Check whether staging and production share:

  • WordPress administrator passwords;
  • database user or database;
  • salts and authentication keys;
  • SFTP/deployment credentials;
  • writable parent directory;
  • object cache/database prefix;
  • webhook or API secrets.

Separate each environment. Rotating production secrets while staging keeps the same compromised values can undermine the repair.

Decide whether to rebuild or retire

If staging is no longer needed, preserve required evidence/data and remove its public DNS/virtual host and files through a controlled, recoverable process.

If needed, rebuild from reviewed production code and a sanitised database. Update all components, restrict access, block email/payment side effects and set an accountable owner.

Do not clone live customer/order data casually. Apply privacy and retention requirements.

Prevent staging from affecting real customers

Replace production payment keys with sandbox credentials, redirect outgoing mail to an approved test mailbox and disable live webhooks, fulfilment and analytics. Use environment-specific configuration rather than editing values after every clone.

Confirm search engines receive authentication or a non-indexable restricted response, not just a robots.txt hint. A public staging copy can expose personal data and duplicate content even when it is not the infection source.

Clean the account boundary

Inspect all sibling sites, hosting cron, PHP configuration, users and deployment artefacts. Replace compromised trusted packages and remove backdoors/database persistence.

Patch the original vulnerable component and rotate affected access after securing administrator devices.

Correct filesystem permissions so staging cannot write into production.

Verify isolation and non-recurrence

Test that the retired site no longer resolves or the rebuilt site requires approved access. Confirm it cannot send real emails, process payments or be indexed.

Monitor production hashes and account logs beyond the previous reinfection interval. Run normal deployment and backup jobs to ensure they do not restore the old copy.

Retest after the next deployment.

When specialist cleanup helps

Request an assessment when staging shares databases, permissions or deployment automation with production. Send the subdomain names and timeline without credentials.

A durable repair removes the forgotten entry, separates environments and proves production remains stable after scheduled and deployment activity.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident