cache.lat
On October 6, 2026, WordPress published security versions for several branches, from 4.7.38 to 6.4.12 (the note for 5.3.26 is in the official documentation). If you manage WordPress sites, this touches your maintenance routine, and also your cache.
What these versions fix
According to the official notes, the security team thanks reporters for vulnerabilities that are already fixed. Among them are:
- A stored XSS on the comment administration page, exploitable through pending comments.
- A denial-of-service issue in the
WP_Http::make_absolute_url()method. - A weakness that allowed users with the Author role to sticky posts.
- Unauthenticated disclosure of comments on private and unpublished posts.
- An XSS in Imgur embeds.
- Forgeable parameters in the
{status}_{type}hook that could cause action name collisions.
The note recommends updating immediately, and clarifies that only the most recent version of WordPress receives active support; older branches receive the patches as a courtesy.
Why it matters if you use cache
Updating the core changes PHP files, and a static page cache stores already-generated HTML. That means two practical things:
1. Cached HTML doesn't fix itself
The patches fix server code, but pages that were already stored remain the same until they are regenerated. After updating, purge or regenerate the cache to make sure that what the visitor sees comes from the already-patched code. To understand what is stored and when it is regenerated, look at how cache.lat works.
2. Comments are sensitive content
Two of the fixes have to do with comments. Check in the admin whether you have suspicious pending comments and don't approve anything with strange links or code. An approved comment ends up on a public page, and therefore in your cache.
Checklist for today
- Back up the site (files and database) before updating.
- Update from Dashboard > Updates, or download the version from wordpress.org.
- If your site runs on an old branch, plan to move up to the current version: receiving the patch is not the same as being on a supported version.
- Purge the cache and check that your main pages load correctly.
- Review the queue of pending comments and delete spam.
- Open a page in incognito mode to verify that what you see is the updated version.
And on the PHP side
PHP branches also move: on October 6, release candidates were tagged (8.6.0 RC3, 8.5.12 RC1, and 8.4.27 RC1) according to the press summary we found. They are candidates, not final versions, so use them only in staging. For production, keep the latest stable version of your branch.
When to ask for help
If after updating you notice outdated pages, errors, or doubts about what to purge, the cache.lat documentation covers the usual cases, and if you need a hand with your specific case you can write through the TNL contact page.
The rule is simple: patch first, purge afterward, and always verify. Five minutes today save you a scare tomorrow.