If you suspect a PHP worker was compromised

CVE-2026-109618 and CVE-2026-109619 were disclosed on 21 October 2026. A vulnerable server is an exposure. A compromised server is an incident. This guide covers the second case: what to do in the first hours when a PHP worker looks wrong, and in what order, so you keep the evidence you need and do not rebuild onto the same problem.

Suspected versus confirmed

Level	Typical signals	Action
Vulnerable only	Runtime is unpatched. No odd behavior.	Follow the emergency response and patch.
Suspected	PHP workers spawn processes you do not expect, write files the application does not own, open outbound connections you do not recognize, or crash in unusual patterns.	Treat as an incident. Preserve, isolate, investigate.
Confirmed	Independent evidence that an unauthorized party ran code or accessed data, such as an unknown process with network connections, altered files outside deploy history, or credentials used from an unexpected place.	Full incident process, escalate, notify per your obligations.

CISA said it had not observed exploitation as of 21 October 2026. That statement can change, and absence of reports is not evidence about your host. Decide from your own telemetry.

The order matters

Step 1: Preserve evidence before remediation

Do not patch, restart, or delete on the suspect host until you have captured what is volatile. A restart destroys process state, and a cleanup destroys file timestamps.

Memory and disk imaging is a specialist task. If your policy or insurer requires it, call your responder now. At minimum, take the read-only captures below and write them off the host, to storage the host cannot modify.

READ-ONLY

# Create a case directory on a mounted evidence volume, not on the suspect disk
CASE=/mnt/evidence/case-$(date -u +%Y%m%dT%H%M%SZ)
sudo mkdir -p "$CASE"

# Process tree with start times and parent relationships
ps -eo pid,ppid,user,lstart,args --forest | sudo tee "$CASE/ps.txt" >/dev/null

# Listening sockets and established connections, with owning processes
sudo ss -tunap | sudo tee "$CASE/ss-connections.txt" >/dev/null
sudo ss -tlnp  | sudo tee "$CASE/ss-listeners.txt" >/dev/null

# Logged in users and recent logins
who -a  | sudo tee "$CASE/who.txt" >/dev/null
last -n 50 | sudo tee "$CASE/last.txt" >/dev/null

Capture logs for the PHP and web units, scoped to the window around the first suspicious signal:

sudo journalctl -u php8.3-fpm --since "2026-10-21" --no-pager | sudo tee "$CASE/journal-php-fpm.txt" >/dev/null
sudo journalctl -u nginx --since "2026-10-21" --no-pager      | sudo tee "$CASE/journal-nginx.txt" >/dev/null
sudo journalctl -k --since "2026-10-21" --no-pager            | sudo tee "$CASE/journal-kernel.txt" >/dev/null

Replace the unit names with yours. Copy web server access and error logs from /var/log to the same location, and record a checksum of every file you collect.

sudo sh -c "cd '$CASE' && sha256sum * > SHA256SUMS"

For containers, preserve first by saving the container filesystem and logs (for example with your orchestrator’s snapshot or export feature) before you delete the pod. Record the image digest. Deleting the pod is the container version of wiping the disk.

Step 2: Isolate the host

Remove the system from the internet. Prefer a network level change over powering off, because shutdown loses memory.

SERVICE CHANGE

• Remove the host from the load balancer or DNS.
• Apply a security group or firewall rule that blocks inbound and outbound traffic except for your responders.
• Keep the machine running if your policy requires memory capture.

Do not log into the host from a workstation that holds production credentials. Use a dedicated responder machine.

Step 3: Assess impact

The impact PHP describes is code execution as the worker user. So ask what that user could read or reach:

1. Which files, environment variables, and secrets were readable by the worker account, such as application configuration, database credentials, API tokens, and signing keys?
2. Which network destinations could the host reach, such as the database, internal APIs, and cloud metadata?
3. Which data did the application handle?

Rotate every credential the worker could read, starting with those that grant the broadest access. Rotating before isolation is useless, so do it after Step 2 and from a clean machine.

Step 4: Rebuild, do not clean in place

Delete-and-hope is not a recovery. Build a new host or image from a patched runtime and deploy application code from your own repository, never from the suspect document root.

1. Provision a clean host from a trusted base image or package source.
2. Install a fixed runtime: an upstream fixed release (8.2.35, 8.3.36, 8.4.27, 8.5.12) or a vendor fixed package. For example, Ubuntu 24.04 lists php8.3 fixed in 8.3.6-0ubuntu0.24.04.13 under USN-8948-1. For PHP 8.1 and older, use a vendor package or upgrade.
3. Deploy application code from version control, with the commit you can identify.
4. Restore data from a backup taken before the suspected window, and check it for tampering.
5. Apply new credentials only.

Step 5: Verify

After the rebuild, the same checks as any patch apply. An incident rebuild that boots the old image has repeated the exposure.

READ-ONLY

ps -eo pid,lstart,args | grep -E '[p]hp-fpm'
/usr/sbin/php-fpm8.3 -v
dpkg -s php8.3-fpm | grep -E '^Version'

Watch outbound connections and process creation on the new host for several days. Compare against a baseline from before the incident.

When to escalate

Escalate to a specialist responder, legal, and leadership when any of these is true:

• You have evidence, not just suspicion, of unauthorized code execution or data access.
• Regulated or customer data may have been exposed.
• You cannot explain a process, connection, or file from your own change history.
• The host has credentials that reach other systems you cannot immediately rotate.
• Your policy, contract, or insurer requires notification.

Escalation is not an admission of a breach. It is how you get the right people involved while evidence is still intact. Our PHP incident response service covers evidence handling and rebuild planning.

Completion checklist

• The incident is classified as vulnerable only, suspected, or confirmed.
• Volatile data and logs were captured and copied off the host before any change.
• Captured files have recorded checksums.
• The host is isolated from the internet and from production credentials.
• Credentials readable by the worker were rotated from a clean machine.
• The replacement runtime is upstream fixed or a vendor fixed package.
• Application code was deployed from version control, not the suspect directory.
• The new worker process was started after the install and its version was checked.
• Escalation criteria were reviewed and decisions recorded.

Questions

Should I delete the suspicious files and keep the server running?

No. Preserve evidence first, then isolate the host and rebuild from a known good source. Deleting files in place removes evidence and does not prove the host is clean.

Is a vulnerable server automatically a compromised server?

No. A vulnerable runtime is an exposure. A confirmed compromise needs evidence of attacker activity. Treat unverified suspicion as an incident to investigate, and do not declare a breach without evidence.

Sources checked

• CISA alert, 21 October 2026
• PHP security advisory, 21 October 2026
• GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp