
Published 21 October 2026
Website owners and server administrators should arrange an immediate PHP security update. On 21 October 2026, the PHP project published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws can allow unauthenticated remote code execution: an attacker may be able to run code through a vulnerable web-serving PHP runtime without first logging in to the site. PHP recommends updating; temporary settings or a web application firewall are not a substitute for the fixed runtime. PHP’s release and advisory notices identify the affected web-serving modes and fixed releases.
What changed, and which websites need attention?
The two flaws concern PHP runtime request handling: one involves out-of-memory corruption, and the other stale request-owned global state. This is not limited to a particular CMS or plugin. PHP says web-serving installations are affected, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. A WordPress, WooCommerce, Laravel or other PHP site may therefore be in scope because of the PHP engine serving its requests, regardless of whether its application code is current.
The listed fixed upstream versions are branch-specific: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Do not assume an older branch is safe because its version number looks familiar. PHP says users on PHP 8.1 and older should check whether their operating-system or long-term-support vendor supplies a backported fix, or plan a move to a supported patched branch. Ask the provider which package and patch status apply to your server; package versions may not match upstream numbering exactly.
Important: PHP says updating is the complete fix. If you cannot update immediately, contact the hosting or platform provider promptly about exposure and containment. Do not treat a WAF rule, a PHP setting, or a claim that your CMS is updated as proof that the runtime is patched.
Check the PHP version that serves the website
A common checking mistake is to run php -v over SSH and assume that result describes the website. That command reports the command-line PHP binary; the public site can use a different PHP version, handler, pool or container. On cPanel, MultiPHP Manager lists the PHP version assigned to each domain, while WHM’s EasyApache 4 controls server-installed PHP versions. A domain may also inherit a system default.
- List every public site: include addon domains, subdomains, staging sites, shop fronts, API endpoints and any separate application container.
- Check each domain’s assigned runtime: in cPanel, review MultiPHP Manager if available. If you manage the server, inspect WHM MultiPHP Manager and the installed PHP packages and handlers.
- Confirm the web SAPI: with authorised access, use a temporary, access-restricted diagnostic or a host-provided check to identify the version actually serving HTTP requests. Remove any diagnostic file immediately after checking; PHP’s
phpinfo()output can reveal configuration and environment details. - Ask when you lack server access: request confirmation of the patch status for every PHP handler used by your domains, including any selector-based or container runtime.
cPanel documents that MultiPHP Manager displays the PHP version for each domain, while installation of versions and server-wide changes depend on administrator access. A customer may not be able to install or patch the underlying runtime themselves.
Update through the supported package or hosting path
For a self-managed cPanel server, use WHM’s EasyApache 4 and the operating-system or cPanel-supported package path to install the available security update; cPanel documents EasyApache 4 for Apache PHP updates. Do not download and replace production PHP binaries by hand on a managed panel server. For a Linux distribution or cloud platform, apply the vendor’s patched package or rebuild and redeploy the runtime image following its current instructions.
- Record the starting point: note each domain’s PHP branch, handler, extensions and important application functions. Keep a recoverable backup and use a staging copy when available.
- Apply the provider-supported update: server administrators should follow the panel or operating-system vendor’s package guidance. Shared-hosting customers should contact their provider if the fixed package is not yet available or the account’s version cannot be changed.
- Test real workflows: load the site and check sign-in, checkout, payment callbacks, forms, file uploads, scheduled tasks and database-backed pages. Review PHP and web-server error logs for missing extensions or new fatal errors.
- Verify the public runtime again: confirm that every site is actually served by the patched release or by a vendor-confirmed package with the fixes backported. Check after any relevant worker restart or redeployment, then remove temporary diagnostic files.
Keep the application on its existing compatible PHP branch when installing a security point update; do not confuse patching within a branch with a major-version migration. If a branch jump is necessary because the current branch has no maintained fix, test application and extension compatibility first using the relevant PHP migration guide. PHP’s supported-version guidance also matters for longer-term maintenance: PHP 8.2 is due to reach end of security support on 31 December 2026, so owners on that branch should schedule a tested move to a maintained branch rather than treating this update as the end of their planning.
What hosting customers and agencies should do now
Customers on shared or reseller hosting may not control the server runtime, but they can still make the response concrete: identify affected domains, ask the provider about the patched package and rollout status, and retest business-critical paths after confirmation. If you operate multiple client sites, maintain a simple domain-to-PHP-branch register so one patched application does not hide an overlooked staging site or older shop.
HostCupid Web Solutions Private Limited is a Chennai-based provider of shared, WordPress, reseller and master-reseller hosting, website development and migration assistance. For a HostCupid customer, the relevant first step is to share the affected domain and ask which PHP runtime serves it and whether the host-supported security update is available; do not infer server patch status from a CMS update or a command-line version check. For agencies planning a migration, include runtime and PHP-branch verification in the handover checklist, but do not move a live store solely to avoid contacting its current provider.
Bottom line: inventory the web-serving PHP runtimes, update each through its supported vendor or host, and verify the version from the website’s actual execution path. For this pair of PHP flaws, an application-level update alone does not patch the PHP engine.
Sources
- PHP News Archive 2026 — security advisory and release notices dated 21 October 2026 · 2026-10-21
- Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 · 2026-10-21
- cPanel & WHM Documentation: MultiPHP Manager for cPanel
- cPanel & WHM Documentation: How to Update Your System
- PHP Manual: PHP command-line options
- PHP Manual: phpinfo
- PHP: Supported Versions
- CloudLinux: PHP CVE-2026-109618 and CVE-2026-109619 — interim package and mitigation status · 2026-10-21
Sources checked: 21 October 2026.
← More HostCupid Insights