On September 22, 2026, WordPress released version 7.1.2 to fix a critical vulnerability and told site owners to update immediately. In the same stretch, Next.js published security releases of its own. Neither fact says one platform is unsafe. Both say a website needs a named person who applies patches quickly, which is the job a maintenance and support plan exists to cover.
WordPress fixed a critical flaw on September 22
WordPress 7.1.2 is a security release for a flaw tracked as CVE-2026-87902, which WordPress.org describes as critical severity and Patchstack scores 9.2 on the CVSS scale. Patchstack lists affected versions as 4.7.0 through 7.1.1, so the range of sites in scope was wide.
WordPress.org says an unauthenticated attacker could, under certain conditions, get a site to load a local PHP file from outside the active theme's folders. When conditions on both the server and the theme line up, that can lead to remote code execution. Not every site was equally exposed, which is why checking beats assuming.
The fix ships in 7.1.2. Patchstack lists patched releases of 7.0.6, 6.9.9 and 6.8.10 for older branches, with backports as far back as 4.7.37. WordPress.org adds that sites with automatic background updates enabled begin the update on their own.
| Branch | Patched release |
|---|---|
| 7.1 | 7.1.2 |
| 7.0 | 7.0.6 |
| 6.9 | 6.9.9 |
| 6.8 | 6.8.10 |
| 4.7 (oldest backport) | 4.7.37 |
Attempts to exploit it began the same day
Patchstack's firewall recorded the first exploitation attempts at 11:49 UTC on September 22, the same day 7.1.2 was published. Less than four hours later it saw the first attempts to write files to servers, and by September 23 public scanning tools for the flaw were circulating, according to Patchstack's write-up.
Under 4 hours
From the first exploitation attempts to the first file writes on servers
11:49 UTC
First exploitation attempt, September 22, the day 7.1.2 was published
Patchstack's advice is plain: update, and once attackers began writing files it called the update urgent. For an owner, the useful part is the timeline. The gap between a public fix and the first attempts to abuse it was zero days, so a monthly update routine is slower than the people probing for unpatched sites.
Next.js published four security releases between July and September
Next.js had its own run of security fixes, so this is not a WordPress-only story. According to the Next.js blog, the team published security releases on July 20, August 25, September 22 and September 30, 2026.
- July 20: fixes for nine issues, four of them high severity. One was a middleware and proxy bypass in certain App Router builds, where authentication or security checks in the middleware could be skipped. Patched in 16.2.11 and 15.5.21.
- August 25: two critical vulnerabilities, one in image optimization with AVIF files and one affecting Windows-hosted servers. The team moved the release forward a day after finding the second. Patched in 16.3.3 and 15.5.24.
- September 22: an out-of-band update for a critical issue that reached Next.js through an upstream dependency, a possible remote code execution problem in the Node.js ImageResponse feature of versions 16.2.0 up to, but not including, 16.3.6. It is fixed in 16.3.6. Next.js says 15.x is not affected by the code execution issue, and 15.5.26 adds related hardening.
- September 30: seven vulnerabilities, one high, five medium and one low, patched in 16.3.8 and 15.5.27. A fix for one critical and one high issue was postponed because of upstream dependency delays.
The July 20 post says the team had moved to preannounced security releases, so teams can plan for patches ahead of time. Many of these issues also apply only to certain setups, such as Windows hosting, self-hosting, or particular features like Server Actions. As with WordPress, whether a flaw reaches your site depends on how it is built and hosted, and someone has to look.
The lesson is ownership, not platform
A website stays secure when one named person is responsible for watching releases and applying them. WordPress and Next.js both publish fixes quickly and in the open, so the platform's part is done by the time you hear about it. The remaining work is getting the fix onto your site.
That is the same point as in a website is a business system, not a finished project: launch is not the finish line, and the site needs a permanent owner. Which platform fits your business is a separate question, covered in Next.js vs WordPress in 2026. Either one needs this ownership.
GrossiWeb's maintenance and support plan, from $250 a month, includes security patching, framework and dependency updates, vulnerability monitoring, and uptime and performance monitoring with alerts. It covers sites GrossiWeb built and sites taken over after a codebase review, and sites built under web development are covered from launch.
A five-minute check you can run yourself
Five questions tell you whether your site has an owner for updates. You can answer them yourself or by asking whoever built or hosts the site, and any question you cannot get an answer to is your finding.
- Your version. In WordPress, read the line at the bottom of the At a Glance widget on the dashboard, or open Tools, then Site Health, then Info, and read the Version row in the WordPress section. It should be 7.1.2 or later on the 7.1 branch, or 7.0.6, 6.9.9 or 6.8.10 or later on those branches. If it starts with 6.7 or lower, ask your developer to confirm the site has the security patch for its branch, or plan an upgrade. For Next.js, ask your developer which version of next is installed. The September 30 releases were 16.3.8 and 15.5.27.
- Auto-updates. WordPress documentation says new installs since 5.6 have automatic updates on for minor and major core releases. Plugin and theme auto-updates are opt-in, so check the Automatic update column on the Plugins screen. Site Health flags background updates that are not working, and hosts or plugins can switch plugin and theme auto-updates off, so confirm rather than assume. A Next.js site updates when a developer upgrades the dependency, so ask who does that and how often.
- Backups. WordPress documentation advises backing up before updating so you can restore if something breaks. Ask where backups are stored, how recent the last one is, and whether anyone has restored from one.
- Who gets the alert. WordPress emails the site owner by default when a plugin or theme auto-updates or fails to, so confirm a person reads that inbox. Name a primary and a backup contact for security announcements and uptime alerts.
- Time to patch. Ask how many days passed between the last critical security release and your site being updated. Because attempts on the WordPress flaw began the same day as the fix, treat a critical release as same-day or next-day work, with testing first if your site has custom code.
What to do this week
Five actions to tick off
0 of 5 done