Critical PHP Vulnerabilities: Is Your Website at Risk, and What Should You Do Now?

On 21 October 2026, the PHP Security Team released fixes for two critical vulnerabilities in PHP itself: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4.0, and both can allow an attacker to run code on a server without logging in. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

If your site runs on PHP – and that includes WordPress, WooCommerce, Drupal, Magento and Laravel – the first job is simple: find out which PHP version your site uses and confirm that it includes these fixes. The rest of this guide shows you how, whether you're on shared hosting or running your own server.

If you answered “not sure” to any of these, read on. Each section below closes one of those gaps.

What Are CVE-2026-109618 and CVE-2026-109619?

They are two separate memory-handling flaws in the PHP engine that can, under the right conditions, let an unauthenticated attacker execute code on the server. The PHP Security Team gave advance notice on 20 October and shipped the fixes on 21 October 2026 at 14:00 UTC. Some security vendors refer to the pair as “PHP2Shell”.

Three terms worth knowing: a CVE is the public ID assigned to a specific vulnerability. CVSS scores severity from 0 to 10, and anything from 9.0 up counts as critical. Remote code execution (RCE) means an attacker can run their own code on your server from anywhere on the internet.

How Serious Is This for Your Website?

Serious enough to patch today. According to the PHP Security Team, every PHP installation that serves web requests is in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk is on mod_php, where the team demonstrated an exploit in which a single unauthenticated request triggers the attack before any application code runs.

If an attacker succeeds, the possible consequences include:

• running unauthorised code on the server
• modifying website files or injecting malicious content
• planting backdoors or malware for later use
• exposing customer, order or contact data from your database
• slowing the site down, taking it offline, or getting it flagged by search engines

Is it being exploited?

Here is where things stood on 23 October 2026. Several public proof-of-concept exploits exist, though Rapid7 found that each one works only against a specific combination of operating system, PHP version and web server. Rapid7 expects exploitation in the wild, although its own tests had produced a working exploit only under narrow lab conditions. The Canadian Centre for Cyber Security had identified no active exploitation, while warning that this “can change quickly”. Germany's BSI issued an urgent warning and expects attack waves. In short: don't wait for confirmed mass exploitation before you act.

None of this means every PHP site has been compromised. Whether an attack works depends on your PHP version, server setup and patch status.

Which PHP Versions Are Affected?

All four officially supported PHP branches were affected, and each now has a fixed release. Your site should be on one of these versions – or on your provider's package that contains the same fixes.

PHP 8.1 and older no longer receive updates from the PHP project. Because of the severity, the security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build PHP themselves, and many Linux distributions and long-term-support vendors ship their own patched packages. Those patches close these two holes only. They don't bring an old branch back into support.

A common trap: when a Linux distribution backports a fix, the version number often stays the same. A server can report “8.3.x” and be patched, or not. Check your package changelog or your provider's announcement rather than relying on the number alone.

Don't forget bundled PHP. Docker images, appliances and some commercial products ship their own copy of PHP. Patching the host doesn't patch a container image – rebuild and redeploy it from an updated base image.

Update from 23 October: session upload progress

On 23 October 2026 the PHP Security Team published an informational advisory recommending session.upload_progress.enabled=0 until the next regular bugfix release. The setting was already listed as a mitigation for CVE-2026-109619, so if you applied it then, simply leave it in place. The new issue (CVE-2026-115560) only arises with an unusual combination of configuration and application code, which is why it will be fixed in the normal release cycle.

WordPress, WooCommerce, Drupal, Magento and Laravel: Am I Affected?

Not because of a flaw in your CMS or framework – but yes, if the PHP runtime underneath it hasn't been patched. Updating WordPress core, your theme or your plugins does not fix this vulnerability. The same applies to Drupal modules, Magento extensions and Composer packages in a Laravel app.

Think of PHP as the foundation of a house and your CMS as everything built on top of it. A fresh coat of paint upstairs won't fix a crack in the foundation. That's why there are two separate to-do lists:

How to Check Your PHP Version

