What to check after an emergency PHP update: web PHP vs command-line PHP, set -e and diff exit codes, and an intrusion re-check

Audience: people who run PHP sites and are applying an emergency PHP update, or have just done so and worry about gaps.

In October 2026, fixed versions were released for two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619). A site this site's operator runs was updated that same night. This page turns what happened there, two first assumptions that turned out wrong and the intrusion re-check applied to every server afterwards, into general steps. The vulnerabilities and the fixed versions are covered in Two critical PHP vulnerabilities and the emergency fixed releases (October 2026).

What happened (at a site this site's operator runs)

The site uses PHP in more than one environment. Because the PHP team had announced when the fixed versions would be released, the operator switched to a maintenance page before the release and stayed offline until the fixed version was out. After it was out, they swapped it in and lifted the maintenance page.

1. After the announcement

   Switch to the maintenance page and wait for the fixed version

2. After the release

   Swap in the fixed version and lift the maintenance page

3. Post-update check

   The web side was updated, but the command-line PHP used by cron still pointed to an old version, so it was repointed

4. Same night

   A temporary script that lifted maintenance mode stopped before writing anything. Cause: set -e combined with diff. No harm was done, and the script was rebuilt

5. Afterwards

   The same intrusion checklist was applied to every server, and one suspicious request that had arrived before the update was checked by comparing files

The US CISA later added both CVEs to its catalog of vulnerabilities known to be exploited (KEV) (CISA announcement). That supports the decision to patch in a hurry, but a patch only closes the door. Checking that nobody had already come in is a separate job.

Assumption 1: "The web PHP is updated, so we're done"

The first assumption was that if the site runs on the new version, all PHP on that server is updated. In fact the command-line PHP that cron calls still pointed to an old version.

PHP can be a different program depending on how it runs (the SAPI, Server API). php.net notes that the CLI SAPI differs from the other SAPIs in many ways (PHP: Using PHP from the command line). With several versions installed on one machine, the web can run a new version while the command line runs an old one.

Check web and CLI separately

Assumption 2: "diff either succeeds or fails"

The temporary script that lifts maintenance mode was written to look at the difference between the current and new contents with diff before writing anything. It had set -e turned on.

diff returns exit status 1 when it finds differences. In the GNU manual, 0 means no differences, 1 means differences were found, and 2 means trouble (GNU diffutils: diff). Finding differences was exactly what the script expected. But set -e (errexit) stops the shell on a non-zero status, except in places such as conditions. The script stopped because there were differences, and never reached the write.

So the step that lifts maintenance mode stopped without writing anything, and there was no harm. It failed on the safe side, but the reverse combination, not stopping where it should, would be dangerous. The script was rebuilt.

Commands where exit status 1 is not an "error"

Safe patterns

The GNU Bash manual says that under set -e the shell does not exit when a command returns non-zero as part of an if test, in an && or || list other than the last command, or when its status is inverted with ! (GNU Bash: The Set Builtin). Use that.

Here is an example that separates 0, 1 and 2. A failure on the left side of || is exempt from errexit, so the script does not stop and rc holds the exit status.

#!/usr/bin/env bash
set -euo pipefail
 
rc=0
diff -rq deployed/ live/ || rc=$?
 
case "$rc" in
  0) echo "no differences" ;;
  1) echo "differences: review before continuing" ;;
  *) echo "diff failed" >&2; exit 2 ;;
esac

set -e is not a complete safety net. It has many exceptions that can hide mistakes, so for important branches it is easier to read the exit status yourself and decide (this site's advice).

After patching: run the same checks on every server

Patching closes the entry point. It does not tell you whether someone got in before the update. For KEV vulnerabilities, CISA asks for a check for intrusion before updating (see "Confirmed exploitation and addition to CISA's KEV" in the PHP article). To keep the checks from varying from server to server, the operator applied the same checklist to every server.

crontab -l shows only the current user's jobs, so check /etc/crontab, /etc/cron.d and the per-user cron spools separately. ss -tunp needs root to show the process behind every connection. dpkg -S and rpm -qf report which package owns a file; "no owning package" may still be a file you placed yourself, so check it against what you remember installing.

find -perm -4000 matches files that have all the given bits set (find(1)). docker diff lists files changed since the container was created (A: added, C: changed, D: deleted), and docker top displays the running processes (docker container diff, docker container top). Containers are normally rebuilt rather than modified, so treat an executable shown by docker diff as unexpected and investigate it (this site's advice).

How to read each item, and the steps for shared hosting, WordPress and a VPS, are in How to check if your website or server was hacked.

Settle a suspicious log entry by comparing files

During this check, the team found that before the update a POST had reached the contact form from a Tor exit node (an exit point of a network that hides the sender). A log only shows that the request arrived. It does not show whether anything was written as a result.

So they compared the live public files with the copy kept at deploy time. They matched exactly, and there were no extra PHP files. This check found no sign that any file had been altered.

What to do today

1. If you can log in to the server, run php -v and which php, and write the full path to PHP in your cron jobs
2. Check the web PHP version from the web side, such as Site Health (and delete any phpinfo() page right after use)
3. Find places in set -e scripts that call diff, grep or cmp, and decide how exit status 1 is handled
4. Keep a copy of what you published outside the server, and compare it after updates
5. Make the intrusion checklist identical on every server and run through it item by item

Sources

• PHP: Using PHP from the command line
• PHP: php_sapi_name
• GNU Bash Reference Manual: The Set Builtin
• GNU diffutils: diff, cmp, GNU grep
• update-alternatives(1), crontab(5), find(1)
• docker container diff, docker container top
• CISA: adds two vulnerabilities to the Known Exploited Vulnerabilities Catalog

Read next

• The vulnerabilities and the fixed versions: Two critical PHP vulnerabilities and the emergency fixed releases (October 2026)
• Checking for intrusion: How to check if your website or server was hacked
• Preparation: Backup and recovery essentials / Security inventory checklist
• Terms: What is RCE (remote code execution)? / What is an IOC (indicator of compromise)?