PHP Security Updates: October 2026

Short answer: if your site runs PHP 8.2, 8.3, 8.4 or 8.5, update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (released October 22, 2026) as soon as your host allows it, and if you skipped the September round, grab those fixes too.

This post is for website owners, developers and anyone who manages hosting for a WordPress site, Shopify app, or custom PHP application. You'll get a plain-English rundown of what changed in the October 22 and September 24, 2026 PHP releases, who actually needs to act, and exactly how to check which version your server is running right now.

What happened on October 22, 2026

PHP's maintainers shipped four new point releases on October 22, 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All four share the same fix, listed under two advisory IDs, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, described in the official changelog as "avoid state corruption via bailout." No CVE (Common Vulnerabilities and Exposures) number is attached to either advisory yet.

A "bailout" in PHP is the internal mechanism the engine uses to unwind execution cleanly when something goes wrong, like a fatal error or a timeout. If that unwinding leaves internal data structures in an inconsistent state, it can cause crashes or, in some setups, more serious memory corruption. This is the kind of low-level engine fix most site owners will never notice directly, but it's still worth applying because it closes a real defect in core PHP, not a feature plugin or theme.

You can read the exact entries for each branch on the official PHP changelog.

The bigger round from September 24, 2026

The October release is small. The one before it, on September 24, 2026, was much larger and is the one most sites actually need to worry about. That update shipped PHP 8.5.11, 8.4.26, 8.3.35 and 8.2.34, fixing twelve separate security issues. Here's what each one does, straight from the changelog:

Several of these matter for ordinary small-business sites, not just enterprise setups. If your app fetches remote URLs (image imports, webhooks, link previews) using PHP's stream wrapper, the redirect-related bugs (cross-origin credential leak and the empty-Location out-of-bounds read) are directly relevant. If you accept uploaded archives (themes, plugins, import files), the Phar/TAR integer overflow is worth knowing about. If your site connects to a MySQL database through mysqlnd, as most WordPress and many custom PHP apps do, the packet overread fix applies to you too.

An unpatched version is a reason to update, not proof your site has already been exploited. Several of these flaws need a specific function, extension or server configuration to be reachable, so the risk varies by site. If you're worried your site might already be compromised, our guide on signs your website has been hacked walks through what to check. Still, there's no good reason to stay on a version with a known, named fix once it's available.

Who actually needs to update

As of October 24, 2026, PHP's own supported versions page lists these end dates for security fixes: PHP 8.2 until December 31, 2026, PHP 8.3 until December 31, 2027, PHP 8.4 until December 31, 2028, and PHP 8.5 until December 31, 2029. If you're on 8.2, that branch has a bit over two months of security coverage left as of this writing, which makes this a reasonable point to plan an upgrade to 8.3 or newer anyway.

How to check your PHP version

You don't need to be a developer to do this. Pick whichever applies to you:

1. Command line (CLI): run php -v on the server. This shows the CLI version, which can differ from the version your web server actually uses to run your site, so don't stop here if you have web server access too.
2. phpinfo(): create a temporary file containing <?php phpinfo(); on your server, load it in a browser, check the version at the top, then delete the file immediately (it reveals configuration details you don't want exposed on a live site).
3. WordPress: go to Tools > Site Health > Info > Server, and look for "PHP version."
4. Hosting control panel: most cPanel, Plesk, or custom host dashboards have a "PHP version" or "PHP settings" section, often under "Software" or "MultiPHP Manager."

If any of these show 8.2.35, 8.3.36, 8.4.27 or 8.5.12, you're current on the October 22 release. If you're on 8.2.34, 8.3.35, 8.4.26 or 8.5.11, you already have the September fixes and only need the small October bailout patch. Anything older than that on a still-supported branch is also missing the September round, and possibly more.

The Linux distribution backport caveat

Here's a wrinkle that trips up a lot of self-managed server owners: Linux distributions like Ubuntu, Debian and Red Hat often patch security issues into their PHP packages without bumping the version number that php -v reports. They do this to keep software stable, backporting just the fix rather than shipping a whole new PHP release.

That means a version number that looks outdated, say an Ubuntu package still reporting "8.2.24," might already contain the September or October fixes. The only reliable way to know is to check your distribution's own package changelog (on Debian and Ubuntu, apt changelog php8.2 or similar, depending on your package name), not just compare the number against what's listed on php.net.

If you're not sure how to interpret your package's changelog, that's a reasonable thing to hand to whoever manages your hosting, or to check against during a manual security review rather than guessing.

A quick checklist

• [ ] Confirm your PHP version with php -v, phpinfo(), Site Health, or your hosting panel
• [ ] Compare it against 8.2.35, 8.3.36, 8.4.27 or 8.5.12
• [ ] If you're on a Linux distro package, check the distro's changelog before assuming you're behind
• [ ] If you're on PHP 8.1 or older, plan a branch upgrade, since 8.1 is no longer supported
• [ ] If your host manages PHP updates, ask them directly whether the October 22 release has been applied
• [ ] If you handle uploads, remote URL fetching, or database connections, treat this round as higher priority

If you'd rather have someone confirm all this for you instead of digging through changelogs, our free passive website security check gives you a quick yes/no read without needing a login or card.

Key takeaways

• PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (released October 22, 2026) fix one shared engine issue; the September 24, 2026 round before it fixed twelve separate, more impactful bugs.
• Check your running version with php -v, a temporary phpinfo() file, WordPress Site Health, or your hosting control panel, since the CLI and web server versions can differ.
• A version number that looks old on a Linux distro package may already be patched: check the distro's own changelog before assuming you're exposed.
• PHP 8.1 is no longer listed as supported; PHP 8.2's security window closes December 31, 2026, so plan ahead if you're on it.
• An outdated version is a reason to patch, not proof you've been compromised, but there's no upside to staying behind once a fix exists.

Patch notes only tell you what was fixed in PHP itself. They won't tell you whether your specific site, plugins, or server configuration have their own separate problems. If you want a person to actually look at your site rather than just compare version numbers, Circuit is a one-time, $49 manual audit where a real security engineer checks your whole site and hands you a written report with exact fixes, not just a changelog diff.