Critical PHP vulnerability fix

On 2026-10-21 the PHP project disclosed two critical vulnerabilities: with no login and no account of any kind, an attacker can run arbitrary code on your server. Every PHP installation that serves web pages is affected. Please deal with this as soon as you can.

• Official announcement: https://www.php.net/archive/2026.php#2026-10-21-5
• CVE IDs: CVE-2026-109618, CVE-2026-109619 (CVSS 9.2)
• One-command fix tool: https://github.com/lizhipay/php

Am I affected?

If your store runs on PHP, yes — whether you use aaPanel, a PHP you compiled yourself, or Docker.

The fixed versions are 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 and later. 8.1 and older are no longer maintained by the PHP project and will not get a fixed release, but the one-command script below can still fix them.

Check your version:

php -v

If aaPanel has several PHP versions installed, check each one separately, for example /www/server/php/82/bin/php -v.

Pick your setup

How you installed	How to fix it
aaPanel, or PHP you compiled yourself	One-command fix script
PHP from system packages (apt / yum)	Update it with your package manager — the distributions have already shipped the fix
Docker	One-command container upgrade
Shared hosting	You cannot change PHP yourself — ask your host to upgrade as soon as possible

One-command fix

Run this on the server as root:

curl -fsSL https://raw.githubusercontent.com/lizhipay/php/main/php-security-update.sh -o php-security-update.sh && bash php-security-update.sh --harden

The script finds every PHP on the server by itself and handles each one according to where it came from and which version it is:

Version	What the script does
8.2 / 8.3 / 8.4 / 8.5	Upgrades to the latest fixed release in the same series
7.4 / 8.0 / 8.1	Applies the PHP project's official fix patches and recompiles
7.0 – 7.3, 5.4 – 5.6	Applies fix patches back-ported by this project and recompiles
5.3 and older	Can only apply the mitigation settings the PHP project recommends

The script leaves PHP from system packages (apt / yum) alone and just tells you which update command to run.

Could this break my store?

• Each version is compiled and checked first, and only swapped in once it passes. A full backup is taken before the swap.
• If the new version fails to start, the old one is restored automatically.
• The store is only interrupted for a second or two while PHP restarts.
• Every PHP source download is verified against its SHA256 checksum.

How long compiling takes depends on the server — anything from a few minutes to half an hour. Run it at a quiet time of day.

See what would change first

If you would rather be careful, run a check that changes nothing:

bash php-security-update.sh --check --harden

Other useful options:

bash php-security-update.sh --harden --only 74,82   # Only handle the listed versions
bash php-security-update.sh --harden -y             # Skip the countdown and start right away

What --harden in the commands does

--harden also switches on session hardening, which fixes an older problem that is separate from the two vulnerabilities above: an attacker can use PHP's session mechanism to slip in a malicious object, which also lets them run code. The official fix this time does not cover it, so every command on this page includes --harden.

Once it is on, objects are never allowed in sessions. ACG SHOP only stores plain data in sessions, so your store is completely unaffected. Even if your PHP is already the latest version, it is recompiled once to build this fix in.

If the same server also runs another PHP application that stores objects in sessions, that application may break once hardening is on. In that case, run the command again without --harden.

Cannot reach GitHub

If your server cannot download the script from GitHub, use this address instead:

curl -fsSL https://cdn.jsdelivr.net/gh/lizhipay/php@main/php-security-update.sh -o php-security-update.sh && bash php-security-update.sh --harden

Docker users

The official image already ships the fixed PHP 8.2.35, with session hardening switched on by default. There is nothing for you to set up.

Run this one command on the server to upgrade to the latest image:

curl -fsSL https://raw.githubusercontent.com/lizhipay/acg-faka/main/docker/upgrade.sh | bash

The script takes care of the following:

• It finds the store's container on this machine, whether it was created with docker run, aaPanel or 1Panel.
• It first checks that /data is mounted on a data volume. If it is not, the script stops rather than risk losing data.
• It pulls the latest image and recreates the container with the same ports, data volume, environment variables and restart policy. Your data is left exactly as it was.
• If the new container will not start, it switches back to the old one automatically and the store keeps running.
• If you are already on the latest version, it does nothing.

If you installed with docker compose, the script updates the source code and rebuilds the image for you. That step compiles PHP, so it takes anywhere from a few minutes to 10–20 minutes.

When you see this line, the upgrade has succeeded:

[acg-faka] 当前：PHP 8.2.35，session 硬化已开启

The script prints its messages in Chinese. This line means "Current: PHP 8.2.35, session hardening enabled".

The admin panel's "online upgrade" cannot fix this vulnerability

The online upgrade only updates the store program. PHP itself is built into the image, so the only way to get the fix is to switch to the new image.

And do not run the one-command fix script above inside the container. For Docker users, switching the image is all it takes.

A few special cases:

• Permission denied: put sudo in front of bash.
• Several store containers on one machine: add the container name to the end of the command, for example ... | bash -s -- faka.
• Cannot reach GitHub: replace the script address with https://cdn.jsdelivr.net/gh/lizhipay/acg-faka@main/docker/upgrade.sh.
• Pulling the image fails: usually the server cannot reach ghcr.io. The script stops before it touches the container, so your store is unaffected. Set up a proxy or a registry mirror for Docker, then run it again.

Checking the fix worked

aaPanel / PHP you installed yourself:

php -v

A version of 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later means you are fixed. Older versions (7.x, 8.0, 8.1) keep the same version number after patching, so go by the result the script prints at the end.

Then confirm session hardening is on — the output should be 1:

php -r 'echo ini_get("session.harden"), PHP_EOL;'

Docker:

docker exec faka php -r 'echo PHP_VERSION, " ", ini_get("session.harden"), PHP_EOL;'

If the output is 8.2.35 1, you are fixed. If your container is not named faka, use your own container's name.