PHP CVE-2026-109618 & CVE-2026-109619

Reporting an Issue
1

Hi,

any news and suggestions on this topic?
PHP2Shell CVE-2026-109618 & CVE-2026-109619

Thanks!

2

Hello,

The update is now available. You can run the following commands to upgrade PHP to the latest version:

sudo apt update

dpkg -l | awk '$1 == "ii" && $2 ~ /^php8[.]2/ {print $2}' | xargs -r sudo apt install -y --only-upgrade --no-remove

Once the update is complete, verify the installed PHP version:

php -v

Please let me know if the update was successful or if you encounter any issues.,

Best regards,

3

Here are all the instructions:

4

what about debian 11 and centos ? is it only debian 12 issue?

5

We don’t provide support for CentOS. About Debian 11, there are mitigation settings, but we won’t provide a patch for that PHP version.

6

but, there are some sites on vitalpbx 3, vitalpbx 4.2. before 4.5…any hints for that sites?

7

You can do this to mitigate this security issue on your Debian 11 servers.

cat >/etc/php/8.1/fpm/conf.d/99-cve-mitigation.ini <<'EOF'
session.upload_progress.enabled = 0
memory_limit = -1
EOF

systemctl restart php8.1-fpm
  • Set memory_limit = -1 at the server/FPM level so applications cannot override it. This specifically mitigates the controllable out-of-memory path in CVE-2026-109618. PHP notes that it does not eliminate every possible allocation-failure path.
  • Disable PHP session upload progress with session.upload_progress.enabled = 0, then restart all PHP workers. This mitigates the confirmed session-related exploitation path for CVE-2026-109619. PHP explicitly says not to rely on ini_set() because request parsing occurs before application code.

Additionally, follow these instructions to safely limit total PHP memory usage on your server without constraining individual web requests.

mkdir -p /etc/systemd/system/php8.1-fpm.service.d

cat >/etc/systemd/system/php8.1-fpm.service.d/memory-cap.conf <<'EOF'
[Service]
MemoryAccounting=yes
MemoryMax=2G
OOMPolicy=continue
Restart=on-failure
RestartSec=5s
EOF

Sizing Tip: 2G is an example. Adjust MemoryMax to match your server’s capacity and peak traffic patterns (e.g., 4G, 8G), ensuring adequate RAM remains for MySQL/MariaDB, Apache, and system processes.

Reload the systemd daemon, test the PHP-FPM configuration for syntax errors, and restart the service:

systemctl daemon-reload
php-fpm8.1 -t && systemctl restart php8.1-fpm

Confirm that the operating system has applied the memory ceiling to the service:

systemctl show php8.1-fpm -p MemoryMax

The output should confirm MemoryMax=2147483648 (2 GB in bytes) or your chosen value.

Why this?

Setting memory_limit = -1 neutralizes the vulnerability by disabling PHP’s internal, exploitable out-of-memory bailout routines, but removing that internal safety rail leaves the host vulnerable to resource exhaustion; applying the 2 GB systemd cap acts as the replacement safeguard, moving enforcement to the operating system level so that all PHP worker processes combined cannot exceed a safe memory threshold and crash the entire server.

The PHP team considers these mitigations, not a full fix.