Securing WordPress and PHP: a patch routine for website operators

By Wladimir Neuberger · Updated 27 Oct 2026

Why PHP and WordPress belong together

A WordPress site has at least three layers, each with its own updates: the WordPress core with plugins and themes, the PHP runtime on the server, and the server itself. Many operators maintain only the first layer because it is visible in the dashboard. The PHP version appears there only under Site Health, and it is usually patched by the host or by you, not by WordPress.

How real this is shows in the Known Exploited Vulnerabilities Catalog of the US agency CISA (CISA Known Exploited Vulnerabilities Catalog). We evaluated a snapshot dated 26 October 2026 ourselves: 309 vulnerabilities were added in the twelve months up to that date. Three name WordPress as the vendor (each for the core, added twice on 21 July 2026 and once on 25 September 2026), and two name PHP Group (both added on 26 October 2026, see our advisory on PHP2Shell). That is five of 309 entries, about 1.6 percent. The number is small, but each of these entries means that, according to CISA, the flaw was actually exploited. A snapshot is not the whole catalogue; third-party plugins and server software are sorted by their own vendors and are not counted here.

Step 1: inventory and PHP version

Nothing can be patched without a list. Record every installation, including staging sites, old campaign sites and containers. The PHP project supports each branch for four years: two years of regular bug fixes, then two more years of critical security fixes only. After that the branch is end of life, and the project advises moving on as soon as possible because unpatched vulnerabilities may remain. According to the overview of 27 October 2026, security fixes end on 31 December 2026 for PHP 8.2, on 31 December 2027 for 8.3, on 31 December 2028 for 8.4 and on 31 December 2029 for 8.5.

• Find the version: in the hosting panel, over SSH with “php -v”, or in WordPress under Tools → Site Health → Info → Server.
• Note the branch and its end date: if security support ends within the next twelve months, plan the migration now (our recommendation).
• Check the patch level: within a branch the minor release counts. A host may ship the fix as a new build under the same version number; GoDaddy therefore advises checking the build date.
• Replace everything unsupported: anyone running PHP 8.1 or older needs to move to a supported branch. Backported fixes from individual hosts are a stopgap.

Step 2: apply updates without downtime

WordPress advises backing up the database and all files before an update and verifying that the backup exists and is usable. Its hardening documentation also recommends regular backups of the full installation in a trusted location so that a pre-compromise state can be restored. The documentation does not describe a test environment (staging); that is our recommendation, because mistakes show up there before visitors see them.

• Back up first: save database and files, and actually test a restore at least once.
• Staging: run a copy of the site with the new PHP version and plugin versions and click through core functions such as forms, checkout and login.
• Order: PHP and core first, then plugins one at a time. That way a faulty plugin can be identified.
• Delete what is unused: remove unused plugins and themes instead of just deactivating them. According to the WordPress documentation, plugins you do not need should be deleted.
• Verify afterwards: check the version, read the error log, and restart services where needed so the new PHP version is really running.

A backup that has never been restored is only a hope. Test the restore before you need it.

Weighing automatic updates

According to its own documentation, WordPress enables automatic updates for minor core releases and translations by default. New installations from WordPress 5.6 onward also include major core releases. Plugin and theme updates run automatically only in special cases; you control them through settings or filters. The documentation strongly discourages switching off all automatic updates.

• Core: let minor releases run automatically. That is the default and delivers security fixes without delay.
• Plugins and themes: automation suits established extensions with a good update record. Update critical functions such as shop or booking in staging first (our recommendation).
• PHP: WordPress does not handle this. Ask your host whether security updates are applied automatically and how you are told about a branch change.

Who is responsible for what at the host?

GoDaddy describes one host’s case: for managed WordPress hosting and standard web hosting the provider patched PHP, while on a virtual server (VPS) the customer is responsible. That is not a general rule but shows how much contracts can differ. So ask in writing.

• Who updates PHP, within what period after a security advisory, and how will you be told?
• Which PHP branches does the plan offer, and when is a branch that is running out switched off?
• How can the patch level be verified, for example by build date rather than version number alone?
• Who backs up the data, how long are backups kept, and who restores them?

Keeping an eye on access and logs

The WordPress documentation calls server logs valuable for forensics: they contain IP addresses, timestamps and actions and can reveal, among other things, file inclusion, directory traversal and brute-force attempts, but not which user logged in. It also recommends protecting administration with two-step login, using SFTP instead of FTP, and blocking editing of PHP files in the dashboard with “DISALLOW_FILE_EDIT”.

• Keep access logs, and after a security advisory search them from the publication date for unusual requests to PHP files.
• Check for new or changed PHP files in upload and cache folders and for unknown administrator accounts.
• Enable two-step login for all administrators and delete accounts that are no longer needed.

When a critical flaw is announced

The most recent example is the PHP flaws CVE-2026-109618 and CVE-2026-109619: the PHP project released fixes on 21 October 2026, and CISA added them to its catalogue on 26 October 2026. Patchstack points out that the flaws sit in the PHP interpreter and therefore affect every site on a vulnerable version; only a PHP update fixes them completely. A WordPress update alone is not enough. Our recommended sequence for such cases:

• Establish exposure: compare product, branch and minor version with the vendor’s statement.
• Take a backup, then update to the patched version or the package your host provides; afterwards restart PHP and the web server and confirm the version.
• Until the update, use stopgaps such as host firewall rules, but only as a bridge. PHP itself describes mitigations as incomplete.
• Check logs and files for anomalies; if you suspect compromise, renew credentials and restore from a clean backup.
• Learn: note how long patching took and set the next deadline.

Current advisories on this topic

• PHP2Shell: critical PHP core flaw affects almost every WordPress site

Frequently asked questions

Sources

• PHP-Projekt — Supported Versions (abgerufen am 27.10.2026)
• WordPress Developer Resources — Hardening WordPress
• WordPress Developer Resources — Upgrading WordPress (u. a. automatische Hintergrund-Updates)
• CISA — Known Exploited Vulnerabilities Catalog
• Patchstack — Major security alert: PHP vulnerable to critical RCE (21. Oktober 2026)
• GoDaddy — Important PHP security update: what website owners need to do

This assessment rests on the publications listed. Check the original source before making decisions.

Keep reading

• Cyber security in the age of agents: what changes when AI acts on its own