PHP Vulnerability 2026: Critical Flaws CVE-2026-109618 and CVE-2026-109619 and How to Patch Your Site

Before you start: take a full backup (files and database) before you patch the PHP vulnerability 2026 and, where possible, test the PHP update on a staging copy of your site first. A new PHP version can occasionally break an old plugin or theme, and a backup turns that into a five-minute fix instead of a crisis. Our guide on how to safely update WordPress without breaking your site covers the backup and staging steps in more detail.

Why the PHP vulnerability 2026 matters for your site

PHP is the engine behind WordPress, Joomla, Laravel, Magento and a huge share of the web. A PHP vulnerability is a flaw in that engine itself, not in one plugin or theme. That means your site can be exposed even when every plugin is up to date and your own code is clean.

On October 21, 2026, the PHP project released emergency security updates for two critical flaws tracked as CVE-2026-109618 and CVE-2026-109619. Researchers have nicknamed the pair “PHP2Shell”. This guide explains what they are, who is affected, and exactly how to patch, even if you have never touched a server.

Overview of the two CVEs

Both flaws in the PHP vulnerability 2026 advisory are rated 9.2 (Critical) on the CVSS v4.0 scale, and both can allow unauthenticated remote code execution (RCE). In plain terms, a visitor who has never logged in could potentially get your server to run commands of their choosing.

Both identifiers match PHP’s official advisory (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp), and security vendors report that CVE.org assigned them on October 21, 2026. The records are only days old, so details in third-party databases may still be changing. Treat php.net as the source of truth.

Affected and fixed versions

• Affected: PHP 5.4 through 8.5.11, so the flaws reach back more than a decade.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• PHP 8.1 and older: no standard update from the PHP project. Some Linux distributions and long-term-support vendors ship backported fixes, so ask yours, or upgrade to a supported version. For people who build from source, the PHP security team also published minimal backports for PHP 7.4, 8.0 and 8.1. PHP 8.2 itself reaches end of life on December 31, 2026 (see PHP’s supported versions page), so plan a move to 8.4 or 8.5.

Who is at risk

PHP says every installation serving web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php considered the highest risk. WordPress, Joomla, Laravel, WooCommerce and every other PHP application inherit the problem because they run on the affected engine.

How the PHP vulnerability 2026 flaws work

Both are memory-safety bugs (use-after-free) inside PHP’s core. Think of a hotel housekeeper who is interrupted halfway through preparing a room. The next shift assumes the room is ready and uses supplies that were never properly set up, or that were already thrown away.

• CVE-2026-109618: if PHP runs out of memory while setting up request data, it can be interrupted while that data is only partly initialized. Cleanup then treats the half-built data as valid, which corrupts memory.
• CVE-2026-109619: request-owned data can outlive the memory behind it. A later request handled by the same worker may then use that stale data before PHP resets it.

What makes this serious is where it happens. The problem sits in the engine’s request handling, so a demonstrated attack can trigger before any WordPress or Laravel code runs. Security plugins that live inside your application cannot see it coming. Vendors have publicly described one confirmed path involving PHP’s upload-progress feature, which is why you will see it mentioned in the interim steps below.

For balance: reliable exploitation takes specific conditions. Red Hat, for example, rates CVE-2026-109618 as Important rather than Critical for its builds and notes that PHP-FPM setups make exploitation harder. PHP’s own position is still unambiguous: only an update is a complete fix.

Exploit availability and real-world risk

Details of the flaws leaked online on October 20, before the patches shipped. Researchers at watchTowr confirmed that remote code execution is real, and security vendors reported early attack activity on October 21, the day the fixes were released. Web application firewall providers have since added rules for the publicly circulating exploit pattern.

Palo Alto Networks’ Unit 42 reported more than 22.6 million internet-exposed instances that are potentially vulnerable, based on its own telemetry. That is a vendor estimate, not an exact count of hacked sites.

The takeaway: this is urgent, but not a reason to panic. Patching is a routine, well-understood task, and the steps below are in priority order. This article deliberately omits exploit details; follow the official advisories if you need technical depth.

Immediate action plan

Step 1: Check your current PHP version

You need to know which version is serving your website, which can differ from the version on the command line.

1. In WordPress, go to Tools → Site Health → Info → Server and read the PHP version.
2. In cPanel, open MultiPHP Manager to see the version assigned to each domain.
3. Create the c-check.php file described in Step 4 for a definitive answer.

If your version is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (and you have no vendor confirmation of a backported fix), you need to update.

Step 2: Update to the latest patched release

Aim for PHP 8.5.12 or newer. If 8.5 is not available from your host, use 8.4.27 or newer. PHP 8.3.36 and 8.2.35 are also patched, but older branches are closer to end of life. Check that your plugins and theme support the version you choose.

Step 3: Apply the update

Option A: cPanel (MultiPHP Manager)

