Taking Over WordPress Security: A Senior Developer’s First 48 Hours

Taking over WordPress security should reduce uncertainty before any dramatic production change.

A new developer often inherits unclear access, abandoned users, expired licences and a backlog of updates. Rushing to update everything can destroy evidence or trigger failures. The first job is to establish control and a recoverable baseline.

Secure access and preserve evidence

List every administrative route: WordPress users, hosting, DNS, CDN, registrar, email delivery, analytics and external integrations. Remove access only after ownership is confirmed and a safe replacement exists.

Create and test a backup before high-impact changes. Retain relevant logs and record current versions, active plugins, scheduled tasks and unusual administrator accounts. This snapshot helps distinguish existing compromise from problems introduced during recovery.

Prioritise by exposure and business impact

Not every warning carries equal risk. Rank findings using exploitability, privileges, data sensitivity and the importance of the affected workflow.

• Confirm domain, hosting and administrator ownership
• Rotate exposed credentials through approved account owners
• Review administrator and application-password access
• Check update paths on staging before production
• Inspect unexpected scheduled actions and outbound requests
• Document compensating controls for changes that must wait

Avoid security theatre

Installing another security plugin is not a substitute for understanding the incident. Controls must match the identified attack path and operational reality.

A secure handover leaves the client with clear ownership, an update routine, tested recovery and fewer privileged accounts. It should also state what remains unknown.

A practical next step

Start with an access map and verified backup. Those two artefacts make every later security decision safer and easier to explain.

Establish authority before changing access

Confirm who owns the domain, DNS, hosting, CDN, WordPress administrators, email delivery, backups and connected services. Do not remove accounts solely because a name is unfamiliar. Record the owner and purpose, then revoke access through an agreed process.

Preserve a recoverable baseline

• Create a complete backup and verify that it can be restored
• Record WordPress, PHP, theme and plugin versions
• Export a list of users, roles and application passwords
• Preserve relevant access and error logs
• Document scheduled tasks and unusual outbound connections
• Take changes through staging when the business can support it

Use WP-CLI for a clear inventory

wp core version
wp core verify-checksums
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update
wp user list --fields=ID,user_login,user_email,roles,registered
wp cron event list --fields=hook,next_run_relative,recurrence

Checksum results require interpretation. Premium or modified packages may not have an official checksum, and a clean checksum does not prove that configuration, users or the database are safe. Treat every signal as part of the investigation.

Prioritise findings

Rank each issue by exploitability, privilege, exposed data and operational importance. An abandoned administrator account with active access is different from a minor information disclosure. A vulnerable plugin on an unreachable staging site is different from the same plugin handling live checkout.

• Contain active compromise first
• Patch externally reachable critical issues
• Remove unused software after dependency review
• Rotate credentials through the account owner
• Review persistence mechanisms such as scheduled tasks and must-use plugins
• Document risks that cannot be fixed immediately

Verify recovery

After remediation, test login, publishing, forms, email delivery, checkout and integrations. Confirm that monitoring and backups are operating. Provide a short record of what changed, why it changed and what remains uncertain.

Security work is complete only when access is owned, recovery is tested and future maintenance has a responsible person.

For inherited sites with unclear risk, start with a WordPress rescue assessment.

Implementation checklist

• Rotate privileged access and remove stale users
• Create verified backups before remediation
• Record core, plugin and theme integrity findings
• Patch the highest-risk exposure first
• Test clean deployment and recovery paths

Frequently asked questions

Should every plugin be updated immediately?

Not blindly. Prioritise exploitable exposure, back up first and test changes that affect checkout, membership or integrations.

Is malware scanning enough?

No. Scanning may find modified files but does not explain the entry point, stolen credentials or persistence mechanism.

What proves the site is safer?

Documented access control, verified integrity, patched exposure, working backups, monitoring and a tested recovery process provide stronger evidence than a clean scan alone.

Taking over WordPress security without losing evidence

Taking over WordPress security requires a recoverable baseline, named access owners and documented evidence. Use the official WordPress hardening guidance as a reference, then adapt controls to the site’s actual hosting, plugins and commercial risk.

Hands-on first hour: preserve evidence and establish a baseline

Developer lab: run these commands from a trusted shell after taking a hosting-level snapshot. Do not delete suspicious files until logs and timestamps have been preserved.

# Record versions and active components
wp core version
wp plugin list --status=active --format=table
wp theme list --status=active --format=table

# Verify official WordPress files
wp core verify-checksums
wp plugin verify-checksums --all

# Review administrators and scheduled tasks
wp user list --role=administrator --fields=ID,user_login,user_email,registered
wp cron event list --fields=hook,next_run_gmt,recurrence

A checksum warning is a lead, not automatic proof of compromise. Premium and custom extensions may not have public checksums, while a clean checksum does not cover database injections or stolen accounts.

# Read-only database checks for unexpected options and users
wp option get siteurl
wp option get home
wp option get active_plugins --format=json
wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;"

Containment order

1. Snapshot files, database and access logs.
2. Restrict administrative access and revoke unknown sessions.
3. Rotate hosting, WordPress, database and integration credentials.
4. Replace core and trusted plugins from known packages.
5. Remove persistence only after its entry point is understood.
6. Monitor file changes, logins and outbound traffic after recovery.

In takeover work, I document every change and keep a rollback path. Fast deletion without evidence often leaves the original vulnerability open.

A defensible 48-hour WordPress incident workflow