The quickest route is your hosting control panel or your CMS dashboard. Menu names can differ slightly depending on your provider and panel version.

• cPanel: Under Software, open MultiPHP Manager (or Select PHP Version) to see the PHP branch assigned to each domain.
• Plesk: In Websites & Domains, open the domain's PHP (PHP Settings) page to see the version and the PHP handler (FPM, CGI, etc.).
• WordPress: Go to Tools → Site Health → Info → Server. Site Health also warns you if your PHP version is outdated.
• Command line: Run php -v, and for FPM php-fpm -v (on some distributions php-fpm8.3 -v). The CLI and the web server can use different PHP binaries, so check both.

How to Upgrade Your PHP Version: Step by Step

On shared hosting you can usually change your PHP version in a few clicks: MultiPHP Manager in cPanel, or the domain's PHP settings in Plesk. First, it helps to separate two things that often get mixed up:

• A security update within the same branch (e.g. 8.3.35 → 8.3.36): this is what closes these vulnerabilities. On shared and managed hosting your provider does it on the server; there's usually nothing for you to select.
• A branch upgrade (e.g. 8.1 → 8.3): this is how you leave an unsupported version. You pick it in your control panel, and it needs a short compatibility check.

Which branch should you choose? The newest supported branch your host offers. As of 23 October 2026 the supported branches are 8.2, 8.3, 8.4 and 8.5. Because PHP 8.2 will reach end of life on 31 December 2026, 8.3 or later buys you more time. Coming from 8.1 or older, you don't need to step through each branch in between – what matters is that your plugins and theme support the target version.

Before you start: three quick checks

1. Back up. Back up your files and database together, using your panel's backup tool or a backup plugin.
2. Check compatibility. On each WordPress plugin page, look at the minimum PHP version and when the plugin was last updated. Plugins that haven't been touched in years cause most upgrade problems.
3. Update your CMS first. Bring core, theme and plugins up to date before switching branches. If you can, rehearse the switch on a staging copy.

Changing the PHP version in cPanel

1. Log in to cPanel and open MultiPHP Manager under Software.
2. Tick the box next to the domain you want to change (1).
3. Choose the target version from the drop-down, for example PHP 8.3 (2).
4. Click Apply (3). The change usually takes effect within seconds.

Some servers show Select PHP Version (the CloudLinux PHP Selector) instead. The idea is the same: pick a version and save. PHP extensions are configured per version there, so after switching, check that the extensions your site needs (for example intl, imagick or zip) are enabled on the new version too.

Changing the PHP version in Plesk

1. Go to Websites & Domains, find your domain and click PHP (in some versions PHP Settings) (1).
2. Choose the target release from the PHP version list (2). Leave the PHP handler (FPM, CGI, etc.) as it is unless you have a specific reason to change it.
3. Save with Apply or OK (3).

Confirming the new version in WordPress

Check that the change actually reached your site. If you use a caching plugin, clear the cache first.

1. In the dashboard, open Tools → Site Health (1).
2. Switch to the Info tab (2).
3. Expand Server and read the PHP version row (3). On the 8.3 branch, 8.3.36 or later includes the 21 October fix.

If you manage your own VPS or server

On your own server you update PHP through the operating system's package manager. The commands below are examples; package names depend on your distribution and the PHP repository you use.

# See the current version (CLI)
php -v

# Debian / Ubuntu example – security update within the same branch
sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky example
sudo dnf upgrade "php*"
sudo systemctl restart php-fpm

# Using Apache mod_php? Restart the web server too
sudo systemctl restart apache2   # on RHEL-based systems: httpd

Don't skip the restart: if old PHP workers stay in memory, the patch isn't live. Confirm that your repository really ships the 21 October fixes by checking the package changelog (on Debian/Ubuntu, for example, apt changelog php8.3-fpm). Switching branches means installing the new branch alongside the old one and pointing your web server or FPM pool at it; the exact steps vary by distribution.

If something breaks: a safe recovery plan

