Critical PHP Security Update: How to Check and Patch Your Server

PHP administrators should check their servers now. On October 21, 2026, the PHP team released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities rated CVSS v4.0 9.2 that can enable remote code execution without authentication. The first fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Distribution packages may use different version numbers when they backport the fixes. Source: PHP security announcement.

This guide explains how to identify the PHP runtime behind your website, verify patch availability, update an Ubuntu or Debian PHP-FPM installation, and check the result. Commands are administrative examples; adapt the branch and service names to your server.

Which PHP installations need attention?

PHP's announcement covers installations handling web requests, including PHP-FPM, Apache mod_php, CGI, FrankenPHP, and LiteSpeed. Exploit conditions vary by runtime and configuration. A working unauthenticated exploit was demonstrated for mod_php; this does not establish that every deployment is exploitable in the same way.

A PHP application can be affected even when its own code has not changed. Updating a CMS, Laravel dependency, or plugin does not update the PHP runtime underneath it.

What do the two vulnerabilities do?

CVE-2026-109618: out-of-memory corruption

PHP can abandon an operation when memory allocation fails, leaving request data incompletely initialized. Cleanup may then use that invalid data. The official advisory explains how this can lead to code execution and why exposure differs between web runtimes. Read the PHP OOM advisory.

CVE-2026-109619: stale state between requests

A persistent worker may retain references to memory belonging to an earlier request after that memory has been released. A subsequent request can encounter those stale references. Certain session, configuration, and error-handling paths create opportunities for exploitation. Read the PHP stale-state advisory.

Step 1: identify every PHP version serving websites

Start with an inventory. These commands inspect installed packages and running services; they do not install updates:

hostname
cat /etc/os-release
php -v
php --ini

dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Abbrev}\n' \
  'php[0-9]*' 'libapache2-mod-php*' 2>/dev/null

systemctl list-units --type=service --all --no-pager 'php*-fpm.service'

The output of php -v describes the command-line interpreter. It does not prove that your website uses that interpreter. One VPS may have PHP 8.2 as its CLI default while individual domains use PHP 7.4 or 8.3 through different FPM pools.

Map each domain to its actual FPM socket, Apache module, container image, or hosting-panel backend. In HestiaCP, inspect the domain's backend template and confirm it against the generated web-server configuration. Repeat this for subdomains, staging sites, and secondary servers that remain publicly reachable.

For an ambiguous deployment, use a temporary access-controlled diagnostic endpoint that returns only PHP_VERSION and PHP_SAPI. Remove it after checking. Publishing a full phpinfo() page unnecessarily exposes configuration details.

Step 2: check whether your package vendor has shipped the fixes

On Ubuntu or Debian, refresh package metadata, then inspect the installed and candidate versions. This example checks PHP 8.2:

if sudo apt-get update; then
  apt-cache policy php8.2-common php8.2-fpm php8.2-cli
else
  echo "Package metadata refresh failed. Resolve repository errors before updating."
fi

Compare the full package revision with your repository vendor's security notice for both CVEs. A lower upstream version can contain a backported fix; an update candidate can also be unpatched. Neither the presence of an update nor the date of its build is sufficient evidence.

Check local release notes as an additional clue:

apt changelog php8.2-common

If the changelog is unavailable or does not mention the issue, consult the vendor advisory or ask the hosting provider for the exact fixed package revision. Keep a record of that confirmation.

Step 3: update the existing PHP branch

Before installation, confirm a recent restorable backup or snapshot, save the PHP and web-server configuration, and allow for a brief service interruption. Updating PHP 8.2 within its branch is a different operation from migrating an application from PHP 7.4 to PHP 8.x.

The following Bash example targets an existing, versioned PHP 8.2 FPM installation. It collects that branch's installed packages, including extensions, and previews their upgrade. Change PHP_BRANCH only after completing the domain inventory.

PHP_BRANCH="8.2"

mapfile -t PHP_PACKAGES < <(
  dpkg-query -W -f='${binary:Package} ${db:Status-Abbrev}\n' 2>/dev/null |
  awk -v prefix="php${PHP_BRANCH}-" \
    'index($1, prefix) == 1 && $2 == "ii" {print $1}'
)

if [ "${#PHP_PACKAGES[@]}" -gt 0 ]; then
  printf '%s\n' "${PHP_PACKAGES[@]}"
  sudo apt-get -s install --only-upgrade "${PHP_PACKAGES[@]}"
else
  echo "No matching installed packages found. Check the PHP package naming scheme."
fi

Review the simulation. Stop if it proposes unexpected removals, repository changes, or a branch migration. Once you have verified that the candidate packages contain both fixes, run this in the same Bash session:

if [ "${#PHP_PACKAGES[@]}" -gt 0 ]; then
  sudo apt-get install --only-upgrade "${PHP_PACKAGES[@]}"
else
  echo "Run the package-selection block first."
fi

