Daily SEO Note — September 28, 2026: A Critical WordPress RCE Meets an Emergency Block Rule

This edition covers the 72 hours to 06:15 UTC on Monday, September 28, 2026, the extended weekend window. The honest headline is a split one: the editorial side saw no new primary-source announcement in the window, while the engineering side has a critical, unauthenticated WordPress vulnerability that now has an emergency edge rule sitting in front of it. Every item below is dated to its primary source, and rollout status is stated as the source states it.

1. SEO for Content Writers

No new editorial announcement landed between Friday and this morning: Google published nothing to the Search Central Blog, the documentation changelog has no entry after September 24, and the Bing Webmaster Blog has been silent since February. What changed is not an announcement but a clock: the September 2026 spam update has now been open long enough to break every 2026 precedent, and that should change how long you plan to keep your hands off your own rankings.

The September spam update is now running on a core-update timetable, not a spam-update one

The rollout status itself has not changed since Thursday, and this note has covered the update three days running, so the item earns its place only because of what is now measurable. Google's incident entry still carries a single update, logged September 24 at 16:15 UTC, and still has no end time. As of 06:15 UTC this morning that is three days and fourteen hours open.

Here is the part worth acting on. Google's own wording for this update was "The rollout may take up to two weeks to complete." Every other spam update in 2026 said "a few days" instead, and each one closed well inside that: the March spam update ran 19 hours and 30 minutes, the June one two days and one hour, the August one two days and sixteen hours. The "up to two weeks" phrasing belongs to the two 2026 core updates, which ran eleven days and twelve days respectively. Those figures come from the start and end timestamps Google publishes in its own machine-readable incident feed. This update has already outlasted every 2026 spam update and is being described in core-update language.

Who it affects: all content, with the sharpest movement on sites touching the spam policies — scaled content abuse, site reputation abuse, expired domain abuse. What to do differently in your next article: extend your freeze. If you told your team to hold reactive rewrites for a few days, re-plan for up to two weeks from September 24 and put a calendar marker on October 8. Keep publishing on your normal schedule and keep the dated log. What to stop doing: stop expecting this one to close on the August update's two-day timetable, and stop drawing conclusions from any single day inside it.

Unconfirmed: the Discover traffic thread is now three days old and still unconfirmed

Community discussion that began Friday about Discover traffic being throttled has continued through the weekend without any confirmation. Google has said nothing about Discover, there is no Discover entry on the Search Status Dashboard, and the open spam update remains a sufficient explanation for movement this week. Treat it as unconfirmed, do not rewrite anything on the strength of it, and note that it is excluded from the checklist below for that reason.

Apply to your next brief

• Re-plan the rewrite freeze to run up to two weeks from September 24, 2026, not a few days; mark October 8 as the review date.
• Keep the dated before-and-after log going all week so the post-rollout comparison uses stable data.
• Do not treat any single day's volatility inside an open rollout as a verdict on an individual article.
• Audit remaining scaled-content, site-reputation and expired-domain practices now; those policies are enforced independently of any update.
• Leave the Discover chatter out of briefs and stakeholder updates until Google confirms something.
• If your site runs WordPress, ask your engineers today whether it is on a patched version — see the developer section.

2. SEO for Developers

One item dominates the window, and it is breaking. A critical, unauthenticated remote file inclusion in WordPress core is now public, patched, and — as of Friday — covered by a Cloudflare managed rule that defaults to Block. That gives you two jobs, not one: patch the CMS, then confirm the new edge rule is not returning 403 to Googlebot on legitimate URLs. Everything else in the window was a prerelease or a negative result.

Critical unauthenticated WordPress RCE, now with an emergency Cloudflare Block rule in front of it

CVE-2026-87902 is an unauthenticated path traversal in WordPress page-template resolution: an attacker can make get_page_template() include a chosen readable local .php file from outside the active theme directories, which can reach remote code execution when the preconditions line up. It is classified CWE-98 and scored CVSS 9.2. It affects WordPress 4.7.0 through 7.1.1 and is fixed in WordPress 7.1.2, released September 22, 2026 and backported to every branch from 4.7 upward. The advisory ID is GHSA-7hp8-65ch-5whp.

Breaking, and the preconditions are more common than they sound. The active theme needs a top-level directory whose name starts with "page-" — which covers page-templates and page-builders layouts in legacy default themes and in widely installed third-party ones — and the server needs a readable .php file the web process can reach, which the official Docker PHP image and default cPanel installs on PHP below 8.5 supply. The symptom if ignored is not a ranking dip; it is arbitrary file inclusion on a path any crawler can reach unauthenticated. The setting to change is your WordPress version, and a minor-version update carries the fix on every branch.

#!/usr/bin/env bash
# CVE-2026-87902 - unauthenticated remote file inclusion via page-template
# resolution. Fixed in WordPress 7.1.2 (2026-09-22), backported to 4.7+.
# Advisory: GHSA-7hp8-65ch-5whp  (CWE-98, CVSS 9.2)
set -euo pipefail

# 1. What is actually running?
wp core version

# 2. Do we meet the theme-side precondition: a top-level "page-" directory?
find "$(wp theme path)" -maxdepth 2 -type d -name 'page-*' -print

