Securing WordPress: the mandatory program after four security updates in 41 days

Between September 17 and October 28, 2026, WordPress released four security updates for the core. The most recent, version 7.1.4, fixes 22 security vulnerabilities, and one of them lies in the update itself: In the few seconds in which WordPress unpacks the new files, attackers could under certain circumstances execute code on the server. The US agency CISA added this vulnerability to its list of actively exploited vulnerabilities on November 3.

For about ten years, the WordPress security team received 20 to 30 reports a month; in July 2026 it was 450, and in August 773.

In this guide, you will go through the mandatory program for your site: which updates run on their own, which accounts and plug-ins can go, what a usable backup looks like, and which values matter on the server. It is based on the hardening rules in the official WordPress documentation and the recommendations of the BSI.

Which updates does WordPress install on its own?

Security and maintenance updates for the core are installed by WordPress automatically, as are translations. Since version 5.6, new installations also receive the major version upgrades, as long as WordPress does not detect version control in the folder. Plug-ins and themes, on the other hand, are only updated by WordPress on its own in exceptional cases, for example when the security team releases a critical fix; this is stated in the guide to updating.

For plug-ins, since WordPress 5.5 you switch on automatic updating yourself: in the list under "Plugins" via the link in the column for automatic updates, or for several plug-ins at once via the bulk actions above the table. For themes, the switch is located in the detail view under "Appearance". WordPress then checks for new versions twice a day and sends you an email after each attempt, even if an update fails.

If the switches are missing, according to the WordPress help they have usually been disabled by the hoster or a plug-in.

WordPress actively maintains only the latest version. The team nevertheless backported the fixes from 7.1.4 all the way down to version 4.7; for 4.6 and older, no more security updates will be released.

Who is allowed to log in to your site?

Every account with write permissions is a potential entry point. In the list of bugs that WordPress 7.1.4 fixes, eight entries require an account with at least the Contributor role, and one each requires the Author or Editor role. Contributors write their own posts without publishing them, Authors publish their own, Editors also publish other people's posts, and Subscribers only manage their profile, according to the overview of roles.

It is best to go through the user list once. Accounts of former guest authors, interns, or an agency whose assignment has long been completed should be deleted or downgraded to Subscriber. Replace an account named "admin" with an administrator of your own, because according to the hardening guide, attackers try such usernames first.

If an administrator shows up that nobody created, that is a warning sign. After an incident involving a backup plug-in in October, attackers created new admin accounts via plug-ins they had previously installed unnoticed.

For the remaining accounts, the BSI's recommendation for every login applies: a separate password for each service, either at least eight characters from four character types or 20 to 25 characters from two character types, such as several words in a row. You don't have to remember the passwords; a password manager takes care of that.

WordPress does not include two-factor authentication. The guide against password attacks advises setting it up for all administrators and accounts with elevated permissions via a plug-in or a login service. The BSI recommends the second factor for every service that offers it.

Application passwords, which have been available for apps and services since WordPress 5.6, can be revoked individually without you having to change your actual password.

Which plug-ins and themes should go?

Everything you don't use you delete rather than just deactivate. The WordPress hardening guide explicitly advises removing unused plug-ins; a deactivated plug-in remains on the server with all its files.

You only get new extensions from the official directory on wordpress.org or from well-known companies. If a plug-in requires write permissions on the server, the documentation advises reading the code yourself or having someone you trust review it.

It's best to avoid plug-ins that execute PHP code from database entries altogether; for custom functions, custom page templates are the safer route.

You turn off the built-in file editor for themes and plug-ins with one line in the wp-config.php: define( 'DISALLOW_FILE_EDIT', true ); An attacker with a hijacked administrator account can then no longer write PHP code into a theme in the dashboard. The documentation itself states that the line does not prevent the uploading of malicious files.

What does a backup look like that helps in an emergency?

Database and files both belong in the backup; only with both can a typical WordPress site be fully restored. A copy of the files usually does not contain the database, which you export separately. The WordPress guide to backups specifies a fixed order for both parts.

When backing up, the database comes first, then the files. When restoring, it works the other way around.

For small sites that rarely change, one backup per week is enough according to the guide; sites with a lot of new content you back up daily, and all of them additionally before every update. Keep at least three to five current backups in separate locations, such as with your host, in cloud storage, and on your own computer. If the only copy is on the same server as the site, an outage or break-in hits both at the same time.

The hardening guide additionally advises encrypting backups and keeping dated versions so that a copy from before a break-in is available.

A plug-in for automatic backups takes the routine off your hands. The documentation nevertheless recommends backing up manually from time to time to check whether the automation is really working. What this looks like in practice is shown in the lesson Security and Backups in the WordPress course for beginners.

What do you set on the server and in the wp-config.php?

File permissions, PHP version and encryption help determine how far an attacker gets once they have found a vulnerability. You set most of these values once via SFTP or in your host's customer area.

For folders, the documentation specifies the file permissions 755, for files 644; automatic updates also create the files with these values. The wp-config.php, which contains the database credentials, gets 400 or 440, so it can only be read. It may also sit one folder level above the installation. For transferring files, use SFTP instead of FTP as soon as your host offers it.

WordPress recommends PHP version 8.3 or higher. For PHP 8.2, security updates end on December 31, 2026. If your site is still running on it, it's best to plan the switch now; what you should clarify with your host is covered in the guide to web hosting for WordPress.

For login and the dashboard, the hardening guide requires an encrypted connection via HTTPS. For a new installation, set the database table prefix to something other than wp_; according to the documentation, this at least keeps out some SQL injection attacks.

Keep the server's access and error logs, because without them an intrusion can hardly be reconstructed afterwards.

What this means for you

The stream of updates is unlikely to stop anytime soon: since the start of the year, WordPress has received more than 3,000 security reports, more than in the previous twelve years combined, as the interim report from the security team shows. Five steps bring your site to a solid state:

1. Check under "Dashboard" and "Updates" whether your site is running on 7.1.4 or the patch version of your release series, and turn on automatic updates for all active plugins and themes.
2. Clean up the user list, replace an account named "admin" and set up two-factor authentication for every administrator.
3. Delete unused plugins and themes and disable the file editor in the wp-config.php.
4. Decide when and where you back up, with at least three copies in separate locations, and restore one copy once as a test.
5. Ask your host about the PHP version and plan the switch if PHP 8.2 or older is still running.

Our assessment: a security plugin does not replace any of these steps. It runs in PHP itself and costs computing power during a large attack, as the WordPress documentation notes. It changes nothing about outdated plugins, orphaned admin accounts and missing backups.

If you are just starting to build your site, the course WordPress for Beginners takes you from installation to going live, with dedicated lessons on updates and backups.

Information as of: November 13, 2026.

Sources

• WordPress documentation: Version 7.1.4
• Make WordPress Security: The Core Security Initiative: two months in
• WordPress Developer Resources: Upgrading WordPress
• WordPress documentation: Plugin and themes auto-updates
• WordPress Developer Resources: Hardening WordPress
• WordPress Developer Resources: Brute Force Attacks
• WordPress Developer Resources: Backups
• WordPress documentation: Roles and Capabilities
• WordPress.org: Requirements
• PHP: Supported Versions
• BSI: Creating secure passwords
• BSI: Two-factor authentication