Find your host
Pick your host and the exact product you pay for. Each guide shows where the PHP controls live and what to ask support.
- SiteGroundSite Tools → Devs → PHP Manager; host rollout confirmation
- GoDaddyManaged WordPress production settings; separate product routes noted
- FlywheelSite → Advanced; staging checked separately
- WP EngineEnvironment → Updates → PHP
- KinstaMyKinsta site/environment → Tools → PHP settings
- BluehostcPanel → MultiPHP Manager; other products use support
- HostingerhPanel → PHP Configuration; check every site on the plan
- HostGatorWebsite → Advanced → PHP Version, or cPanel
- DreamHost / DreamPressSeparate website panel and DreamPress staging routes
- CloudwaysApplication Settings → PHP Settings; check maintenance status
- PressableExisting site's PHP Version dropdown
- WordPress.comPlatform-managed PHP; server controls where available
- Nexcess / Liquid WebSite Management → PHP; separate SiteWorx route
- InMotion HostingcPanel → MultiPHP Manager
- hosting.com / former A2 HostingcPanel PHP selector; product-dependent support fallback
- GreenGeekscPanel → Select PHP Version; account-wide/override checks
- NamecheapEasyWP support; separate shared/business cPanel routes
- IONOSManaged WordPress support; separate Linux Web Hosting selector
- WPXPlan → Control Panel → PHP → website
- PantheonPlatform point releases; Git configuration for branch changes
No guide for that host yet. Use the checklist and support request below; they work with any host.
Fixed versions
These are the first upstream PHP releases that fix both CVE-2026-109618 and CVE-2026-109619.
| PHP branch | First fixed release | Security support ends |
|---|---|---|
| 8.2 | 8.2.35 or later | 31 December 2026 |
| 8.3 | 8.3.36 or later | 2027 |
| 8.4 | 8.4.27 or later | 2028 |
| 8.5 | 8.5.12 or later | 2029 |
Vendor backports may keep an older version number. Require the complete revision and written coverage of both CVEs. Sources: PHP release, supported versions.
A selector that only shows “PHP 8.4” proves nothing. If your host confirms your current branch is patched, keep it.
What happened
On 21 October 2026, PHP released fixes for two critical flaws that allow unauthenticated remote code execution and called for immediate updates. They affect web-serving PHP, including FPM, mod_php, CGI, FrankenPHP and LiteSpeed. mod_php has the highest stated risk. WordPress runs on PHP, so updating WordPress or plugins does not replace the runtime patch. PHP announcement
CVE-2026-109618 · GHSA-w8hw-w9fx-j79w · Critical · CVSS v4 9.2
Remote code execution via out-of-memory corruption
PHP request state can remain invalid after an allocation failure, and cleanup may consume it. Remote code execution over HTTP is confirmed for mod_php before application code runs. The advisory also considers FPM susceptible. Official advisory
CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp · Critical
Remote code execution via stale global state
Request-owned state can outlive its memory and be used by a later request on the same worker. The advisory describes confirmed mod_php paths and application-dependent FPM paths. Default session upload progress can take part without the application calling session_start(). Official advisory
Checklist
A PHP branch selection is not proof of this security patch. Managed hosts install the runtime; the customer selector usually chooses from installed branches. General auto-update policies and mitigation or WAF notices do not establish an individual site’s completed runtime patch. Use these steps with your host’s guide.
- Record the provider product, domains, staging environments, current PHP runtime and a restorable backup reference. Test a necessary branch migration on staging before production.
- Follow the provider’s documented control path. If your plan shows different controls, ask support for its route; do not substitute instructions from another product.
- Confirm the complete patch build, serving-node coverage and replacement of old PHP workers. Do not wait for a branch migration if the provider can patch the existing branch.
- In WordPress Tools → Site Health → Info → Server, record the full web PHP version. If the plan hides it, request evidence from support. A selector showing “8.4” or a CLI version alone is insufficient.
- Test dynamic login/session behavior, a form, upload and checkout where relevant. Save evidence per site, including sites affected by account-wide controls.
- If patching is unconfirmed, request an ETA and restriction of affected public origin/PHP access. If an update breaks compatibility, recover on a patched compatible runtime; keep a vulnerable fallback isolated.
Need proof for every server, worker and rollback? Read validate and recover safely. WordPress PHP guidance supplies the Site Health route.
Support request
Fill in the brackets and send it to your host. Ask for a written answer.
Subject: Urgent: confirm PHP patches for CVE-2026-109618 / CVE-2026-109619 Please confirm the status for these managed WordPress sites: - Hosting account: [account reference] - Domains, including staging: [list] PHP's 21 October 2026 security release fixes CVE-2026-109618 and CVE-2026-109619. Please provide: - The complete installed PHP version/build or vendor revision and evidence that it fixes both CVEs. - Confirmation that the update covers every serving node/PHP handler for these sites and that old workers have been replaced. - The completion time, or a concrete ETA if still pending. - Any site-owner action needed, and an access restriction option if the runtime cannot be patched promptly. Please also confirm the available backup/recovery path before any PHP branch change.
Change record
Keep one per site. It’s your proof the fix landed and your map if something breaks.
- Site/app and environment
- Owner and operator
- Change start/end (UTC)
- Public exposure and SAPI
- Before: web/CLI PHP version and complete package revision/image digest
- After: web/CLI PHP version and complete package revision/image digest
- Evidence the build fixes CVE-2026-109618 AND CVE-2026-109619
- Download/signature/hash evidence
- Backup/snapshot reference (no credentials)
- Applied transaction/deployment reference
- Every pool/replica/background worker replaced; evidence
- Actual dynamic web runtime checked; evidence
- Smoke checks and error-rate/log results
- Rollback threshold and recovery route
- Restrictions/remaining exposure
- Final status, owner and next action
If you can’t patch yet
The official advisories say a complete update is the only reliable fix. Configuration changes reduce specific paths; they do not make a server safe. Ask your host for an ETA and to restrict access to the affected origin or PHP service until the patched runtime is running.
If you run the server yourself, the advisories list partial measures. Apply them administratively, before request parsing; runtime ini_set() is not enough.
- CVE-2026-109619: disable
session.upload_progress.enabledand restart every worker. On PHP 8.5, also disablefatal_error_backtraces. Other stale-state variants remain possible. Advisory - CVE-2026-109618: PHP lists
memory_limit=-1as a partial fallback, with conservative body and input limits and an external availability boundary. It changes denial-of-service exposure, so don’t deploy it blindly. Advisory
PHP 8.1 and earlier get no ordinary upstream updates. Get an explicit vendor backport that covers both CVEs, or move to a supported branch (8.2–8.5). Patching prevents the known paths; it does not remove an existing compromise. See signs of possible compromise.
Questions
What are CVE-2026-109618 and CVE-2026-109619?
Two critical PHP vulnerabilities fixed in PHP’s 21 October 2026 security release. PHP confirms both allow unauthenticated remote code execution. CVE-2026-109618 is out-of-memory corruption (CVSS v4 9.2); CVE-2026-109619 is stale global state. They affect web-serving PHP, including FPM, mod_php, CGI, FrankenPHP and LiteSpeed. mod_php has the highest stated risk.
Which PHP versions fix them?
The first fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Use that release or a later stable one in the same branch. A host’s vendor backport may keep an older version number; in that case ask for the complete revision and written coverage of both CVEs.
Does updating WordPress or my plugins fix this?
No. The flaw is in the PHP runtime, not in WordPress. Updating only application code does not replace the PHP runtime patch. On managed WordPress hosting, your host installs the runtime, so the fix comes from them.
How do I check my PHP version in WordPress?
Open Tools → Site Health → Info → Server and record the full PHP version, such as 8.3.36, not just “8.3”. A hosting selector that shows “8.4” or a command-line version alone is not enough. If your plan hides it, ask support for evidence.
Should I switch PHP versions in my hosting panel?
Not just to respond to this. Choosing a branch in a selector is not proof of the security patch; the host installs the runtime and the selector picks from what is installed. If your host confirms your current branch is patched, keep it. Test any necessary branch change on staging first.
Can a WordPress plugin or firewall fix it?
No. You do not need to compile PHP, upload archives or install a plugin. A WAF or mitigation notice alone does not establish that your site runs the patched runtime. The official advisories say a complete update is the only reliable fix.
What should I ask my hosting provider?
Ask for the complete installed PHP build or vendor revision with evidence it fixes both CVEs, confirmation that every serving node is covered and old PHP workers were replaced, the completion time or an ETA, and an access restriction option if they cannot patch promptly. Copy the support request on this page.
What if my host has not patched yet?
Ask for an ETA and a way to restrict public access to the affected origin or PHP service until it is fixed. A promised automatic update is pending until completion is confirmed.
What about PHP 8.1 and earlier?
PHP 8.1 and earlier have no ordinary upstream updates. Get an explicit vendor backport that covers both CVEs, or move to a supported branch (8.2–8.5).
Sources and limits
- PHP release announcement, 21 October 2026
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- PHP supported versions
- WordPress: Update PHP
These walkthroughs were researched from official public documentation, not inside signed-in provider accounts. Menu labels can vary by plan, region or dashboard revision. A source citation verifies the documented procedure; it is not confirmation that any provider has completed this incident’s rollout for your site. No hosting accounts were accessed, support messages sent or runtime changes applied.
Each host guide lists the provider’s own documentation. Clarity Messaging is not affiliated with any provider listed. Host names are trademarks of their owners.