# 3. Patch. A minor update carries the security fix on every branch.
wp core update --minor
wp core version   # expect 7.1.2, or the patched tip of your branch

Then the SEO half. Cloudflare's WAF managed ruleset changelog records an emergency release dated 2026-09-25 that adds rule ...70a43f96, "Wordpress - Path Traversal, Local File Inclusion - CVE:CVE-2026-87902", with a new action of Block, alongside a "Wordpress - XSS - Comment" rule and two JFrog Artifactory authentication-bypass rules. An emergency rule that blocks on a path-traversal pattern is exactly the kind that can catch a legitimate URL, and a blocked request returns 403. Google treats 4xx on a previously indexed URL as a signal to drop it, so a false positive here is a deindexing path that no build step will warn you about.

#!/usr/bin/env bash
# Cloudflare emergency release 2026-09-25 added rule ...70a43f96 with a
# default action of Block. Confirm it is not blocking real URLs for Googlebot.
# Verify any real crawler by reverse DNS before trusting a user agent:
# https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot
set -euo pipefail

UA="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

# Feed it the URLs most likely to trip a path-traversal pattern.
while read -r URL; do
  CODE="$(curl -s -o /dev/null -w '%{http_code}' -A "$UA" "$URL")"
  case "$CODE" in
    200|301|304) ;;
    403) echo "WAF-BLOCKED  $CODE  $URL" ;;
    *)   echo "CHECK        $CODE  $URL" ;;
  esac
done < urls-to-verify.txt

After patching, watch the Crawl stats report in Search Console for a 403 spike dated on or after September 25. If you find one, do not disable the rule: scope an exception to the specific paths involved and leave the rule blocking everywhere else.

Unlighthouse 0.18.2 fixes CSV columns landing under the wrong headers

Unlighthouse 0.18.2 was published to the npm registry at 03:55 UTC on September 28, 2026, making it the only stable release inside this window. It carries one bug fix, "Keep csv columns under the right headers" (PR #401). Non-breaking.

The symptom if ignored is quiet and genuinely misleading: your CSV export parses cleanly and every number looks plausible, but values sit under the wrong column headings, so whatever you feed into a spreadsheet or a dashboard attributes scores to the wrong metric. If you have been exporting Unlighthouse CSVs on 0.18.0 or 0.18.1 and reporting from them, treat those exports as suspect and re-run them rather than trusting the numbers already circulated. The file to change is your dev dependency.

#!/usr/bin/env bash
# unlighthouse 0.18.2 published 2026-09-28T03:55:26Z
# Fix: "Keep csv columns under the right headers" (PR #401)
set -euo pipefail

npm i -D [email protected]

# Re-run any CSV export produced on 0.18.0 or 0.18.1 - the column
# alignment in those outputs cannot be trusted.
npx unlighthouse-ci --site https://example.com --reporter csv

Next.js stayed on 16.3.6 — the window was canaries only

The npm registry confirms the latest stable Next.js tag is still 16.3.6. Everything published in the window was a prerelease: 16.4.0-canary.45 through canary.51, the last at 23:58 UTC on September 27. Canary.51 contains only DevTools work surfacing security upgrade advisories, and nothing in it touches metadata, sitemaps, robots, caching, revalidation, or image optimization. No action: hold at the current stable tag and do not put canary in front of Googlebot.

SvelteKit 3.0.0-next.30 is a prerelease with nothing SEO-relevant

SvelteKit published 3.0.0-next.30 at 11:42 UTC on September 27, while the stable line stays at 2.70.3. Its fixes cover a never-typed Path when a project has no routes, a focus-handling bug that leaked hashchange to app listeners, and form instance re-registration. Nothing touches prerendering, trailing-slash behavior, or adapter output. No action.

Specs and the SEO supply chain were clean in the window

Recorded so the negatives are on file. Schema.org's most recent release is still 30.1, dated September 16, with nothing since. Registry metadata shows no releases in the window for next-sitemap, next-seo, @nuxtjs/sitemap, @astrojs/sitemap, web-vitals, schema-dts, or Lighthouse — the most recent of those are Lighthouse 13.5.0 on September 19 and web-vitals 6.2.2 on September 14. No entry in the Vercel changelog in the window touches redirects, rewrites, middleware, ISR, caching, or image optimization. Beyond the WordPress advisory above, no advisory in the window affects an SEO package, sitemap generator, or crawler dependency.

Ship today

1. Patch WordPress to 7.1.2, or to the patched tip of whichever branch you run. This is the only genuinely urgent item in the window.
2. Check whether your active theme has a top-level directory beginning with "page-", which is the theme-side precondition for CVE-2026-87902.
3. If you are behind Cloudflare, review the Crawl stats report for a 403 spike dated September 25 or later, and scope a narrow exception rather than disabling rule ...70a43f96.
4. Bump unlighthouse to 0.18.2 and re-run any CSV export produced on 0.18.0 or 0.18.1 before reporting from it.
5. Leave Next.js at 16.3.6 and SvelteKit at 2.70.3; nothing in the window justifies moving to a prerelease.