Quick answer: when the PHP security release is due today
PHP says a security release is scheduled for Wednesday, 21 October 2026 at 14:00 UTC. That converts to 10:00 a.m. EDT, 7:00 a.m. PDT, and 7:30 p.m. IST on 21 October 2026. PHP also says it may publish earlier if details become public or active exploitation appears.
What is confirmed
- PHP’s 20 October 2026 notice says a security release is scheduled for 21 October 2026 at 14:00 UTC.
- PHP says the release addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.
- PHP says full details, affected versions, and fixed versions will be published with the release.
- PHP says it may release earlier if details become public or if active exploitation appears.
- PHP’s supported-versions page currently lists PHP 8.2, 8.3, 8.4, and 8.5 as supported; 8.2 security support ends on 31 December 2026.
- PHP 8.6 RC3 is a test release and PHP says not to use it in production.
What is not confirmed yet
- Do not assume which branches are affected until PHP publishes the advisory.
- Do not treat any circulating third-party CVE claims as confirmed unless they match PHP’s final notice.
- Do not assume the vulnerability class, attack path, prerequisites, or real-world exploitability in your environment before the release.
- Do not assume managed hosting will patch every runtime automatically without verification.
Why the severity score matters, and what it does not tell you
A CVSS v4.0 score of 9.2 is a strong severity signal. It tells operators to prepare urgently. It does not, by itself, prove that your site is exploitable in the same way as someone else’s site, or that a public exploit already exists. Treat the score as a reason to get inventory, ownership, testing, rollback, and communications ready before the release lands.
Pre-release checklist: do this before the patch arrives
- Inventory the runtime actually serving traffic, not only the CLI output on one shell or a Docker tag in a repo.
- Identify the package maintainer, container image owner, managed-hosting vendor, or internal platform team that can deliver the patched build.
- Snapshot or back up according to your normal procedure, including data, configs, and any deployment artifacts you rely on for rollback.
- Test a representative staging or canary workload so you know whether the updated runtime interacts cleanly with your app.
- Record key extensions, FPM or web-server integration details, queue workers, cron jobs, and container base images.
- Prepare rollback steps and maintenance communications before any change window starts.
- Verify vendor advisories for managed WordPress or hosting platforms rather than assuming automatic patching.
- Increase monitoring and preserve useful logs so you can investigate anomalies without claiming compromise before you have evidence.
Why a single version check can be misleading
A command like php -v on one shell only tells you about that shell’s PHP binary. It may not match the version serving web traffic through PHP-FPM, a separate container, a cron job runner, or a managed control panel. A Docker tag can also be stale if the image was built before the release. Likewise, a hosting dashboard label may lag behind the actual runtime or show only the platform’s default, not the specific site pool handling your requests.
Post-release verification checklist
- Read PHP’s final advisory first, including the affected and fixed versions.
- Map those versions to the actual production runtimes that serve traffic, including web, FPM, CLI, workers, and scheduled jobs.
- Obtain builds only from your normal trusted OS, vendor, or container channel.
- Validate checksums or signatures where your platform supports them.
- Restart or redeploy every relevant service and worker after the update.
- Confirm the running runtime again after restart, not just before it.
- Run smoke tests, watch for error spikes or latency changes, and document completion for your team and stakeholders.
If you are on an unsupported PHP branch
Do not assume a vendor patch will arrive for an unsupported branch. The durable fix is to upgrade to a supported release or move to a vendor-supported backport path if your hosting or distribution offers one. Temporary isolation, stricter access controls, or reduced exposure can lower risk, but they are not a substitute for a fix.
Myth vs. fact
- Myth: all PHP versions are confirmed affected. Fact: PHP has not yet published the affected versions, so don’t generalize before the advisory.
- Myth: CVSS alone tells me whether my site is exploitable. Fact: CVSS helps with prioritization, but your actual exposure depends on the released details and your environment.
- Myth: managed hosting means I never need to verify. Fact: you still need to confirm what is running on your sites, when it changes, and whether every relevant runtime was updated.
FAQ
Q: Should I take every site offline until the release lands? A: No. Prepare proportionately: inventory, back up, test, and be ready to patch quickly once the advisory is published.
Q: Is the release expected to come exactly at 14:00 UTC? A: That is the scheduled time, but PHP says it may release earlier if details become public or if active exploitation appears.
Q: Can I rely on a managed host’s automatic patching? A: Only after you verify it. Check the vendor’s advisory, the runtime actually serving your traffic, and whether the update reached every relevant service.
Q: What should I do first after the advisory appears? A: Read the final advisory, match the affected and fixed versions to your production runtimes, and update through your normal trusted channel.
Sources
PHP archive, 2026 security notice and release context (dated source page)
Techmeme homepage for discussion context only, not as primary vulnerability evidence
