New PHP security fixes — the no-DevOps guide to updating your site

PHP shipped another round of security releases this autumn. The headline fixes include a high-severity flaw in the SOAP extension (CVE-2026-91765), a SQL-injection class bug in the PostgreSQL extension (CVE-2026-17543), plus patches in OpenSSL certificate verification, the HTTP stream wrapper and PHP-FPM. Every actively supported branch received an update, so the question for anyone running a PHP site is not whether to update but how fast.

First, in ten seconds: what version is your site on?

You cannot plan an update without knowing where you start. Pick whichever is easiest:

• Browser (works for most sites). Many frameworks and themes expose the PHP version in response headers. Open your site, press F12, go to the Network tab, reload, click any request, look under Headers → Response for an X-Powered-By: PHP/8.x.y line. If it is there, you have your answer in one glance.
• Shell on a VPS. php -v prints the full version on the first line. On managed hosting there is usually a PHP info button in the control panel that does the same thing without a terminal.
• Last resort. Drop a one-liner info.php with <?php phpinfo(); into your site's web root, open it in a browser, read the version at the top, and delete it immediately — leaving phpinfo reachable in production leaks server internals that attackers specifically grep for.

Now compare against the list below.

Which versions are still safe to run

As of October 2026, only four PHP branches are still receiving fixes:

• PHP 8.5 — current, full support.
• PHP 8.4 — active support until 31 December 2026, security fixes until the end of 2028. The latest patch is 8.4.26.
• PHP 8.3 — security-only, patches until the end of 2027. The latest patch is 8.3.35.
• PHP 8.2 — security-only, and this branch reaches end-of-life on 31 December 2026 — about two months from now.

Anything older (8.1, 8.0, the whole PHP 7 line) has been unsupported for a while. If your site is on PHP 8.1 or earlier, no amount of patching will help — the upstream project is not writing fixes for it anymore, and every new CVE in those versions is a free attack surface.

The update, if nobody on your team speaks server

Pick the row that matches how your site is hosted. In every case the fix is the same conceptually — switch the PHP version your site runs on to the latest patch of whichever branch you are already on (so 8.3.x → 8.3.35, 8.4.x → 8.4.26, and so on). You almost never need to jump a major version at the same time.

Shared hosting with cPanel, Plesk, DirectAdmin or ISPmanager

Most low-cost hosts (Hostinger, SiteGround, Bluehost, Namecheap, Beget, Timeweb, and nearly every regional reseller) run one of these control panels. The update is a UI click.

1. Log in to the hosting control panel. 2. Find "Select PHP Version" (cPanel), "PHP Settings" (Plesk), or "PHP Selector" (DirectAdmin / ISPmanager). 3. Switch to the latest patch of your current branch — if you were on 8.3, pick the newest 8.3.x; if you were on 8.4, pick the newest 8.4.x. 4. Save, then open your site in a private browser window and click through the main pages. If anything looks broken, switch back to the previous version from the same screen — this is reversible in one click.

If your host only offers major versions ("PHP 8.3", "PHP 8.4") without patch numbers, that is fine. Shared hosts auto-apply the latest patch inside each branch. Simply picking the highest supported major you can is the whole update.

WordPress on managed hosting (WP Engine, Kinsta, Pressable, Pantheon, Cloudways)

Managed WordPress hosts handle the PHP update for you, but you still have to select which version your site uses.

1. Open your host's dashboard. 2. Find the site, then look for an "Environment", "PHP version" or "Tools" panel. 3. Move the slider or dropdown to PHP 8.3 or 8.4. Avoid staying on 8.2 past December 2026. 4. Managed hosts usually have a staging environment button right next to it — flip staging first, test, then promote.

If you installed WordPress yourself on a shared host, follow the cPanel path above instead.

Docker-based deployments

If your site is a Dockerfile with a FROM php:... line, the update is a one-character change.

1. Open the Dockerfile. 2. Change the base image tag to the latest patch of your branch — for example php:8.4.26-fpm or php:8.3.35-apache. 3. Rebuild and redeploy the image. Most CI/CD pipelines will handle this on the next push. 4. If you pin only the major version (php:8.4-fpm), you already pull the latest patch on every rebuild — just redeploy.

A VPS where you run PHP from the OS packages

On Ubuntu or Debian servers using Ondřej Surý's PPA (which is the overwhelmingly common setup):

sudo apt update
sudo apt upgrade php8.3 php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

Replace 8.3 with whichever branch you are on. On RHEL / AlmaLinux / Rocky with Remi's repository, use dnf update php and restart php-fpm.

If you have no idea what hosts your site

Email the person or company who built it. The message is literally two lines: "Our site runs on PHP. Please update it to the latest patch of PHP 8.3 or 8.4 and confirm when it's done." That is a 10-minute job for anyone who deploys the site.

If you cannot update today — what to do in the meantime

Sometimes the update has to wait: your developer is unavailable, the host is in a maintenance window, or you are blocked on a plugin that still crashes on the newer PHP. The attack window does not care, so narrow it:

• Put the site behind a WAF for the week. Cloudflare's free plan is a one-click DNS switch and will block the most generic probe traffic by default. It is not a replacement for patching, but it blunts commodity scanners while you organise the update.
• Disable the extension you cannot patch. Both of this month's high-severity bugs are in optional extensions. If your application does not call SOAP, comment out extension=soap in php.ini. If you do not talk to Postgres, remove extension=pgsql and extension=pdo_pgsql. Fewer loaded extensions, fewer attack surfaces — and php -m will confirm what is actually loaded.
• Rotate secrets that could leak through an unpatched runtime. API keys stored in environment variables, database passwords in .env, SMTP credentials — any of those is cheap to rotate and expensive to lose. Rotation does not fix the bug, but it caps the blast radius if someone already got in.

These are stopgaps, not fixes. Schedule the actual update as soon as the blocker clears.

Three things to check after you update

The update takes minutes. The next step takes about the same time and catches most regressions.

• Open your homepage and the login page in a private window. A broken PHP update normally produces a blank white page or a visible error on the first request.
• Check your error log. On cPanel/Plesk it's a one-click tab; on a VPS it is typically /var/log/php*-fpm.log or your web server's error log. Fresh errors right after the update point to a deprecated function or an extension that didn't come across.
• Confirm the version actually changed. Reuse the ten-second check from the top of this post — reload the site, look at X-Powered-By in the response headers, and confirm the number moved. On a VPS, php -v is faster.

What this has to do with us

The whole reason bugs like these have an attack value is that the gap between patch released and patch deployed on your site is usually measured in months, not days. That window is exactly what an attacker enumerates against. Sintropyc's Proof scan and Continuous audits treat an unpatched runtime as a finding with proof attached — a working exploit, not a scanner tag — and re-test once you ship the fix.

If you want the window closed and verified rather than just announced, that is what a Proof scan is for.