On 21 October 2026 the PHP team ships an unscheduled security release at 14:00 UTC. It contains two fixes. Each flaw is scored 9.2 on CVSS 4.0 — the top of the scale, not a ticket for next week.

The write-up stays sealed until the patch is public. A precise description at that point helps someone assemble an attack more than it helps someone upgrade a server. If the details leak, or if break-ins start, the team has said the release can move earlier.

Who has to care

Any site that answers through PHP: WordPress, Bitrix, a custom form, some hosting panels. If you do not remember the stack, ask the person who launched the site, or open the hosting panel and read the PHP version.

A 9.2 score does not describe the trick. It says the old build should be gone the day the package exists. Diffing the patch against the previous release is usually how the flaw becomes obvious, so the time a production server spends on the old build is short.

Before the release, and right after

  • Decide who installs PHP updates: you, the host, or whoever maintains the site
  • Write down the current version before 14:00 UTC, so you can see whether it actually changed
  • Install the package the day it is published, not on the next scheduled Thursday
  • Open the homepage, the request form, and checkout. A security patch should not silently break the path that brings in orders

Do not hunt for a how-to-reproduce thread. Until the fix is out, that write-up should not exist. If it shows up, that is the case where the release may land ahead of the announced hour.

Where to look

The PHP team’s own notice goes up on php.net. The report this note started from was published on Habr — the link is below. After the package ships, one check matters: the version on the server matches the release, the site opens, and the form still arrives.