A white screen or a “500 Internal Server Error” after an upgrade is fixable. Your first instinct shouldn't be to roll back to the old PHP version – if that version isn't patched against these vulnerabilities, you'd be reopening the door. Work through this order instead:

1. Find the cause. Your PHP error log or WordPress's debug.log usually names the failing plugin or theme within the first few lines.
2. Disable the culprit. Can't reach the dashboard? Rename the plugin's folder in your file manager (e.g. plugin-name → plugin-name-off), and WordPress will stop loading it.
3. Update or replace it. Install the developer's latest version or switch to an alternative that supports the new PHP version, then reactivate it.
4. Restore from backup if the site is badly broken. Restore the backup you took before the upgrade – but keep the new PHP version and solve the issue on a staging copy.

Your Action Plan: Protecting Your Site Step by Step

Updating PHP to a fixed release is the only complete fix. The PHP Security Team is explicit that temporary measures do not make an installation safe. This order cuts the risk quickly while keeping the chance of breaking your site low:

1. Identify your PHP version – the branch, and the exact release if you can.
2. Check your provider's announcement – status page, email or support channel.
3. Confirm the fix is in place – 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or later, or written confirmation of a patched package.
4. Take a fresh backup and test that it restores.
5. Run a short compatibility check – essential when changing branch, usually unnecessary for a same-branch security update.
6. Apply the update in a controlled way – pick a quiet hour and restart PHP-FPM or the web server so old workers exit.
7. Test the site using the post-update checklist below.
8. Look for signs of compromise – recently changed files, new admin accounts, unusual requests in access logs, unexpected outbound connections.

A security update within the same branch doesn't need weeks of testing. Compatibility checks should never become a reason to leave a critical patch uninstalled for days.

Temporary mitigations for server administrators

If you run your own server and genuinely can't update for a few hours, the PHP Security Team lists measures that narrow specific attack paths. They do not make the installation safe and are not a substitute for updating:

• For CVE-2026-109619: set session.upload_progress.enabled=0 somewhere applications can't override it (php.ini, the FPM pool or server configuration) and restart every worker. Don't rely on ini_set() or .user.ini. On PHP 8.5, fatal_error_backtraces=0 also blocks one confirmed path.
• For CVE-2026-109618: lower post_max_size (8M if you don't need uploads, 32M if you do) and keep upload_max_filesize below it. Enforce limits on request size, field count and header count at the web server or proxy.
• Hiding errors with display_errors or @ doesn't help. Attacker-reachable fatal errors and timeouts need to be fixed.
• For internet-facing systems you can't patch yet, consider isolating them from public access, as the Canadian Centre for Cyber Security recommends.

Post-update test checklist

What If You Suspect Your Site Was Compromised?

Patching closes the door, but it doesn't remove anyone who may already be inside. If you notice unfamiliar files, unknown admin users, spam pages or redirects, treat it as an incident:

• Keep the logs and take a snapshot before you change anything – you'll need them to understand what happened.
• Change all passwords (hosting panel, database, CMS admins, SFTP) and rotate API keys and secrets stored on the server.
• Restore from a clean backup taken before the suspected compromise, then patch PHP before going live again.
• If personal data may have been accessed, check your legal duties. Under the GDPR and UK GDPR, a reportable breach generally has to be notified to the supervisory authority within 72 hours of becoming aware of it; other countries have their own rules. A data protection adviser can help you decide.

Who Is Responsible for Patching: Your Host or You?

Short answer: on shared and managed hosting, your provider normally patches PHP; on an unmanaged VPS or dedicated server, it's your job. Your CMS, plugins and content remain largely your responsibility in every model.

This is a typical split; your contract and plan define the exact scope. If you're unsure, ask your provider:

• Does my server's PHP include the 21 October 2026 security fixes, and when were they applied?
• Is my PHP branch still officially supported? If not, when and how should I move?
• Were PHP worker processes restarted after the update?
• How often are backups taken, how long are they kept, and how do I request a restore?

Why Running an Old PHP Version Is Risky

An end-of-life PHP version receives no official fixes for newly discovered vulnerabilities. Even if it gets a one-off patch today, the next flaw may never be fixed.

PHP's support model is straightforward: each branch gets two years of active support, then two years of critical security fixes only, and then it reaches end of life. PHP 8.2 will reach end of life on 31 December 2026. If you're on 8.2.35 you're protected against these two vulnerabilities, but you should plan a move to 8.3 or later within the next two months.

Backports from providers or distributions are a valuable stopgap. They fix specific vulnerabilities, though – not the other known issues, missing performance improvements or growing incompatibility with modern plugins. The lasting fix is a supported branch.

Choosing a Hosting Provider That Takes Security Seriously

Incidents like this show that a host's security processes matter as much as price and disk space. When comparing providers, ask:

How Atak Domain hosting plans match these criteria

You can weigh these criteria against Atak Domain's web hosting plans. The details below are taken from the features listed on the product page; they are not a statement about this specific PHP incident.

Frequently Asked Questions

Does this PHP vulnerability affect my website?

If your site runs on PHP (WordPress, WooCommerce, Drupal, Magento, Laravel and so on) and the server's PHP doesn't yet include the 21 October 2026 fixes, it's in scope. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched vendor package closes both holes. Being in scope doesn't mean your site has been hacked.

Do I need to update PHP right away?

Yes. The PHP Security Team urges every user to update immediately. A security update within the same branch (for example 8.3.35 to 8.3.36) rarely causes compatibility issues. On shared hosting your provider applies it – your job is to confirm it's done.

If WordPress is up to date, is PHP safe too?

No. Updating WordPress core, themes and plugins doesn't patch the PHP runtime. PHP has to be updated separately on the server. They are different layers, and each needs its own updates.

Will my host patch PHP automatically?

On shared and managed hosting, usually yes – though timing and scope vary between providers. On an unmanaged VPS or dedicated server, it's up to you. The safest approach is to get written confirmation from your host that the patch is in place.

Will changing my PHP version break my site?

A security update within the same branch rarely breaks anything. Changing branch (for example 8.1 to 8.3) can trip up old plugins or themes. Back up first, test on staging if you can, and run the post-update checklist.

Is PHP 8.2 still safe?

PHP 8.2.35 fixes these two vulnerabilities. However, PHP 8.2 will reach end of life on 31 December 2026, after which new vulnerabilities won't be fixed. Plan your move to 8.3 or later in the coming weeks.

Does an SSL certificate protect me?

No. SSL encrypts traffic between the browser and your server; it doesn't fix a flaw in the PHP running on that server. Malicious requests can travel over an encrypted connection too. A WAF or malware scanner can reduce risk but can't replace the update.

Should I take my site offline?

Usually not. The priority is to update PHP and confirm the fix. If you run a critical server you can't patch yet – especially one using mod_php – restricting access until it's updated is worth considering. That's a call based on your own risk assessment.

What should I do if I run a VPS?

Update PHP from your distribution's security repository (or build the 21 October release from source), restart PHP-FPM and the web server, then confirm with php -v and the package changelog. If several PHP versions or container images are in use, check each one.

Bottom Line: Update First, Then Verify

CVE-2026-109618 and CVE-2026-109619 are rare vulnerabilities in PHP itself that can lead to remote code execution. The good news: fixes are out for every supported branch.

Three things to do today: find out your PHP version, confirm the fix is installed, and make sure you have a recent backup. If you're still on PHP 8.1 or older, this is also the right moment to plan your move to a supported branch.

Treating security as routine maintenance rather than a one-off emergency is the least stressful approach in the long run. A supported PHP version, regular backups and support you can actually reach are its three building blocks.

Sources

• PHP: Security advisory – Critical remote code execution vulnerabilities (21 Oct 2026)
• PHP: Informational advisory – Session upload progress (23 Oct 2026)
• PHP: Supported Versions
• Canadian Centre for Cyber Security: Alert AL26-026
• Rapid7: CVE-2026-109618 and CVE-2026-109619 analysis
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp