Critical PHP vulnerabilities in 2026 and how to fix them on Debian Linux

Security analysis | November 5, 2026 | Debian 12, Debian 13, PHP-FPM and CloudPanel

The discovery of two critical vulnerabilities in the PHP runtime on October 21, 2026, exposed a security problem that cannot be solved by updating WordPress, Drupal, Joomla or an individual PHP application. The weaknesses reside inside PHP itself, in the handling of memory and internal request state. An attacker may be able to execute code remotely without authenticating to the application.

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, received critical CVSS 4.0 scores of 9.2. Both were added to CISA’s Known Exploited Vulnerabilities catalog on October 26, 2026. A further vulnerability, CVE-2026-115560, was disclosed separately and requires additional attention even on installations updated to the October security releases. Google Cloud Blog+3

The three vulnerabilities administrators need to understand

The PHP Security Team identifies the following first fixed upstream versions for the first two vulnerabilities. GitHub+2

PHP 8.1 and older releases are outside the PHP project’s security-support period. Linux vendors may provide backported fixes under separate support arrangements, but an unsupported upstream version should not be treated as safe merely because it still runs.

The central distinction is that updating to these four versions addresses the first two vulnerabilities, but does not by itself eliminate CVE-2026-115560. The October 23 PHP advisory recommends disabling session.upload_progress.enabled until the additional fix is available. 2026+1

Understanding CVE-2026-109618

CVE-2026-109618 is a memory corruption vulnerability in PHP’s handling of out-of-memory conditions. The problem involves PHP’s use of longjmp() to abandon an operation when memory allocation fails.

An allocation can fail while an internal data structure is only partially initialized. PHP may then enter its cleanup routine, which incorrectly assumes that the structure contains valid information.

The security problem is not simply that an attacker can exhaust a server’s memory. It is that the cleanup process can operate on invalid memory and potentially permit execution of attacker-controlled code.

The official advisory explains that the vulnerability can be triggered through multiple out-of-memory strategies. The attack surface includes PHP request processing, meaning application-level authentication is not necessarily an effective boundary. cve.org+2

The importance of the execution environment

The PHP project identifies Apache with mod_php as the highest-risk configuration because exploitation was demonstrated before application code runs.

PHP-FPM is also affected, but the demonstrated attack paths and prerequisites can differ. A server running Nginx and PHP-FPM must therefore be updated, even though its exposure is not identical to a server running Apache with mod_php.

The patched PHP versions also introduced memory_hard_limit_percent, changing how PHP handles memory limits. The normal memory_limit now operates as a soft limit for many allocations, while a separate hard limit controls how far memory usage may exceed it. Manual+1

This is particularly relevant to servers hosting multiple websites. Resource limits should remain part of capacity planning, but they must not be mistaken for the security patch.

Understanding CVE-2026-109619

CVE-2026-109619 involves a different memory-management defect: use-after-free involving PHP’s internal global state.

A PHP worker processes a request, retains references to internal data, and subsequently releases memory belonging to that request. Under certain circumstances, a reference survives when it should have been cleared.

A later request handled by the same worker may access the stale reference before the runtime completes its normal initialization.

The attacker needs a sequence of operations that first produces the stale reference and later causes PHP to consume it. The official advisory describes several relevant paths involving session management, error handling, configuration processing and abnormal termination.

A critical distinction follows: restarting PHP-FPM can clear existing worker state, but restarting an unpatched runtime is not a permanent fix. The vulnerability can be triggered again. GitHub+1

Likewise, suppressing PHP warnings using display_errors=Off, error_reporting or the @ operator does not repair the underlying defect.

The unresolved session upload-progress vulnerability

CVE-2026-115560 concerns an unusual interaction between PHP’s session serialization configuration and its upload-progress functionality.

According to the PHP Security Team, the vulnerable configuration requires all of the following conditions:

