---
title: "PHP security update: check your version and ask your host"
description: "Check your PHP version under Tools > Site Health > Info > Server, then ask your host if the October 21, 2026 PHP fix is installed for your site."
url: "https://webleveling.com/blog/php-critical-security-update-what-to-do/"
lang: "en"
published: "2026-10-21"
modified: "2026-10-21"
author: "Cal Hewitt"
tags: ["website-security","wordpress","website-maintenance"]
image: "https://webleveling.com/og/blog-php-critical-security-update-what-to-do.jpg"
alternates:
  es: "https://webleveling.com/es/blog/actualizacion-critica-de-seguridad-php-que-hacer.md"
---

# PHP security update: check your version and ask your host

Check your PHP version under Tools > Site Health > Info > Server, then ask your host if the October 21, 2026 PHP fix is installed for your site.

![A closed laptop, a blank notepad and a small external drive arranged neatly on a server rack shelf.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-security-update-featured.jpg)

The critical PHP security update released on October 21, 2026 is a fix to PHP on the web server, so WordPress needs no update for it. Your job tonight is two steps: read the PHP version under Tools > Site Health > Info > Server, then ask your host whether the October 21 release is applied to your site.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A site on a lower number in one of those branches is a reason to ask the host for the update. Linux distributions number their packages their own way, so the host's written answer is what settles it.

Sites on PHP 8.1 or older need a bigger step, because the PHP project no longer issues security updates for those versions. If that is yours, plan an upgrade to a supported version, with a backup in hand and a test copy first.

**Key Takeaways**

**Fix lives on the server**

PHP fixed CVE-2026-109618 and CVE-2026-109619 on October 21, 2026, and [WordPress.org says](https://wordpress.org/news/2026/10/critical-php-security-release/) no WordPress update is required or planned.

**Fixed versions**

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 carry the fix; PHP 8.1 and older get no security updates from the PHP project.

**Ten-minute check**

Tools > Site Health > Info > Server shows your PHP version, and one written question to your host shows whether the fix is installed.

**Settings are not a fix**

The interim settings in the advisory reduce exposure on certain paths, and only the update is complete.

**Signs to raise**

Memory-limit errors or repeated HTTP 500 errors after odd requests, oversized PHPSESSID cookies and unexplained PHP worker restarts call for a compromise check.

## The fix is a PHP update on the server, and WordPress needs none

On October 21, 2026, the PHP project published a [security advisory](https://www.php.net/archive/2026.php#2026-10-21-5) fixing two critical vulnerabilities that can allow remote code execution without a login. The first, [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), involves how PHP handles running out of memory while it reads a request. It can leave half-built data that later cleanup treats as valid, which corrupts memory.

The second, [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), involves leftover request state that stays in use after its memory is freed. A later request handled by the same worker can then use that stale state. Use both CVE numbers when you write to a host or developer, because they name exactly what changed.

PHP says installations serving web requests are at risk, and it names PHP-FPM, Apache mod\_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod\_php highest, because the demonstrated exploit can fire before any of your application code runs. A handler is whichever of these runs PHP for your site.

Fixed PHP releases and what each branch means

| Your PHP branch | Fixed release | Where it stands |
| --- | --- | --- |
| 8.5 | 8.5.12 | Supported by the PHP project |
| 8.4 | 8.4.27 | Supported by the PHP project |
| 8.3 | 8.3.36 | Supported by the PHP project |
| 8.2 | 8.2.35 | Supported; security support ends December 31, 2026 |
| 8.1 and older | None from the PHP project | Ask the host about a vendor backport, then plan an upgrade |

The [supported versions page](https://www.php.net/supported-versions.php) lists 8.2 through 8.5 as supported on October 21. This is a PHP issue, not a plugin issue, so a plugin update cannot change it. For plugin warnings, [how to check WordPress plugins for urgent security updates](https://webleveling.com/blog/check-wordpress-plugins-for-urgent-security-updates/) covers a different routine.

![A closed laptop beside a blank notepad and a sharpened pencil on a worn wooden desk.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-update-version-notepad.jpg)

A version number on a notepad is the first thing your host will want to see.

## Security firm Wiz discovered the flaws, and the risk is a takeover without a login

Security firm Wiz discovered the vulnerabilities with the help of AI models and reported them to the PHP security team on August 24, 2026. The patch and public disclosure followed on October 21. In its [write-up](https://www.wiz.io/blog/php2shell-php-rce), Wiz named the flaws PHP2Shell, and [NCSC-NL](https://github.com/NCSC-NL/php2shell) uses the label as well. The PHP project itself identifies them by CVE number.

In plain words, the first risk is takeover without a login. Wiz demonstrated remote code execution on the latest WordPress, Drupal and Joomla containers, and says the flaw sits in PHP itself, so even a simple app on an affected version can be exposed. Wiz rates severity up to 9.2 on the CVSS scale.

The second risk is quieter. Wiz says an attacker could also read memory from the PHP process, and that memory can hold passwords, tokens and API keys. NCSC-NL said on October 21 that it had no indication of active exploitation. That status can change, which is why the update, not the headline, is what to act on.

[BBC News reported](https://www.bbc.com/news/articles/cmly0lg3w5x2o) on October 21 that sites were taken offline worldwide, and it named the Finnish government, Edinburgh council and the BBC itself as having taken pages down. Several cyber-security agencies urged organizations that could not patch in time to consider taking sites down. That advice is aimed at servers that cannot be updated quickly, and your first move is still the version check.

## Two minutes in your dashboard tell you which PHP version you run

Version and handler are the two facts your host needs. In WordPress, [Site Health](https://wordpress.org/documentation/article/site-health-screen/) shows both in the Info tab, and WordPress.org points to the same screen or to your hosting panel.

1.  Sign in to the WordPress dashboard.
2.  Open Tools > Site Health.
3.  Select the Info tab and expand Server.
4.  Write down the PHP version, the web server line and any PHP handler or SAPI detail shown.
5.  Compare the version with 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

On a cPanel host, [MultiPHP Manager](https://docs.cpanel.net/cpanel/software/multiphp-manager-for-cpanel/) lists the PHP version for each domain and shows whether PHP-FPM is enabled. A host may limit which versions appear there. If you use a \`phpinfo()\` page for the same answer, delete it right after, because it exposes server details to anyone who finds it.

A number below the fixed release in your branch is a reason to ask for the update. A number at or above it is not proof that the right package is running for your domain, since a second PHP pool or a different handler can still be on an old build. That gap is what the written answer from your host closes.

## One written answer from your host settles whether the fix is installed

Who applies the update depends on where the site lives. On shared and managed hosting, the host usually handles the server package. On a VPS, the owner or administrator applies the operating-system package, and [Ubuntu's notice USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1) says a standard system update installs the fix on supported Ubuntu releases.

Host documentation shows how version updates work in general. [SiteGround says](https://www.siteground.com/kb/what-is-managed-php) Managed PHP periodically updates the default PHP version, and sites on a manually managed version are not updated automatically. [Kinsta says](https://kinsta.com/docs/wordpress-hosting/php/wordpress-restart-update-php/) automatic PHP updates are on by default and happen when a version reaches end of life. Whether the October 21 release is on your server tonight is a question only your host can answer, so ask.

Send the host this, word for word:

\> Please confirm whether the October 21, 2026 PHP security release fixing CVE-2026-109618 and CVE-2026-109619 is installed for my domain. Please tell me the active PHP version, PHP handler, package version, whether PHP-FPM or mod\_php is in use, and whether I need to take any action.

WordPress.org notes that your host may already be updating PHP and adding web application firewall rules, and that you should check with the host and update as soon as possible if needed. A reply that says only "we take security seriously" does not answer the questions. If your host cannot give a specific answer, [choosing web hosting for a small business](https://webleveling.com/blog/choosing-web-hosting-for-a-small-business/) sets out what to look for in a host that can.

![A sealed blank envelope and a pen resting beside a closed laptop on a tidy wooden desk.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-host-question-envelope.jpg)

One short written question to your host settles more than an hour of searching.

## PHP 8.1 or older needs a supported branch, tested before it goes live

PHP 8.1 and older no longer receive security updates from the PHP project. PHP says some distributions and long-term-support vendors may backport the fixes, and it supplied minimal source backports for 7.4, 8.0 and 8.1 for people who build from source or have no such vendor. A backport is not the same as moving to a supported branch.

So, the first question for an older site is whether the installed package contains fixes for both CVEs, and the second is when the site moves to 8.2 or newer. Since PHP 8.2 security support ends on December 31, 2026, 8.3 or 8.4 gives a longer runway. That date is also a reason to book the work now instead of in December.

WordPress guidance on [PHP versions](https://developer.wordpress.org/advanced-administration/performance/php/) recommends testing on a staging copy, checking plugins, themes and custom code, and keeping a backup you can restore before changing the live site. [Kinsta's safe-change workflow](https://kinsta.com/docs/wordpress-hosting/using-kinsta/kinsta-make-changes-safely/) follows the same order. Forms, logins, checkout and bookings are the pages to click through after the change.

If you run your own server on an older version, WordPress.org quotes the UK NCSC and other national agencies on one more option: consider taking the server offline while you prepare the update. That choice belongs to the person managing the server. A site on shared hosting waits on its host.

![A small external drive and a ring of brass keys resting on a clean desk beside a closed notebook.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-update-backup-before-upgrade.jpg)

A backup you have restored once is the one worth trusting before a PHP change.

## Interim settings reduce exposure but do not make a site safe

The advisory lists settings for people who cannot update at once, and PHP labels them as reducing exposure on particular paths, not as a fix. For CVE-2026-109618, it recommends setting \`memory\_limit=-1\` administratively with \`php\_admin\_value\` in the FPM pool or Apache configuration, making sure no other setting restores a finite limit. It also recommends lowering \`post\_max\_size\` and limiting uploads and request complexity.

For CVE-2026-109619, it recommends turning off \`session.upload\_progress.enabled\` and restarting every worker. On PHP 8.5 it adds \`fatal\_error\_backtraces=0\`, applied the same way. These change server configuration, so the host or a developer applies them, and a restart is part of the job.

Treat them as a holding step. A site with these settings and no update is still not patched, and a setting applied halfway can look finished while leaving a path open. If you sit behind a CDN or firewall provider, check that provider's notice as well. Wiz says Cloudflare, Akamai, AWS, Fastly, Google, Imperva, Microsoft, Vercel and Automattic prepared guidance and mitigations for customers who cannot patch immediately. Mitigation from a provider is also not a substitute for the update.

## Three signs call for a compromise check until the site is patched

Wiz lists signs to raise with your host or developer while a site is still unpatched. They are a reason to look closer, and none of them proves a break-in on its own.

- Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 errors
- Unexpectedly large or malformed PHPSESSID cookies
- Unexplained PHP worker restarts

Ask the host to look in the server logs for these. If your site was unpatched and shows any of them, treating stored passwords, tokens and API keys as possibly exposed is a reasonable precaution, and asking the host or developer about rotating them is a sensible step. It is a precaution, and it is not required of every owner. A site that is online is not proof of safety, and a site that is offline is not proof of an attack.

If a check does turn up something real, [what to do in the first 24 hours after a hack](https://webleveling.com/blog/website-hacked-first-24-hours/) lays out the order: preserve evidence, isolate the site, then clean or restore it. A [website security audit](https://webleveling.com/services/website-security-audit/) is the longer review for after the immediate fix.

![A clipboard holding a blank checklist sheet with a pen clipped to it, set on a metal server rack shelf.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-update-patch-checklist.jpg)

A written checklist keeps the host, the developer and you working from the same list.

## Paid help makes sense in a few specific cases

You can run the first check yourself, and you do not need a vendor for it. Version, handler, one email and a written reply are all within an owner's reach. Help starts to earn its fee when the answer is not simply a version number.

- The host cannot give a specific answer about your domain
- The site runs PHP 8.1 or older
- Custom code or older plugins are involved
- There is no staging copy to test on
- A backup cannot be restored

If none of those apply, a clear reply from the host and a quick click-through of your forms and checkout may be all this takes. If any do apply, a maintenance provider can find every PHP pool and handler, confirm the package source, build a staging copy, test the upgrade, restart the right workers and write down the result. That is the difference between a patch and a documented patch, and it is what a [web hosting](https://webleveling.com/services/web-hosting/) or maintenance plan should leave you with.

**Quiz: Check what you know about the October 21 PHP update**

1. Which fixes the two critical PHP vulnerabilities announced on October 21, 2026?
   - A WordPress core update
   - A plugin security update
   - A fixed PHP release installed on the server **(correct answer)**
   - A new SSL certificate
2. Where do you read your PHP version in WordPress?
   - Settings > General
   - Tools > Site Health > Info > Server **(correct answer)**
   - Appearance > Themes
   - Plugins > Add New
3. Your site runs PHP 8.1. What does the PHP project say about security updates for it?
   - It still receives them until 2027
   - It receives them only through plugins
   - It no longer gets them, so ask about a vendor backport and plan an upgrade **(correct answer)**
   - It does not need them

## Frequently Asked Questions About Critical PHP Security Update

**What is the latest PHP vulnerability?**

On October 21, 2026, the PHP project fixed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow remote code execution without a login. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

**Who found the PHP vulnerability?**

Security firm Wiz discovered it with the help of AI models, reported it to the PHP security team on August 24, 2026, and published its findings on October 21 under the name PHP2Shell.

**How do I update PHP in WordPress?**

WordPress does not update PHP itself. On cPanel hosting, MultiPHP Manager switches the version for a domain, and your host's own panel usually has a similar setting. For a security patch within your branch, ask the host to install the fixed release, and test on a staging copy before you change branches.

**What is the latest version of PHP?**

The newest branch PHP lists as supported is 8.5, and its fixed release is 8.5.12. The other fixed releases are 8.4.27, 8.3.36 and 8.2.35.

**Has the flaw been exploited?**

NCSC-NL said on October 21 that it had no indication of active exploitation. That can change, so patch now rather than waiting for confirmation.

**My host says it is managed. Am I covered?**

Ask for a written answer that names the two CVE numbers, your PHP version and your handler. A host's general description of its service does not tell you whether this release is installed for your domain.

## What This Means for You

The critical PHP security update is a server fix, so your work is a version check and a question. Read your PHP version in Site Health, compare it with the four fixed releases, and send your host the email with both CVE numbers. Until the host replies in writing, watch for the three signs, and ask whether the interim settings are in place as a holding step.

Once the fixed release is confirmed, you can go back to your week with a clear answer on file, and with a name next to the job of applying PHP updates. If your site is on PHP 8.1 or older, the same email sets up the upgrade, and a tested move to a supported branch is a one-time project. A site with no PHP server to patch is another option; our hand-built Next.js sites, part of our [web design](https://webleveling.com/services/web-design/) work, are built that way.

If your host cannot answer, or you would rather hand the upgrade to someone who tests and documents it, [Web Leveling](https://webleveling.com/) can handle it through our [website maintenance](https://webleveling.com/services/website-maintenance/) service. We work with small and medium businesses across the country and overseas. [Send us your PHP version and host details](https://webleveling.com/contact/) and we will tell you what the next step looks like.

## Terms

PHP update words in this post

Tap a term to see what it means.

**CVE.** A public identifier for a specific security flaw, such as CVE-2026-109618, used so hosts and developers talk about the same issue.

**PHP handler.** The part of the server that runs PHP for your site, such as PHP-FPM or Apache mod\_php.

**mod\_php.** A way of running PHP inside Apache; PHP rates it the highest risk for this update.

**Backport.** A fix copied back into an older PHP version by a vendor, which is not the same as upgrading to a supported version.

**Staging site.** A private copy of your site used to test changes before they go live.

**Web application firewall (WAF).** A filter in front of a site that can block known attack patterns while the update is being applied.

**PHP worker.** A process that handles website requests; the interim settings call for restarting every one.

- [Ghostscript Vulnerability and PDF Uploads: Check Today](https://webleveling.com/blog/ghostscript-flaw-pdf-uploads-wordpress/): A Ghostscript vulnerability can reach WordPress sites through PDF uploads. List your upload forms, ask your host one question and update WordPress today.
- [All in One SEO and Bricksforge flaws: what to update first](https://webleveling.com/blog/bricksforge-all-in-one-seo-wordpress-flaws/): Bricksforge needs 4.0.1 or newer and All in One SEO needs 5.0.2.1 or newer. Update Bricksforge first, then check users, files and redirects for damage.
- [Ninja Forms Vulnerability: Check Your Version and Update Today](https://webleveling.com/blog/ninja-forms-vulnerability-wordpress-contact-form/): Ninja Forms vulnerability: open Plugins, read your version, back up and update. See which version fixes each flaw, plus the File Uploads add-on.