Staging sites are often abandoned with old plugins, copied administrators and production secrets. If staging shares a database, filesystem user, SFTP key or deployment route, compromising it can undo a clean production rebuild.
Inventory every non-production copy and remove its path back to live systems.
Find all staging copies
Search cPanel/Plesk domains, DNS records, subdirectories, local hosts, backup restores and deployment configuration. Include old staging, dev, test and temporary sslip-style hostnames.
Check search-engine indexes and certificate transparency for forgotten public names without treating those sources as a complete inventory.
Record owner, purpose and last update.
Compare shared infrastructure
Determine whether staging and production share an operating-system user, document parent, database server/user, Redis/object cache, uploads bucket, SMTP, backup destination or CDN token.
A separate hostname is not isolation. One writable account may modify both roots.
Preserve current relationships before rotating them.
Assess the staging compromise
Review web, PHP, SFTP/SSH and panel logs plus files, users, cron and database. Compare indicators/timestamps with production recurrence.
An outdated plugin on staging is a plausible entry point only when version/configuration and request evidence align. Record uncertainty.
Do not expose the infected staging copy for reproduction.
Check network and cache separation
Confirm staging does not share Redis/object-cache prefixes, sessions or CDN cache keys with production. Shared caches can leak data or let one environment alter another’s behaviour.
Use unique database/cache namespaces and credentials. Flush only the affected namespace after preserving incident evidence; a global flush can disrupt unrelated sites.
Verify staging cannot reach internal production-only services through an unrestricted network.
Remove public access
Take staging offline at DNS/CDN and hosting layers or protect it with strong access controls and network restrictions. Basic authentication alone may not protect direct origin or shared PHP access.
Prevent indexing and external callbacks, but do not use robots.txt as security.
Keep evidence in isolated non-executable storage.
Separate credentials and data
Create unique database, SFTP/SSH, WordPress and API credentials for production. Remove production payment, SMTP and customer-service secrets from staging.
Sanitise personal/order data before future non-production copies and restrict who can create them. Rotate secrets copied into old backups or environment files.
Do not send real customer email from staging.
Review deployment direction
Check Git hooks, synchronisation plugins, migration tools and backup restores. A compromised staging site should never push files or database into production.
Secure deployment service accounts, require reviewed builds and make production pulls from a trusted source where architecture permits.
Remove forgotten automatic sync jobs and record their former access.
Control future staging creation
Use an approved provisioning process that creates unique secrets, blocks indexing, disables production mail/payment and records an expiry owner. Copy only sanitised data.
Alert when temporary hostnames remain publicly reachable after their project date. Remove DNS, certificates, storage and user access together so a forgotten origin does not survive.
Do not clone production by copying wp-config.php and the full uploads/database without review.
Rebuild or retire staging
If staging remains needed, rebuild it from maintained code in a separate account/environment and import sanitised data. If not, delete it after the evidence-retention period and remove DNS, certificates and accounts.
Do not archive the infected root inside a public production directory.
Maintain an inventory and expiry date for future temporary environments.
Verify production independence
Confirm staging credentials cannot reach production files/database and production secrets are absent from it. Monitor former staging paths, shared users and deployment changes.
Retest production login, forms, checkout, cron and email after separation. Check sibling backups for old credentials.
Request urgent recovery when staging and production share a user or database. Share the environment map and redacted logs—never production secrets, databases or infected archives publicly.