• The application configures session.serialize_handler as php_binary or php_serialize.
• Application code changes that handler to php at runtime, before calling session_start().
• session.upload_progress.enabled remains enabled.

Applications that never perform the runtime serialization-handler change are not exposed to this specific attack path.

The October 23, 2026, PHP announcement recommends:

session.upload_progress.enabled = 0

This is a temporary security mitigation for CVE-2026-115560, not a substitute for updating PHP against the two earlier critical CVEs. 2026+1

PHP’s upload-progress facility can write session information while processing an HTTP upload, before normal application code executes. That behavior explains why changing the configuration too late in request processing is unsuitable as a security control. Manual

Debian security updates and the exact fixed packages

Debian has issued security updates for its supported default PHP versions.

Debian 13 (Trixie)

Fixed package available

DSA-6574-1 · October 21, 2026

8.4.27-1~deb13u1

The Debian Security Team identifies this as the fixed package version for both critical CVEs. lists.debian.org

Debian 12 (Bookworm)

Fixed package available

DLA-4848-1 · October 21, 2026

8.2.35-1~deb12u1

Debian’s long-term security advisory identifies this version as fixing both vulnerabilities. lists.debian.org

These packages address CVE-2026-109618 and CVE-2026-109619. They must not be interpreted as confirmation that CVE-2026-115560 is fixed.

Debian preparation and PHP inventory

Before installing an update, identify the operating system, installed PHP packages, execution interfaces and package repositories.

All commands in the following examples assume an account with sudo privileges.

Step 1 — Identify the Debian release

cat /etc/os-release

Check the VERSION_CODENAME value. A normal Debian 13 installation reports trixie; Debian 12 reports bookworm.

Step 2 — List the installed PHP packages

dpkg-query -W \
  -f='${binary:Package}\t${Version}\n' \
  'php8.*' 2>/dev/null

This is more informative than running only:

php -v

The second command reports the PHP interpreter selected for the terminal. It does not establish which PHP version Nginx, Apache or a particular website actually uses.

A system may have PHP 8.2, 8.3, 8.4 and 8.5 installed simultaneously. Some versions may be used by active websites, while others may serve scheduled tasks or management software.

Step 3 — Identify running PHP-FPM services

systemctl list-units --type=service --all \
  | grep -E 'php.*fpm|apache2'

Inspect the running processes:

ps -eo pid,ppid,user,args \
  | grep -E '[p]hp-fpm|[a]pache2'

Also inspect the PHP-FPM configuration directories:

ls -la /etc/php/

find /etc/php -path '*/fpm/pool.d/*.conf' \
  -type f

This helps identify which PHP branches have FPM pools, but pool existence alone does not prove that a website uses them.

Step 4 — Identify the runtime used by Nginx

On a server running Nginx:

sudo nginx -T 2>/dev/null \
  | grep -nE 'fastcgi_pass|upstream'

The output can reveal the FastCGI Unix sockets or TCP listeners used by website configurations.

Compare those destinations against FPM pool settings:

sudo grep -RIn '^[[:space:]]*listen[[:space:]]*=' \
  /etc/php/*/fpm/pool.d/ 2>/dev/null

An Nginx configuration referencing a socket or listener must be matched to the actual FPM service, rather than assuming the website uses the CLI default.

Step 5 — Check Apache execution mode

On systems running Apache:

sudo apache2ctl -M \
  | grep -E 'php|proxy_fcgi'

The presence of a PHP module suggests mod_php; proxy_fcgi indicates the possibility of FastCGI integration.

Inspect the virtual-host configuration before deciding which runtime needs a restart.

Updating PHP on Debian 13

For a standard Debian 13 installation using the distribution’s PHP 8.4 packages, the correction is available from Debian’s security repositories.

Step 1 — Refresh package information

sudo apt update

Review the output for repository errors. Do not interpret a successful-looking update as proof that every configured repository was reached.

Step 2 — Inspect the available package versions

apt-cache policy php8.4-fpm php8.4-cli \
  php8.4-common php8.4-opcache

For packages from the official Debian 13 security repository, the relevant fixed version is:

8.4.27-1~deb13u1

If Candidate is older, check whether the security repository is enabled, whether package lists were updated and whether packages are pinned or held.

apt-mark showhold

Inspect configured repositories:

grep -RhE '^(URIs|Suites|deb )' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/ 2>/dev/null

Debian 13 security sources ordinarily use the trixie-security suite. Avoid copying repository configuration blindly from a different Debian release.

Step 3 — Back up the configuration

For an Nginx/PHP-FPM system:

sudo tar -czf \
  /root/php-nginx-config-$(date +%F-%H%M).tar.gz \
  /etc/php /etc/nginx

This archives configuration, not website content, databases or a complete server image. Make sure a recoverable application and database backup exists separately.

Step 4 — Simulate the update

sudo apt -s upgrade

Review the proposed changes and check that PHP packages are not being kept back.

Step 5 — Install the updates

sudo apt upgrade

Using the normal distribution update is appropriate for this security incident because the PHP source package provides multiple related binary packages and extensions.

Debian’s security FAQ recommends updating affected binary packages and restarting the relevant services where necessary. debian.org

Step 6 — Validate and restart PHP-FPM

First test the configuration:

sudo php-fpm8.4 -t

If the test succeeds, restart PHP-FPM:

sudo systemctl restart php8.4-fpm

Confirm the service is running:

sudo systemctl is-active php8.4-fpm

Inspect the latest logs:

sudo journalctl -u php8.4-fpm \
  -n 50 --no-pager

If Apache uses mod_php, restart Apache instead:

sudo apache2ctl configtest
sudo systemctl restart apache2

Restarting Nginx is not normally necessary merely because the PHP-FPM binary was updated, although configuration changes to Nginx require their own validation and reload.

Step 7 — Verify the installed version

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

php8.4 -v

A successful result should show the patched version or a later vendor-confirmed fixed version.

For an official Debian package, also confirm the Debian revision rather than relying only on the upstream PHP version string.

Updating PHP on Debian 12

Debian 12 uses PHP 8.2 as its default PHP branch.

The corresponding fixed security package is 8.2.35-1~deb12u1.

The update procedure follows the same principle, but the package and service names differ.

Step 1 — Refresh and inspect

sudo apt update

apt-cache policy php8.2-common \
  php8.2-cli php8.2-fpm

Check whether the candidate version includes the fixed Debian security package.

Step 2 — Install available security updates

sudo apt upgrade

Step 3 — Validate and restart

sudo php-fpm8.2 -t
sudo systemctl restart php8.2-fpm
sudo systemctl is-active php8.2-fpm

For Apache installations using mod_php, restart Apache.

Step 4 — Verify

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

php8.2 -v

An installation running the fixed PHP 8.2 release has addressed the two October 21 vulnerabilities, provided that the web-facing runtime actually uses those updated packages.

PHP 8.2 reaches upstream end of life on December 31, 2026. Administrators should plan a migration rather than treating this update as a reason to retain the branch indefinitely. lists.debian.org+1

PHP 8.3 and PHP 8.5 installed from additional repositories

Debian 13’s default PHP branch is 8.4. Servers using several PHP versions may obtain PHP 8.3 or PHP 8.5 from an additional package repository or hosting-panel package source.

Before running an upgrade, identify the origin:

apt-cache policy php8.3-fpm php8.5-fpm

Then review the proposed update:

sudo apt -s upgrade

For PHP 8.3, verify that the available build contains the corrections included upstream in version 8.3.36. For PHP 8.5, verify the corrections from 8.5.12.

After updating, test and restart each installed, active FPM service:

sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm

sudo php-fpm8.5 -t
sudo systemctl restart php8.5-fpm

Run these commands only for versions that are actually installed and whose configuration tests succeed.

If the packages come from a third-party repository, the official Debian security advisory does not automatically establish the status of those builds. Check the package maintainer’s changelog and the installed package revision.

Never change an APT repository, upgrade across PHP branches or remove an old PHP version merely to make the version number look current. The website, extensions, scheduled jobs and management software may still depend on that runtime.

Applying the temporary CVE-2026-115560 mitigation

This mitigation deserves its own deployment and verification procedure because it must affect the PHP runtime processing incoming requests.

Option A — PHP-FPM configuration for a particular PHP version

For PHP 8.4 on Debian 13, create an additional FPM configuration file:

echo 'session.upload_progress.enabled = 0' \
  | sudo tee \
  /etc/php/8.4/fpm/conf.d/99-security-upload-progress.ini

Validate and restart:

sudo php-fpm8.4 -t
sudo systemctl restart php8.4-fpm

This applies a default to that FPM configuration. An overriding pool or server setting may still change the effective value, so it must be checked.

Option B — Enforce the directive in an FPM pool

For stronger enforcement, edit the relevant PHP-FPM pool file under:

/etc/php/8.4/fpm/pool.d/

Inside the appropriate existing pool section, add:

php_admin_flag[session.upload_progress.enabled] = off

The PHP-FPM manual documents that php_admin_value and php_admin_flag cannot be overridden using ini_set(). This makes the pool-level administrative directive suitable when an application must not restore the setting. Manual

Check the configuration:

sudo php-fpm8.4 -t

Restart the service:

sudo systemctl restart php8.4-fpm

Repeat for every relevant PHP-FPM version and pool. On hosting systems, verify whether the management panel regenerates the pool configuration during later changes.

The temporary control may disable an upload-progress indicator in applications that depend on PHP’s built-in session upload tracking. It does not inherently prohibit ordinary file uploads.

Inspecting potentially relevant session configuration

Search for session serialization settings:

sudo grep -RInE \
  'session\.serialize_handler|session\.upload_progress\.enabled' \
  /etc/php/ 2>/dev/null

Application code may also change settings using ini_set(). Check the deployed application’s code and dependencies where appropriate.

A configuration search cannot prove the absence of vulnerable behavior in all dynamically executed code, but it is a useful first investigation.

Why some emergency workarounds are dangerous

The PHP Security Team listed temporary measures for the October critical vulnerabilities, including changing the memory limit or restricting POST body sizes.

For CVE-2026-109618, setting:

memory_limit = -1

can remove one PHP-controlled allocation-failure path. But this is not a complete security fix, and disabling the PHP memory limit may increase the risk of resource exhaustion on a shared server.

An administrator should not apply it to a production server without understanding the available physical memory, FPM concurrency, process limits and application behavior.

A configured pm.max_children value limits the number of simultaneous PHP-FPM child processes in a pool; it is not a security boundary against these runtime vulnerabilities. 2026+1

The advisory also discusses reducing post_max_size and enforcing request size limits at the web server or reverse proxy. Such measures may reduce exposure but can disrupt legitimate upload workflows.

For Nginx, client_max_body_size provides one request-size control. It does not replace a PHP patch or address every request-parsing condition. nginx.org

Use mitigations as temporary controls while deploying the corrected runtime, not as evidence that an unpatched PHP installation is secure.

CloudPanel requires an additional runtime check

CloudPanel installations require particular care because the PHP runtime serving a website may differ from the runtime used by the management interface.

CloudPanel’s documentation supports per-site PHP selection and separate PHP-FPM pools. Public issue reports also describe installations where CloudPanel’s own clp-php-fpm service ran a different PHP version, including an older PHP 8.1 runtime. Those reports do not prove that every installation has the same configuration. Documentation+2

For a CloudPanel server, inspect both the hosted-site services and the management service.

systemctl status clp-php-fpm --no-pager

systemctl cat clp-php-fpm

To inspect the executable associated with the running master process:

pid=$(systemctl show -p MainPID --value clp-php-fpm)

if [ "$pid" -gt 0 ]; then
    sudo readlink -f "/proc/$pid/exe"
fi

Also check the installed CloudPanel version and package dependencies before making changes.

Do not blindly replace the PHP executable used by clp-php-fpm, edit a vendor systemd unit or remove PHP 8.1. Management-panel dependencies may require specific extensions or configuration, and an unsupported modification can break administrative access.

The correct sequence is to identify the active runtime, establish whether the vendor supplies a supported fix, validate the alternative in a test environment if necessary, and confirm the management login and database functions after any approved change.

Verifying that the server is actually repaired

A completed APT transaction is only one part of verification.

A sound post-update audit establishes four separate facts: the required package is installed, the correct service is using it, the relevant mitigation is active, and the application remains operational.

Package and process verification

Inspect package versions:

dpkg-query -W -f='${binary:Package} ${Version}\n' \
  'php8.*' 2>/dev/null

Check running FPM services:

systemctl list-units --type=service --state=running \
  | grep -E 'php.*fpm'

Check the corresponding service logs:

sudo journalctl -u php8.4-fpm \
  --since "30 minutes ago" --no-pager

Configuration verification

For an FPM installation, inspect the effective pool configuration, including the chosen administrative upload-progress setting.

The FPM configuration test and dump option can assist:

sudo php-fpm8.4 -tt 2>&1 \
  | grep -i 'session.upload_progress.enabled'

A result needs to be interpreted in the context of the specific pool and any web-server-provided settings. Absence from a configuration dump is not proof that the desired value is active.

CLI php -i reads the CLI configuration, which can differ from FPM. Avoid publicly exposing a phpinfo() diagnostic page merely to perform the audit.

Application verification

Test real application functions after the restart: ordinary pages, authenticated areas, forms, administrative logins, scheduled tasks and file uploads where applicable.

An HTTP 200 response proves that an endpoint answered successfully. It does not prove that the underlying PHP runtime was patched.

Detecting possible exploitation attempts

The vulnerabilities have been treated as exploited in the wild by CISA, although different security teams have reported differing degrees of observed exploitation success. Wiz reported limited attempts in its October 27 telemetry and cautioned that it had not identified a publicly available, generally reliable end-to-end exploit against arbitrary targets at that point. Canadian Centre for Cyber Security+1

Investigators should avoid equating an attempted exploit with a confirmed compromise, or the absence of a logged crash with proof of safety.

PHP-FPM logs

For Debian 13 and PHP 8.4:

sudo journalctl -u php8.4-fpm \
  --since "2026-10-20" --no-pager \
  | grep -Ei \
  'segfault|signal|child.*exit|memory exhausted'

Inspect available PHP-FPM error logs as well, including rotated logs.

Apache logs

On an Apache installation, look for abnormal process termination and segmentation faults:

sudo zgrep -Ei \
  'segmentation fault|child.*exit signal|segfault' \
  /var/log/apache2/error.log*

The Berkeley Lab security guidance specifically identified segmentation-faulting Apache workers as an indicator worth investigating. Such messages are not independently conclusive evidence of successful exploitation. Berkeley Lab Commons

File changes and unexpected processes

On a server where website content resides under /var/www, an initial file-modification inventory might use:

sudo find /var/www -type f -name '*.php' \
  -newermt '2026-10-20' \
  -printf '%TY-%Tm-%Td %TH:%TM %p\n'

The output includes legitimate modifications from updates and deployments. Compare unexpected changes with version control, known release artifacts and trusted backups.

Inspect running processes and network connections:

ps auxf

sudo ss -tulpen

Suspicious evidence warrants a proper incident response: preserve logs, isolate affected services where necessary, investigate persistence and unauthorized changes, and rotate potentially exposed secrets. Reinstalling a patched PHP package alone does not establish that an already compromised system is clean.

Keeping Debian protected after the emergency update

A PHP security update should be handled as a recurring operational process rather than a one-time terminal command.

For Debian servers, maintain a current inventory of active PHP branches, package origins, running FPM services and responsible applications. Configure supported automated security updates where appropriate, while retaining monitored maintenance procedures for services that require restarts or compatibility checks.

Review the Debian Security Tracker and PHP’s security announcements as separate sources. A PHP upstream release may be fixed before a particular vendor build becomes available; conversely, a distribution may backport a fix without adopting the newest upstream version number.

The next response to a high-impact PHP vulnerability should not require discovering from scratch which websites use which runtime. That information should already exist in an operating inventory.

A practical recurring check should report only meaningful changes: a newly published vulnerability affecting deployed versions, the availability of a fixed package, a failed update, an unpatched running service or a security mitigation that is no longer active.

Technical questions administrators frequently ask

Does updating WordPress fix CVE-2026-109618? No. The vulnerability is in the PHP interpreter, not WordPress.

Does Nginx protect PHP-FPM from these flaws? No. PHP-FPM is among the affected execution environments, although demonstrated exploit paths differ.

Is PHP 8.4.27 safe against both October critical CVEs? It contains the upstream corrections for CVE-2026-109618 and CVE-2026-109619.

Does PHP 8.4.27 also fix CVE-2026-115560? No. The October PHP advisory explicitly separates that issue.

Must upload progress be disabled permanently? The PHP team describes the setting as a temporary mitigation until the relevant correction is released.

Can I update PHP without restarting PHP-FPM? The installed package may be updated, but existing processes must be replaced to ensure they are using the corrected executable.

Is php -v enough to verify a website? No. It reports the selected CLI interpreter.

Does restarting FPM remove a use-after-free vulnerability? No. It clears processes but leaves vulnerable code in place if the binary is unpatched.

Does setting display_errors=Off prevent exploitation? No. Suppressing the visibility of errors does not correct the internal memory-state flaw.

Does a firewall eliminate these vulnerabilities? Not for publicly accessible PHP endpoints that an attacker is still permitted to reach.

Does a WAF replace updating PHP? No. Request filtering may reduce exposure but cannot be relied upon as a complete correction.

Can I keep PHP 8.1 if a hosting panel needs it? Its upstream support has ended. Check the vendor’s actual support arrangements and migration path rather than assuming it is patched.

Should I disable all file uploads? Not automatically. Assess application requirements and apply the documented targeted controls.

Can I use the same commands for PHP 8.2 and PHP 8.5? The APT process is similar, but package origins, configuration directories and service names differ.

Does an HTTP 200 response establish security? No. Application availability and runtime patch status are different checks.

Can Debian install newer packages while keeping old ones? Multiple PHP branches can coexist; the old runtime may remain installed or active until separately addressed.

Is a PHP-FPM pool a complete isolation boundary? No. The PHP manual explicitly warns that pools do not provide full security isolation.

Should I remove every PHP version that is not currently active? Only after checking package dependencies, website configuration, scripts and hosting-panel requirements.

Which issue should be prioritized first? Any deployed web-facing runtime missing the October corrections needs urgent patching. The session upload-progress mitigation must also be evaluated separately.

Primary technical references

The following official references provide the basis for the remediation procedures and vulnerability descriptions:PHP Security Team — October 2026 security announcementsPHP advisory — RCE via OOM corruptionPHP advisory — RCE via stale global stateDebian Security Advisory DSA-6574-1Debian LTS Advisory DLA-4848-1Debian Security Tracker — CVE-2026-109618Debian Security Tracker — CVE-2026-109619PHP manual — PHP-FPM configurationPHP manual — Core configuration and memory limitsCloudPanel — PHP and site settings

Operational priority: Patch every active PHP runtime, verify that the running services use the corrected binaries, and separately enforce the session upload-progress mitigation wherever the unresolved exposure requires it. A successful package update without runtime verification is not a completed security remediation.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.