On September 22, 2026, WordPress released version 7.1.2, a security update that fixes a vulnerability of critical severity. And two days later, on September 24, the PHP team released security versions for all supported branches. If you manage WordPress sites, this is a week to review versions, not to postpone.
What WordPress 7.1.2 fixes
According to the official announcement, an unauthenticated attacker could, under certain conditions, cause page template resolution to include a local PHP file readable outside the active theme's directories. That can lead to remote code execution. It is registered as CVE-2026-87902.
The security team itself clarifies that preconditions must be met both on the server and in the active theme. It is not an excuse to wait: it is one more reason not to have old or hand-modified themes in production. The patch was applied to all eligible branches, back to 4.7, and sites with automatic background updates receive it on their own.
And in PHP: four security versions at once
On September 24, PHP 8.2.34, 8.3.35, 8.4.26 and 8.5.11 were released as security versions. According to the summary published by Pantheon, they fix 11 vulnerabilities, including one of high severity in the SOAP extension and issues in OpenSSL certificate verification, the HTTP streams wrapper and PHP-FPM.
On shared hosting you normally don't choose when PHP is updated, but you can check which version your site runs and ask your provider if it has fallen behind.
Practical checklist for today
- Update WordPress to 7.1.2 (or the latest version of your branch) from Dashboard → Updates. Verify that it was actually applied.
- Confirm the PHP version in Tools → Site Health → Info.
- Make a backup before updating if you have WooCommerce or customizations in the theme.
- Review inactive themes and delete the ones you don't use.
- Test the site afterwards: home, a post, the checkout if there is a store and the contact form.
What happens to the cache when you update
A core or PHP update should not break a well-made cache, but it is worth verifying. After updating, regenerate or purge what is cached and check that public pages are still served well and that dynamic content (cart, account, forms) still works without being cached.
cache.lat serves static HTML from the server, so visits do not execute PHP on every page. That reduces load, but it does not replace updating: the admin panel, the REST API and dynamic routes still go through WordPress. If you want to see what is served statically and what is not, look at how cache.lat works, and the PHP and server requirements in the technical data.
How to organize updates without suffering
Enable automatic updates for security
Minor and security core updates are usually enabled by default. Verify that no plugin or constant in wp-config.php is disabling them without you remembering.
Have a test site
If your site lives off sales, test major updates in staging. For critical security patches, the risk of waiting is usually greater than that of updating with a recent backup.
Look at the logs afterwards
After updating PHP, check the error log for a few hours in case an old plugin emits warnings or fatal errors.
Conclusion
Two patch packages in the same week: WordPress 7.1.2 and the PHP security versions. Update, verify and test the site. If you need a hand with the cache or with the server configuration, you can write to TNL support or review the documentation.