Full implementation: taking over a compromised or neglected WordPress site is incident response, not routine maintenance. The priorities are preserving evidence, stopping ongoing access, finding persistence, restoring a trusted baseline and proving that the business can operate safely. Deleting the first suspicious file can destroy the evidence needed to understand the entry point.

Hour 0 to 2: establish authority and preserve evidence

Confirm who can authorise hosting, DNS, CDN, email and payment changes. Record the current time, reported symptoms and people with access. Take hosting-level file and database snapshots before remediation, plus copies of relevant web, PHP, authentication and CDN logs. Store them somewhere the compromised application cannot modify.

Do not browse every suspicious URL from an administrator session. Use an isolated test path and avoid executing unknown files. If payment data, personal data or regulated information may be involved, involve the organisation’s legal and incident-response owners early. A developer should not make breach-notification decisions alone.

Hour 2 to 6: contain active access

• Restrict WordPress administration by network or maintenance control where practical.
• Revoke unknown sessions and remove unrecognised administrator access.
• Rotate hosting, SSH, SFTP, database, WordPress and integration credentials in a controlled order.
• Replace exposed API keys and webhook secrets.
• Pause outbound mail or payment actions only when the business owner approves the operational impact.

Credential rotation needs sequencing. Changing the database password before updating WordPress can create an outage, while changing only the WordPress password leaves hosting access untouched. Record every rotated secret and dependent service without placing secret values in the incident log.

Hour 6 to 12: build a trusted inventory

Record WordPress, PHP, server, theme and plugin versions. Export active plugins, must-use plugins, users, scheduled actions and cron hooks. Compare core and repository plugins with official checksums. For commercial or custom code, compare against a known release package or version-control commit.

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_email,registered
wp cron event list --fields=hook,next_run_gmt,recurrence
wp option get active_plugins --format=json
find wp-content/uploads -type f -name "*.php" -print

Interpret results carefully. A checksum mismatch can be a legitimate local change, and a clean checksum does not cover the database, uploads, must-use plugins or stolen credentials. Unexpected PHP in uploads is suspicious, but some systems place generated code outside normal locations. Preserve and investigate before removing it.

Hour 12 to 20: search for persistence

Attackers commonly create more than one way back in. Review recently modified executable files, auto-prepended PHP, unfamiliar must-use plugins, new administrators, changed home or site URLs, scheduled tasks, injected options and unexpected outbound requests. Inspect web-server configuration and writable directories as well as WordPress.

Database inspection should focus on executable or injected content, not random string matching alone. Review active widgets, options loaded on every request, modified templates and recent posts where the symptom appears. Keep queries read-only until the affected records are documented.

wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 30;"
wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 30;"
wp db query "SELECT post_id,meta_key,LENGTH(meta_value) AS bytes FROM wp_postmeta ORDER BY bytes DESC LIMIT 30;"

Hour 20 to 30: rebuild from trusted sources

Replace WordPress core and repository plugins from verified packages rather than editing infected files in place. Reinstall the active theme from a trusted release or repository. Review custom code line by line against the expected version. Remove abandoned components when their purpose and replacement are understood.

Restore only data that has been inspected. A full backup made after compromise can reintroduce persistence, while a very old backup may lose orders and customer changes. Often the safest path is clean application code combined with carefully reviewed current data. Test it in an isolated environment before changing production.

Hour 30 to 38: close the entry point

Remediation is incomplete until the initial access path is addressed. Patch the vulnerable extension, remove leaked credentials, correct file ownership, restrict administrative access and update server components. If the exact entry point cannot be proven, document the plausible paths and apply layered controls to each.

• Minimum required file permissions and ownership.
• MFA for hosting and administrator accounts where supported.
• Rate limits and login protections appropriate to the site.
• Restricted XML-RPC or REST exposure only when the business does not require it.
• Protected backups with tested restoration.
• Central logging that a compromised WordPress process cannot rewrite.

Hour 38 to 44: validate business workflows

A clean homepage is not proof of recovery. Test login, forms, checkout, payment callbacks, subscription renewals, email, scheduled actions, webhooks and administrative editing. Compare order and user counts with the incident baseline. Confirm that analytics and consent tools still behave after code replacement.

Run vulnerability and malware tools as supporting evidence, not as the only evidence. Automated scans miss custom persistence and can flag benign patterns. Pair them with checksum comparison, access review, log analysis and functional tests.

Hour 44 to 48: monitor and hand over

Increase monitoring for new administrators, file changes, failed logins, outbound requests, scheduled-task failures and modified DNS or CDN settings. Set an owner and response path for each alert. Keep the observation period appropriate to the site’s traffic and delayed jobs.

The handover should state what happened, what evidence supports it, what changed, what remains uncertain and what the client must do next. Include credential-rotation status, removed components, patched versions, tests performed and backup restoration instructions. Do not promise that a site is “100% secure”. Security is an operating process, not a permanent state.

Recovery acceptance criteria

1. Trusted code packages are deployed.
2. Unknown access and persistence have been removed.
3. Credentials and exposed secrets are rotated.
4. The entry path is patched or contained.
5. Revenue and communication workflows pass.
6. Backups restore successfully in a test.
7. Monitoring and ownership are active.
8. The incident record supports future review.

My approach is conservative because hurried clean-ups often remove symptoms while leaving the attacker’s access or the original vulnerability intact. A defensible recovery preserves evidence, rebuilds trust and gives the business a clear operating plan after the emergency.

Need a production review?

If this system carries revenue or customer data, I can review the current architecture, reproduce the risky paths and turn the findings into a prioritised implementation plan. Request a technical review.