Keep the normal confirmation prompt and review any configuration-file questions. Package installation scripts may restart services automatically. If installation reports errors, resolve them before continuing.

This example does not select Apache's libapache2-mod-php packages or custom vendor package names. For mod_php, LiteSpeed, or a panel-managed custom PHP build, use that vendor's update procedure and restart the service that actually hosts PHP.

Step 4: validate configuration and replace running workers

A new package on disk is insufficient if old PHP workers are still serving traffic. For an Ubuntu-style PHP 8.2 FPM service, validate its configuration and restart it:

if sudo /usr/sbin/php-fpm8.2 -t; then
  if sudo systemctl restart php8.2-fpm; then
    systemctl is-active php8.2-fpm
  else
    echo "Restart failed. Inspect service status and logs immediately."
  fi
else
  echo "FPM configuration validation failed. Resolve it before restarting."
fi

Repeat for every affected FPM version. For mod_php, validate Apache configuration and restart Apache after the module update. Container deployments need a patched image rebuilt or pulled and the running containers recreated; updating the host's CLI package does not update an image.

Step 5: confirm the patch and test the application

Recheck package revisions and the PHP runtime through the website's actual execution path. For backported packages, retain the vendor's fixed-revision evidence alongside your installed revision.

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
  php8.2-common php8.2-fpm php8.2-cli

systemctl status php8.2-fpm --no-pager
sudo journalctl -u php8.2-fpm --since "15 minutes ago" --no-pager

Test the homepage, authentication, an administrative page, a database-backed page, and any important upload or checkout flow. A successful homepage response alone does not verify the application.

If a problem appears, preserve the error output and investigate configuration or extension differences. Restoring an unpatched runtime restores the exposure too; restrict public access while resolving a rollback.

What if you still run PHP 7.4, 8.0, or 8.1?

PHP provided minimal source backports for these three legacy branches, despite their end-of-life status. Those source patches are not automatically installed binary packages and do not restore ordinary upstream support. Obtain explicit confirmation from your distribution or LTS vendor that its package fixes both CVEs. Otherwise, arrange a maintained patched build or migrate to a supported branch.

For a legacy booking system, forum, or custom CMS, test a branch migration on a copy with matching extensions and configuration. Check authentication, scheduled jobs, database access, and core business flows before switching production traffic. Do not assume that changing a hosting-panel dropdown establishes compatibility.

Temporary measures when patching is delayed

Configuration changes reduce specific attack paths; they do not establish that a server is safe. PHP recommends disabling session upload progress before request parsing and replacing all workers:

session.upload_progress.enabled = 0

Apply this through the web runtime's php.ini or appropriate server/pool configuration. Application-level ini_set() and FPM .user.ini are too late for this mitigation. PHP 8.5 also has a mitigation involving fatal_error_backtraces=0. Configuration warnings and reachable fatal errors require attention as described in the stale-state advisory.

The OOM advisory describes administratively enforcing memory_limit=-1, reducing request limits, and using carefully designed cgroup or container boundaries. Removing PHP's memory limit can threaten server availability, especially on a shared VPS. Treat these as a coordinated administrator-managed configuration, rather than copying one setting in isolation. OS address-space or data limits are specifically unsuitable substitutes.

If exposure cannot be adequately reduced while awaiting a patch, temporarily restrict access to the affected service at the proxy or network layer.

Does a WAF replace the PHP update?

No. A WAF filters requests; it does not replace vulnerable PHP binaries. Check your provider's current guidance and rule coverage, and remember that a publicly reachable origin may bypass a proxy. Keep patch verification as a separate task even when a protection dashboard reports that mitigations are active.

Frequently asked questions

Is PHP-FPM automatically safe?

No. PHP includes FPM in its warning. Runtime-specific exploit conditions differ, but administrators should update affected installations rather than infer safety from the handler name.

Can a browser tool tell me whether my server is patched?

A public header or browser report cannot reliably identify the installed server package or its backports. Rubic8's What Is My IP identifies your connection's public IP, which is a different task. Patch confirmation needs server or hosting-provider evidence.

Does patching prove the server was never compromised?

No. Patching addresses the vulnerability. If you find unexpected PHP files, unfamiliar scheduled jobs, or suspicious account activity, preserve relevant logs and investigate separately. An absence of obvious errors is not proof that no intrusion occurred.

Before you close the maintenance task

• Every public domain and subdomain is mapped to its real PHP runtime.
• Every affected runtime has a fixed release or a documented vendor backport for both CVEs.
• Old workers or containers have been replaced.
• Critical application flows and service logs have been checked.
• Any temporary diagnostics have been removed and legacy migrations have an owner.

Editorial note: Reviewed October 22, 2026. Vendor packages and advisories can change; verify the current fixed package revision when performing maintenance. The command examples are a deployment workflow, not a vulnerability scanner.

Official references

• PHP: October 2026 security announcements
• PHP advisory: CVE-2026-109618
• PHP advisory: CVE-2026-109619