WordPress PHP Security: 7 Checks to Confirm the Patch

WordPress PHP security needs attention after the 21 October 2026 emergency release. Check Tools → Site Health → Info → Server, record the PHP version, then confirm the patch with your host. The fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. An older displayed version may contain a vendor backport; ask for evidence before deciding it is unpatched.

Checked: 22 October 2026. This is a verification checklist, not a report of completed client-site tests. No three-host comparison or downtime measurements are claimed.

The PHP security advisory describes two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can permit remote code execution without authentication. Its mitigations are incomplete. The WordPress security notice urges prompt PHP updates and explains that no WordPress core release is planned for these issues.

Contents

• Record the runtime
• Verify the fix
• Confirm deployment
• Check recovery
• Apply the patch promptly
• Test business functions
• Review logs and evidence
• Frequently asked questions
• Get an audit

1. Start your WordPress PHP security check with the runtime

Open Site Health’s Info tab, expand Server, and copy the full PHP version. Record the domain, environment, host, hosting plan, date and time zone. Keep production and staging records separate.

If available, record the PHP handler and package/build details from your hosting panel. A selector showing only “PHP 8.3” is too broad to establish patch status. A recent build date is supporting context, not proof that a particular fix was included.

On a server you manage, a terminal’s PHP version may differ from the runtime handling website requests. Ask the administrator to verify the web-serving runtime specifically. Avoid leaving a public PHP information page online just to collect this data.

2. Match the release or obtain backport evidence

The October fixes arrived in these upstream releases:

These are the fixed releases for this incident, not a permanent recommendation to stop updating. Check the advisory and your vendor’s current guidance when acting.

PHP’s advisory explicitly allows for distribution and long-term-support vendor backports. If your host keeps an older displayed version, request the package identifier and vendor notice confirming both CVEs are fixed. “We have a firewall” does not establish that the runtime is patched.

PHP 8.1 and older no longer receive normal upstream updates. Exceptional source backports do not restore routine support. Obtain vendor-specific evidence or arrange migration to a supported branch.

3. Ask whether the fix is serving your traffic

A rollout announcement is useful context. It is not account-specific confirmation. Send your hosting provider these questions through its support channel:

• Does the PHP runtime serving this domain contain fixes for CVE-2026-109618 and CVE-2026-109619?
• What exact release or vendor package/build contains them? Please link the applicable advisory.
• Was my account patched automatically? When was deployment completed, and in which time zone?
• Have all relevant workers and servers been restarted or replaced as required to run the patched code?
• Are staging, subdomains and additional sites covered? What remains my responsibility?
• Are temporary restrictions still active, and which site functions might they affect?

Save the response and ticket number. If support confirms only mitigation, record the status as patch not confirmed. Do not convert a vague assurance into a claim that your site is safe.

4. Verify recovery before changing production

Confirm that you have a recent backup of files and database, know where it is stored, and can access the recovery process independently of WordPress. Record its timestamp and who can restore it.

A backup’s existence does not prove restoration works. Use a recent restore-test record where available. For an active store, establish how orders placed after the backup will be preserved before considering a database restore.

Agree on a recovery route that retains a patched runtime. A broken plugin may need disabling or replacement; leaving production on a vulnerable PHP build is not a standing recovery plan. Restoring site files alone also does not install a PHP security patch.

5. Apply the security patch without an open-ended delay

Ask for a patched release within your existing supported PHP branch where available. Separate this immediate remediation from a larger branch migration, which can introduce more compatibility work.

Use staging for a focused compatibility check when it is available. Match production’s important settings, extensions and plugins. Prevent staging from sending customer messages or taking real payments. Keep it access-controlled.

Do not let an extended test project leave an exposed runtime waiting indefinitely. If patching is blocked, escalate promptly to the host or server administrator. WordPress’s incident notice says owners of older, self-managed installations should consider taking the server offline while preparing an update.

Treat the PHP patch and the usual WordPress security update routine as separate tasks. Updating core, themes or plugins does not replace this runtime fix.

6. Test the functions that bring in business

Check the homepage, then follow an actual customer journey. A page loading successfully proves little about lead capture or payment processing.

• Login: sign in, sign out, and confirm an ordinary user’s expected access.
• Forms: submit a clearly labelled test, verify receipt in the destination inbox or CRM, and check required-field errors.
• Uploads: test a permitted file type and a representative file size through the normal interface.
• WooCommerce: test product selection, cart, shipping, tax and checkout using an approved test-payment method. Verify the order record and expected test notifications.
• Integrations: check the booking, membership or other workflow the business depends on, where applicable.

Record each result separately. “Checkout opened” is not “payment and order handling passed.” If something fails, capture the time, affected step and relevant error before making unrelated changes.

7. Review logs and keep a defensible record

Review PHP and application errors around deployment and testing. Ask the host for help if logs are unavailable. Compare new failures with the pre-update baseline; avoid assuming every old warning came from the patch.

Use this record for your own site and each client site you are authorized to assess:

• Site label, host, environment and timestamp.
• Before/after PHP version and package/build evidence.
• Host patch confirmation and automatic/manual deployment status.
• Backup timestamp and recovery reference.
• Staging failures, changes made and unresolved issues.
• Form, upload and checkout results, with test times.
• Monitoring interval, observed interruptions and follow-up owner.

“No outage observed during these checks” is defensible when accurate. “Zero downtime” needs monitoring evidence. Redact domains where necessary, account identifiers, customer data and secrets before sharing screenshots.

For WordPress PHP security, keep three conclusions separate: the fix is confirmed, business checks passed, and broader compromise assessment is complete. Patching these vulnerabilities does not prove the site was never compromised or remove an existing infection.

Frequently asked questions

How do I check the PHP version on WordPress?

Go to Tools → Site Health → Info → Server and read PHP version. Record the complete value. Ask your host for package/build evidence if it uses backported fixes.

Will updating WordPress install the PHP security fix?

No. PHP is a server runtime. Your hosting provider or server administrator must deploy its fix separately. Keep WordPress updated too, but do not mistake that for PHP remediation.

Which PHP versions contain the October 2026 fix?

The upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Vendor packages may include backports. Confirm coverage of both CVEs against the PHP advisory and vendor documentation.

Can updating PHP break plugins or WooCommerce?

Compatibility problems are possible, especially during a branch migration. Test your installed extensions and critical flows. The WordPress PHP update guide recommends backups and compatibility checks; neither guarantees every plugin will work.

What should I ask my hosting provider?

Request confirmation for your domain, both CVEs, the installed package/build, deployment time, worker replacement or restart where required, and coverage of staging and other sites. Ask whether temporary restrictions remain.

Need a WordPress security and maintenance audit?

Send me your WordPress URL and host name. I’ll tell you what to verify before you touch production. Include your Site Health PHP version if available; never send passwords through a contact form.

A public URL starts the discussion. Confirming private runtime details requires host evidence or authorized access. An audit can examine patch status, backups, compatibility and business workflows, with its scope agreed before changes begin.