FIELD NOTES / A PATCH WITH PROOF
WordPress updated? Check the PHP runtime too.
A WordPress update can finish successfully while the PHP runtime underneath it still needs a security patch. That was the problem we chose to rehearse after the PHP security release on 21 October.
The task was specific: keep a disposable site offline, recover its content from backup into a patched target, then check what actually served the pages. WordPress stayed at 7.1.3. The web-serving PHP runtime changed from 8.3.35 to 8.3.36.
This was a real test with synthetic content, not a customer rescue or an overnight production update. Here is the walkthrough, followed by what we checked and what it does not establish.
Play the locally hosted video instead
The fix belonged below WordPress
PHP's advisory describes two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. It lists upstream fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Distribution packages can carry vendor fixes under different package numbers; check the relevant vendor advisory. Read the PHP advisory.
WordPress explicitly says that a WordPress-core update is not required for these PHP issues. Its notice explains where to inspect the PHP version in Tools → Site Health → Info → Server, and advises checking with the hosting provider. Read the WordPress notice.
First, keep requests away from PHP
The lab used a static gate returning HTTP 503 before requests reached PHP, with separate private access for checks. A WordPress maintenance page would still execute PHP, so it was not used as the exposure boundary. No public ingress was opened.
This distinction matters when a patch cannot be applied immediately. The official advice is to update promptly; if that is not feasible, assess taking the affected service offline. Letting a maintenance job run while you are away is not a reason to leave the vulnerable service exposed overnight.
A backup had to survive a restore
The agent backed up the files and database and restored them into a separate disposable target. The restore compared the rows in all 12 tables and checked 3,783 extracted files; the target-specific configuration was the documented exception.
That gave the run something stronger than a successful backup command: a separate site built from the saved data. It did not test every possible disaster-recovery scenario.
Then check the pages, not just the shell
The replacement target served PHP 8.3.36. Private HTTP probes and the authenticated Site Health screen confirmed the runtime used for web requests. Checking php -v alone would only identify the command-line runtime.
The browser opened the homepage and a post permalink, signed into the admin area and inspected Site Health. Separate checks wrote and read a database record and wrote media that could be read back over HTTP. The tested extensions were Twenty Twenty-Five 1.5 and Hello Dolly 1.7.2.
There were harness corrections during setup. The run was not a flawless first attempt, and those corrections remain in the source and logs.
What this result actually proves
The checked lab restored its data and served the WordPress site on the patched PHP runtime. It used PHP's built-in development server, not a production PHP-FPM or Apache rollout. Its permalink handling and private review access were lab fixtures, not deployment templates.
For a real host, the serving pools and worker processes need their own update and restart verification. The named plugin and theme checks do not establish compatibility for an arbitrary site. Passing the checks also cannot prove that an earlier compromise never happened; suspicious evidence needs separate investigation.
The useful handoff is a checked result
This rehearsal ran through an AgentHub session's tools. The film shows the WordPress lab and recorded evidence, not a filmed AgentHub production-maintenance session.
A bounded maintenance task can continue on a running server with scoped access to a reachable private target. That does not bypass a firewall, and using a model provider can still send data outside the network. A human still decides when to reopen the site. Here, the temporary runtimes were removed after recording and the static gate remained closed.
Keep the affected service offline. Verify a separate restore, apply the provider-supported PHP fix, restart the actual serving workers, run the agreed application checks, and report pass, fail or blocked. Do not reopen service without review.
Use that as the shape of a maintenance brief, then adapt it to the real hosting environment. Failed checks mean the service stays offline. A rollback to a vulnerable runtime is not a reason to expose it again.
Read the video transcript
A WordPress update won't fix this PHP flaw. Can we patch the runtime and prove the site still works? This is a disposable lab rehearsal, with synthetic data, not a customer rescue.
PHP's October twenty-first security release fixes two critical remote code execution vulnerabilities. WordPress says no core update is required for these issues. Check your host's advisory: vendor backports may use different package numbers.
In this demonstration I first take the test site offline. A static gate returns five oh three before PHP receives the request. WordPress maintenance mode alone would still run PHP. Private review access stays separate.
The starting web runtime is PHP eight point three point thirty-five. I back up the site files and database, then restore both into a separate disposable target. A backup that has never been restored is still a hypothesis.
The restore checks every table's rows and the extracted files. Then the replacement runtime serves PHP eight point three point thirty-six, while WordPress stays at seven point one point three. This lab uses PHP's development server; production hosts must restart their actual web workers and check every serving pool.
Now check the website, not just the command line. I inspect Site Health, open a permalink, sign into admin, write and read a database record, and check media. The named theme and plugin are part of this test, not proof that every extension is compatible.
There were harness corrections along the way; the source and logs record them. These checks show the patch and application behaviour. They cannot establish whether an earlier compromise occurred. Suspicious signs need investigation, and failed checks mean stay offline.
The agent ran this rehearsal through an AgentHub session's tools. This is lab footage, not a recorded production maintenance session. A job can continue on a running server while I am away, provided it has scoped access to a reachable target. Human go-live review is still required. Subscribe for practical agent workflows: the brief, the build, and the checks.