WISECHECKER / SECURITY
Check the October 2026 PHP security fixes, the runtime actually serving your website, supported branches and a safe update process for hosted or self-managed sites.
Sources reviewed:
Scheduled source reviews every 6 hours. This is not a live security scanner or a complete list of incidents. Check the linked official notice for urgent decisions.
The six-hour review window has passed. Treat time-sensitive details as awaiting reconfirmation.
Check the PHP runtime serving your website—not just WordPress, a control-panel label or the command-line version. Apply the appropriate security fix, then verify the running service and the functions your visitors use.
Match the security fix to the PHP branch you run
| Branch | Earlier releases in this branch | Fix first included in |
|---|---|---|
| 8.2 | Before 8.2.35 | 8.2.35 |
| 8.3 | Before 8.3.36 | 8.3.36 |
| 8.4 | Before 8.4.27 | 8.4.27 |
| 8.5 | Before 8.5.12 | 8.5.12 |
These are the first fixed releases for these two issues, not a recommendation to remain on those exact versions indefinitely. Apply later relevant security updates as they become available. If your operating-system or hosting vendor backports a fix, obtain the package advisory and confirmation that both CVEs are addressed.
The official advisory covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The demonstrated risk is particularly high for mod_php, but the other deployments must also be reviewed. Unsupported older branches require a supported migration or a specifically documented vendor fix; an exceptional source patch does not renew upstream support.
Sources: PHP’s security advisory, CVE-2026-109618 advisory and CVE-2026-109619 advisory.
Find the PHP that actually handles each website
- Check the website’s server information. In WordPress, open Tools → Site Health → Info → Server and look for the PHP version. Dashboard translations and hosting interfaces may use different labels.
- Match the domain and handler. Ask the host which PHP package and handler serve that domain, including separate pools, subdomains and staging sites. A server may have several PHP versions installed.
- Check background work separately. Scheduled jobs, queue workers and command-line scripts may use a different binary. A command-line version check alone does not establish the web runtime.
- Confirm the patch and activation. Obtain the fixed package/version, installation result and any required worker or service restart. Have the administrator verify that new requests use the updated runtime.
Do not leave a public phpinfo() page online: it can expose configuration details. Use an authenticated diagnostic, the host’s tools or a controlled check that is removed afterwards. Do not paste configuration files, environment variables or secrets into a public support thread.
Questions to send to your hosting provider
Which PHP runtime, package source and handler serve this domain? Are CVE-2026-109618 and CVE-2026-109619 fixed, including any vendor backport? When was the fix activated, and were relevant workers restarted? Please also check subdomains, staging, scheduled jobs and older PHP installations, and confirm the normal-function test results.
Separate today’s security patch from your migration plan
A supported branch can move from general bug fixes to security fixes only. Plan the migration before security support ends rather than waiting for the next critical notice.
| Branch | General bug fixes through | Security fixes through |
|---|---|---|
| 8.2 | 31 Dec 2024 — ended | 31 Dec 2026 |
| 8.3 | 31 Dec 2025 — ended | 31 Dec 2027 |
| 8.4 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 31 Dec 2027 | 31 Dec 2029 |
Upstream PHP support is different from a distributor’s commercial maintenance agreement. Check the exact package and contract. A CMS’s minimum compatible PHP version is not a statement that the branch is secure or still supported. Older preparation guides may still mention PHP 7.4; that branch no longer has upstream support. Use the current PHP support table and your vendor’s security advisory when choosing a version.
Source: PHP supported versions.
Update with a recovery plan and real-function tests
Identify the runtime owner, security fix, compatibility requirements and maintenance window. Back up files, database and required configuration, and verify how they would be restored.
Use a restricted staging environment with protected test data. Apply the official or supported vendor package through the approved hosting or server process.
Confirm the active runtime and required restart. Test sign-in, forms, uploads, checkout, mail, scheduled work and authorized API integrations; inspect application and server errors.
Test advertising and consent components too if they are part of the service. A page loading successfully is not enough to establish that payments, mail or background processing still work. Preserve the package/version, time, test results and person responsible.
If an urgent security update causes a compatibility failure, coordinate containment and a supported recovery path with the host or developer. Do not silently return a known-vulnerable public service to unrestricted operation. A rollback plan must address the security risk as well as availability.
A WAF rule or hidden version number is not the fix
A WAF may block some requests, but it does not repair PHP or remove an attacker already present. Changing error display, hiding the version or having many workers also does not establish that these vulnerabilities are fixed.
Some official interim mitigations involve server resource controls and worker behavior. Do not copy a memory-limit change or restart command into production without understanding its effects. If the patch cannot be applied promptly, have the responsible administrator assess restricted access, temporary suspension or migration, with an explicit plan and deadline.
Patching PHP does not finish an intrusion investigation
If you find unknown administrators, unexpected redirects, modified files or suspicious outbound activity, preserve relevant logs and evidence and involve the host or incident responder. They must assess accounts, tokens, persistence, files and affected information as well as PHP.
Do not bulk-delete suspicious files or overwrite the only evidence with a restore. Reopening the service should follow containment, a trustworthy rebuild or restore, closure of the entry path and appropriate credential/session actions. See the website incident-response steps.
Common PHP security questions
Does updating WordPress also update PHP?
Usually not. WordPress, themes and plugins are application components. The host or server administrator manages the PHP runtime separately.
Does a static website need a PHP review?
A site that never runs PHP is different from a static-looking site with a PHP form, administration tool or old installation. Check those services and unused subdomains before deciding that PHP is absent.
Should I install an unfamiliar scanner or public exploit to check?
No. Start with the installed package, active runtime and official vendor advisory. Use only authorized, controlled assessment methods with your administrator; do not run an unknown exploit against a production service.
Further reading: WordPress PHP update preparation and WordPress security hardening. For a current outage or an update-related error, check service outages and app-update issues.