Need a PHP security update without breaking WordPress?
Your site loads, hosting shows PHP 8.3 and WordPress reports no obvious error. A required security patch may still be missing. Switching branches blindly can also break an old plugin. Start by recording the complete runtime version, confirm patch coverage with your host, and test the functions visitors actually use after the change.
What the October 2026 PHP advisory requires
PHP’s official announcement on 21 October 2026 released fixes for CVE-2026-109618 and CVE-2026-109619. These critical weaknesses can permit unauthenticated remote code execution on vulnerable servers. A working homepage is not evidence that the runtime is patched.
The upstream releases addressing these flaws are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Check official release information for newer releases in the relevant branch. PHP 8.1 and older no longer receive regular PHP project support; some vendors supply separate backports.
Ask whether both fixes cover the web runtime serving your domain. A distribution or hosting vendor may backport security changes while retaining an older-looking version. In that case, request the exact package/build and vendor advisory rather than judging its security from the short version label alone.
| PHP Branch | Fixed Upstream Release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Find the complete PHP version used by WordPress
Open Dashboard → Tools → Site Health → Info → Server and record PHP version. For example, upstream 8.3.35 and 8.3.36 are different patch levels. Vendor backports require separate confirmation.
Check PHP Configuration or PHP Info for the correct domain in your hosting panel. A main domain, subdomain and staging copy can use different configurations. The command-line PHP version can also differ from the runtime handling web requests.
FACT: Updating WordPress or a plugin does not update the server’s PHP runtime. A security plugin, cache purge or active CDN is not proof that these fixes are installed. General compatibility advice saying ‘8.3 or higher’ is insufficient for this specific patch check.
A practical shared-hosting update sequence
1. Select the correct website. Record its current PHP version, required extensions and recent changes, and make sure you can reach hosting support.
2. Back up both site files and the database. Confirm the backup time and restore procedure. Uploads alone or a WordPress content export is not a complete site backup. Restoring an older database can discard newer orders or form submissions.
3. Review WordPress, theme and plugin compatibility. An available security patch within a supported branch usually involves fewer compatibility changes than a branch upgrade. An automated compatibility scan cannot guarantee success.
4. Test on staging if available, while avoiding an open-ended delay to urgent patching. Check support for essential plugins and the theme before moving to another branch.
5. Apply an available patched runtime or have the host do it. Shared-hosting selectors often show only branches such as 8.3 or 8.4; the provider manages the patch release underneath. Selecting the same branch again does not prove that a patch was installed.
What to ask when the hosting panel offers no patch choice
Hostinger’s official guide directs users to the correct website Dashboard and PHP Configuration. The exact interface depends on the plan. A cPanel host may offer MultiPHP Manager or Select PHP Version, but those controls are not universal.
There is no need to install an unknown ‘PHP fix’ plugin. Send support this request: ‘Please confirm that the web PHP runtime for [domain] includes fixes for CVE-2026-109618 and CVE-2026-109619. Provide the runtime/package build, any backport advisory, and confirmation that workers have been reloaded or restarted as required. Please apply a compatible patched runtime.’
An open support ticket is not confirmation of a fix. If patching cannot happen promptly, ask the provider about server-level isolation or removing public access until patching is verified. A WordPress maintenance-mode page alone does not isolate vulnerable PHP.
Troubleshoot a critical error or HTTP 500 after updating
Do not cycle randomly between PHP branches. Record the change time and inspect the corresponding fatal error in the host’s PHP logs. If WordPress sends a recovery email, only the authorised administrator should use its link; keep it private.
Use Recovery Mode to identify a failing plugin or theme and temporarily disable that component or install its compatible release. If wp-admin is unavailable, ask hosting support or a trusted developer to isolate the identified component. Disabling everything blindly can disrupt payments, forms or authentication.
Compare required extensions with the previous configuration. Do not change memory limits and timeouts without understanding the error. Setting memory_limit to unlimited is not a complete fix for these vulnerabilities. Partial server mitigations require expert handling and do not replace patching.
Rolling back may help diagnose compatibility, but publicly restoring a known vulnerable runtime is not a lasting solution. Ask for a patched compatible branch, a verified vendor backport or isolation. Consider new data and possible incident evidence before restoring a backup.
Advice: test more than the homepage
Recheck the full version in Site Health and obtain confirmation that web workers use the updated package. Clear relevant caches as needed. In a logged-out browser, test the homepage, an article, search, login, media upload and contact form. For a shop, test cart and checkout safely using its supported test mode.
Check the recorded form submission and email delivery, not just whether a button responds. Review background tasks and fresh log entries for failures. Record the test time, version and outcome in maintenance notes.
Unexpected administrators, changed files or unfamiliar redirects warrant investigation rather than being dismissed as compatibility problems. Ask the host to preserve logs, restrict access and assist with examination. Patching addresses these weaknesses; it does not automatically remove an earlier compromise.
Frequently asked questions
Will switching PHP delete posts or photographs? Changing the runtime normally does not delete content, but backups matter because failures and later restoration can have separate consequences.
Does WordPress Update Now update PHP? No. Hosting/server PHP is managed separately.
Is seeing PHP 8.3 enough? No. Confirm the complete upstream patch level or documented vendor backport.
Can a CDN or WAF replace the patch? Do not treat those protections as proof of runtime remediation. Confirm the server update separately.
Should I always switch back after an error? No. The objective is a compatible patched runtime, not leaving the public site on a known vulnerable release.
Official sources and verification date
Checked on 22 October 2026. Consult the PHP advisory and CERT-EU for affected and fixed versions, WordPress for version checks and recovery, and Hostinger for panel instructions. This is general administration guidance; your host must confirm the actual configuration. The feature image is a conceptual AI illustration.
WordPress: PHP version and updates
Also read: SBI data leak and fake KYC calls