1. Log in to cPanel and open MultiPHP Manager.
2. Tick your domain and choose PHP 8.4 or 8.5 from the dropdown, then click Apply.
3. Important: selecting “8.4” gives you whatever 8.4.x build is installed on the server. Confirm the exact patch level with the version-check file below. If it shows an older build, your host has not yet installed the fixed package. CloudLinux and cPanel’s EasyApache 4 packages have been reported as released, but availability varies by host.

Option B: Terminal (SSH) on your own VPS or server

Replace 8.4 with your branch. Run php -v first to see where you stand.

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade 'php8.4*'
sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2     # or: sudo systemctl restart nginx

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Linux distributions often backport fixes without changing the headline version number, so php -v may not read 8.4.27 even when you are patched. Check the package changelog instead:

apt changelog php8.4-common | grep -n "CVE-2026-109618"
rpm -q --changelog php | grep "CVE-2026-109618"

PHP’s advisory also warns that the volunteer-run Remi repository may lag behind. If you use it, switch to distribution packages or build from source.

Option C: No terminal access

• Use your control panel’s PHP selector (Plesk, hPanel, DirectAdmin or similar) and select the newest patched version.
• On managed WordPress hosting, use the dashboard’s PHP version switch, or open a support ticket.
• With Docker, pull the newest tag for your PHP branch, rebuild, redeploy and verify.

Step 4: Create a version-check file (c-check.php)

Create a file named c-check.php in your site’s web root (often public_html) with this content:

<?php
header('Content-Type: text/plain');
echo 'PHP version: ' . PHP_VERSION . "n";
echo 'Server API: ' . PHP_SAPI . "n";

Visit https://yourdomain.com/c-check.php. The page shows the version your website is actually running, which is the one attackers reach. Compare it with the fixed releases above.

Delete the file as soon as you have the answer. Leaving version information publicly available helps attackers fingerprint your server.

Step 5: Add supplementary protections

PHP is explicit that these measures reduce exposure to specific attack paths but do not make a server safe. Use them as a bridge until you are patched, not as a substitute.

A web application firewall (WAF). Cloudflare, your host’s firewall or a security service such as Imunify360 can block known exploit patterns. Check whether your provider has published a rule for these CVEs. A WAF only catches patterns it knows about, so it cannot replace the update.

PHP limits. In cPanel, use MultiPHP INI Editor. Here is what PHP’s advisory suggests and the trade-offs:

• post_max_size = 8M: recommended for sites that do not need large uploads (PHP suggests 32M if uploads are necessary). The trade-off is that large media uploads in WordPress will fail until you raise it.
• upload_max_filesize: keep it below post_max_size.
• memory_limit: PHP’s interim advice for CVE-2026-109618 sounds backwards: set -1 (unlimited), ideally where applications cannot override it. The trade-off is real: one runaway request could consume all server memory. This suits servers where you can also enforce container or cgroup limits. On shared hosting, skip it and prioritize the update. Do not use RLIMIT_AS or RLIMIT_DATA as a substitute, because they can trigger the very failure involved.
• max_execution_time: PHP gives no specific number here. Leave it at a sensible value (often 30 to 60 seconds) and avoid raising it. Setting it too low can break imports and backups.
• session.upload_progress.enabled = 0: blocks the confirmed path for CVE-2026-109619 but not other variants. It must be set in php.ini or server-level configuration and all workers restarted. PHP warns that ini_set() and .user.ini files are not reliable for it, and some shared hosts apply cPanel changes through .user.ini, so ask your host.

Step 6: If you are on shared hosting, contact your provider

On shared hosting the server’s PHP packages are managed by your host. Open a support ticket today:

“Hello, please confirm when PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (fixing CVE-2026-109618 and CVE-2026-109619) will be available on my server, and let me know when it’s installed.”

Ask them to confirm the exact patch level and whether they have WAF rules in place meanwhile. If your host cannot give a timeline, consider moving to a provider that patches quickly.

Post-update verification and ongoing security hygiene

After updating:

1. Re-run c-check.php (or Site Health) and confirm the patched version, then delete the file.
2. Browse your site and admin area, and check your PHP error log for new warnings.
3. Restart PHP-FPM or Apache if you changed settings, because workers keep old settings until restarted.
4. Review logs and scan for unfamiliar PHP files, new admin users or odd scheduled tasks, particularly if you were unpatched since October 20 or 21.

Long-term habits that make the next advisory painless:

• Subscribe to the php.net announcements and your host’s security notices.
• Keep automatic backups and a staging site ready.
• Retire unsupported PHP branches before they reach end of life.
• Keep WordPress core, plugins and themes updated, since attackers combine vulnerabilities.
• Use a WAF and a malware scanner as a second layer, not the first. Our WordPress security checklist has more ideas.

Patch today

The PHP vulnerability 2026 flaws, CVE-2026-109618 and CVE-2026-109619, are serious, but the fix is clear: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor’s confirmed backport), verify it, and delete your check file. Do this today, and if you are on shared hosting, send that support ticket now.

Found this useful? Share it with a site owner who might not have seen the news, and subscribe to wpeducated.com for more practical WordPress and web security guides. For the latest details, always check the official PHP advisory at php.net, and read this Help Net Security report for a clear summary.