WordPress 7.1.2 and 7.1.3 Security Updates: 12 Checks Every Business Should Run

Updating WordPress is the first step. Proving that your website was not already compromised is the part many businesses overlook.

On September 22, 2026, WordPress released version 7.1.2 to address a critical security vulnerability affecting WordPress core.

This is not an ordinary maintenance update. According to the WordPress security team, the vulnerability involves an unauthenticated path traversal issue in page-template resolution. Under certain server and theme conditions, an attacker could potentially cause WordPress to include a readable local PHP file outside the active theme directories, creating a path toward remote code execution (RCE). WordPress recommends that site owners update immediately. For businesses running WordPress websites, however, clicking Update Now should not be the end of the response. A security patch closes a known vulnerability going forward. It does not automatically prove that nobody attempted to exploit the weakness before you installed the fix.

That distinction matters. If your WordPress website generates revenue, collects customer information, processes payments, supports business operations, or represents your company online, this is a good moment to conduct a focused security review.

Here is a practical 12-step response checklist.

First, What Does the WordPress 7.1.2 Vulnerability Mean?

The vulnerability fixed in WordPress 7.1.2 was reported by security researcher Robert Ressl and classified by WordPress as critical severity. The technical description may sound complicated, but the risk can be explained more simply. A path traversal vulnerability can allow an attacker to manipulate the way an application references files and potentially reach files outside the location the application normally expects.

In this case, WordPress says an unauthenticated attacker could, under specific conditions, influence page-template resolution so that a chosen readable local PHP file outside the active theme directories is included. Where the necessary server and theme conditions exist, the issue can lead to remote code execution. Remote code execution is particularly serious because it can potentially allow an attacker to execute code on a vulnerable system. The good news is that WordPress has released a fix.

The important question for website owners is now:

Have you patched, and have you checked whether anything suspicious happened before or around the time you patched?

1. Confirm Your WordPress Core Version

Start with the obvious, but do not assume your site has already updated itself. Log into the WordPress administration dashboard and confirm the version currently installed. Sites running the current 7.1 branch should move to WordPress 7.1.2. WordPress has also made security fixes available for a number of older affected branches. However, WordPress notes that only its most recent release is actively supported, which is another reason organizations should carefully evaluate the risks of remaining on old branches.

For organizations managing several WordPress installations, do not check only the main corporate website.

Include:

• Production websites
• Development and staging environments exposed to the internet
• Marketing microsites
• Campaign landing pages
• Old subdomains
• Customer portals
• Blogs
• Test installations that were never decommissioned

An abandoned WordPress installation can still become an entry point into your infrastructure.

2. Take a Fresh Backup Before Making Major Changes

Before performing significant remediation work, create a new backup of both:

• The WordPress database
• Website files

But there is an important distinction between having a backup and having a recoverable backup. A backup that has never been tested may provide little assurance during an actual incident. Confirm that the backup is accessible, complete and capable of being restored. For business-critical websites, organizations should periodically perform restoration tests rather than discovering during an emergency that backups are incomplete, corrupted or dependent on credentials nobody can locate.

3. Review Every Administrator Account

Compromised administrator accounts are one of the most dangerous forms of persistent access on a WordPress site. Go to the user management section and identify every account with administrative privileges.

Ask:

Who owns this account?

Does this person still work with the organization?

Does this user genuinely require administrator privileges?

Has an unfamiliar administrator appeared recently?

Are several employees sharing one administrator account?

Remove unnecessary accounts and reduce privileges where full administrative access is not required.

If you discover an administrator account that nobody recognizes, treat that as a potential security incident rather than simply deleting the account and moving on.

Investigate how and when it was created.

4. Update Plugins and Themes

Securing WordPress core while ignoring vulnerable plugins and themes leaves a major part of the attack surface untouched.

Review all installed components and update them where appropriate.

Pay particular attention to components that interact directly with users or sensitive functionality, including:

• E-commerce plugins
• Contact and registration forms
• File-upload functionality
• Page builders
• Membership systems
• Authentication plugins
• Backup tools
• Security plugins
• Payment integrations
• API integrations

For business-critical websites, consider testing significant updates in a staging environment before applying them to production.

Security matters, but so does availability.

The objective is to patch quickly without unnecessarily breaking revenue-generating or operationally important functionality.

5. Remove Software You No Longer Use

A deactivated plugin is not necessarily harmless.

If its files remain on the server and those files contain vulnerabilities that can be accessed directly, the software may still increase the site’s attack surface.

The same principle applies to unused themes.

Do not treat WordPress like a software warehouse.

If a plugin or theme is no longer needed, consider removing it completely rather than simply deactivating it.

Every unnecessary component creates another piece of software that must be monitored, patched and trusted.

In cybersecurity, what you remove can sometimes be just as important as what you install.

6. Review Recent File Changes

Patching prevents future exploitation of a known vulnerability. It does not automatically remove malicious files that may already exist.

Review the website’s filesystem for unexpected changes.

Pay attention to:

• Unfamiliar PHP files
• Recently modified files with no known business reason
• PHP files appearing inside upload directories
• Unexpected files in temporary or cache locations
• Modifications to WordPress core files
• Changes to active themes
• Altered plugin files
• Files with unusual or misleading names

Attackers frequently try to make malicious files resemble legitimate application files.

Do not assume that a file is safe simply because its name looks technical.

For important websites, compare application files against known-good versions wherever practical.

7. Review Web, Authentication and Security Logs

Photo: Jefferson Santos / Unsplash

Logs can help answer one of the most important questions after a serious vulnerability disclosure:

Did anyone try to exploit us?

Review available logs for activity around the period before and after patching.

Look for:

• Unusual HTTP requests
• Repeated requests to unexpected file paths
• Suspicious administrator logins
• Authentication attempts from unfamiliar locations
• Sudden increases in failed login attempts
• Requests inconsistent with normal website behavior
• Unexpected changes to users or configuration
• Security alerts
• Malware detections
• Unexplained outbound connections

A single strange log entry does not automatically prove compromise.

Patterns matter.

If suspicious activity is discovered, preserve the relevant logs before making extensive changes. They may become valuable evidence during an incident investigation.

8. Verify That Your Security Controls Actually Work

Many businesses install security tools once and then assume they remain operational forever.

Verify them.

If your environment uses a web application firewall, confirm that it is enabled and receiving traffic.

If you use a WordPress security plugin, check whether:

• Scanning is working
• Alerts are being delivered
• Login protection is active
• File-change monitoring is enabled
• Malware scanning is current
• Firewall rules are functioning

Do the same for hosting-level protections.

A security control that exists only on a configuration screen but is misconfigured, expired or no longer monitoring the site provides false confidence.

9. Strengthen Administrator Access

A patched WordPress installation can still be compromised through stolen credentials.

Review administrator authentication.

At minimum:

• Use strong, unique passwords
• Avoid password reuse
• Enable multi-factor authentication where supported
• Remove shared administrator accounts
• Restrict administrative privileges to people who genuinely require them

Where appropriate, organizations can also consider additional controls such as IP restrictions, identity-provider integration or stronger monitoring of privileged login activity.

Administrator accounts should be treated as privileged identities, not ordinary website accounts.

10. Review Hosting Configuration and File Permissions

WordPress security does not stop at WordPress itself.

The underlying hosting environment matters.

Review file and directory permissions and apply the principle of least privilege.

Avoid unnecessarily broad write permissions.

Where appropriate, consider disabling WordPress’ built-in theme and plugin file editor to reduce the ability to modify application code directly through the administration interface.

Also review:

• PHP configuration
• Server software
• Database exposure
• Hosting control-panel access
• FTP or SFTP accounts
• SSH access
• Old credentials
• Unused databases
• Unnecessary services

A secure WordPress installation sitting on top of a poorly configured server is still a security risk.

11. Test Your Recovery Plan

Security teams often focus heavily on preventing attacks, but recovery capability determines how damaging an incident ultimately becomes.

Ask a simple question:

If this WordPress website became unusable today, how quickly could we restore a trusted version?

Verify:

• When the most recent backup was created
• Where backups are stored
• Whether multiple backup generations exist
• Who can access them
• Whether backups are isolated from the production environment
• How long restoration takes
• Whether restoration has actually been tested

The worst time to discover that your backup strategy does not work is after an attacker has encrypted, deleted or modified production systems.

12. Document What You Did

This final step is routinely overlooked.

Record your response.

At minimum, document:

• Website or system reviewed
• WordPress version before remediation
• Version after remediation
• Date and time of update
• Person who performed the update
• Backup performed
• Accounts reviewed
• Plugins and themes updated
• Security controls checked
• Logs reviewed
• Suspicious activity identified
• Remediation performed
• Outstanding risks
• Required follow-up actions

Documentation turns an informal technical activity into evidence.

For regulated companies, organizations undergoing audits, managed-service providers and businesses with formal cybersecurity processes, that evidence can be extremely valuable.

It also creates accountability.

Instead of saying, “We think the website was updated,” the organization can demonstrate exactly what was done.

When Patching Is Not Enough

Not every WordPress website requires a forensic investigation after every security update.

But certain warning signs should trigger a deeper review.

Escalate the situation if you discover:

• Administrator accounts nobody recognizes
• Unexplained PHP files
• Unexpected website redirects
• Malware or blacklist warnings
• Persistent reinfection after cleanup
• Unusual outbound network traffic
• Unauthorized credential changes
• Unexpected modifications to WordPress core
• Suspicious scheduled tasks or persistence mechanisms
• Security alerts continuing after patching
• Unknown changes to payment or checkout functionality

In these situations, simply deleting the suspicious file and continuing business as usual may destroy evidence without addressing the attacker’s original access method.

A structured incident-response process may be required.

Small Businesses Should Take WordPress Security Seriously

For many small businesses, the WordPress website is no longer “just a website.”

It may process customer enquiries.

It may generate sales.

It may contain customer information.

It may host payment functionality.

It may connect to email marketing platforms, CRM systems, payment providers, analytics tools and other business services.

That makes the website part of the organization’s technology infrastructure.

A compromised WordPress administrator account can therefore become more than a website problem.

Depending on the site’s integrations and configuration, compromise can affect customer trust, privacy, business operations and revenue.

This is why WordPress security should increasingly be approached as a business-risk issue rather than something left entirely to whoever happens to maintain the website.

Security Updates Should Trigger a Process, Not Just a Click

WordPress has done its part by releasing the security fix.

Website owners now have to do theirs.

For most organizations, the immediate priorities are straightforward:

Patch. Verify. Review. Monitor. Document.

The update closes the known WordPress vulnerability, but the surrounding checks provide confidence that your website remains trustworthy.

For a personal blog, that process may take only a few minutes.

For an e-commerce store, membership platform, corporate website or system containing customer information, the review should be more deliberate.

Because the question after a critical security release should never be only:

“Did we update WordPress?”

The better question is:

“Can we demonstrate that the site is patched, secure and showing no evidence of compromise?”

That is the difference between simply maintaining software and managing cybersecurity risk.

---

Official WordPress source: See the WordPress 7.1.2 release documentation for the official security release information and update guidance.

Further guidance: Review the WordPress Hardening guide and the OWASP Logging Cheat Sheet for additional hardening and logging practices.