DEV Community

Mohammed Samaan
Mohammed Samaan

Posted on

PHP2Shell: a client-proof patch checklist for freelancers (CVE-2026-109618 / 109619)

#php #security #webdev #wordpress

Free checklist, written 26 Oct 2026. It is a technical checklist, not legal advice, not a security audit, and no guarantee that a server is safe.
For freelancers and small agencies who look after other people's PHP and WordPress servers.
Version 1.1 · written 26 Oct 2026 · facts are as reported by the sources listed at the end, each with a read date.

What this is: a checklist you can run on a server (a guess: about 30 minutes for a simple one) and the words to send your client afterwards. It is not legal advice, not a security audit, and not a guarantee that a server is safe. It does not replace updating PHP; updating is the only complete fix (Tenable, citing PHP).

Before you start: only work on servers you are contracted to manage, get the client's written go-ahead before you change settings, take a site offline or restore a backup, and keep a written record of every command you run and every change you make. The commands below only read client data, except the settings and updates in Steps 3 and 4. The file search in section 4 writes one results file into your own home folder; delete it when you are done.

1. What happened (as reported by the sources)

  • On 21 Oct 2026 the PHP project fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619, together called "php2shell". Tenable, citing the PHP security team, gives both CVSS v4.0 9.2 (an earlier circulated score of 10.0 was wrong) and says an unauthenticated remote attacker can exploit them.
  • Amazon's honeypots recorded a first attempt on 17 Oct, four days before disclosure, and more on 21 Oct. Amazon says php2shell now sees broad exploitation attempts in the wild. CISA said it had not observed successful exploitation at publication; CISA revised its alert on 23 Oct, so that statement may be out of date. As of 23 Oct neither CVE was in CISA's KEV catalog (Tenable).
  • CISA says all PHP installations serving web requests are affected (Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed). CISA notes that PHP considers mod_php the highest risk.
  • Hostinger says the setting session.upload_progress.enabled = Off also protects against a further issue, CVE-2026-115560. We did not verify that CVE ourselves; check its status with your vendor.

2. Is this server affected?

PHP branch Status (Tenable, read 26 Oct)
8.5.x before 8.5.12, 8.4.x before 8.4.27, 8.3.x before 8.3.36, 8.2.x before 8.2.35 Affected. Fixed in 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (CISA names the same four; php.net's release feed lists each as a security release dated 21 Oct 2026)
7.4 to 8.1 No official release; "minimal source backports from the PHP security team". Rely on your OS vendor's package and their advisory
5.4 to 7.3 End of life, no fix from the PHP project

Do not trust php -v alone. It reports the command-line binary, which can differ from the PHP that serves web requests (FPM, mod_php, LiteSpeed). Packaged and hosted builds can also be fixed without the version number changing (Hostinger says so for its managed hosting).

3. The triage, per server

Step 1: find every PHP on the box (CISA: inventory all installs including embedded ones, internet-facing first).

which -a php php-fpm php-cgi
php -v; php-fpm -v | head -1       # on Debian/Ubuntu the FPM binary is versioned, for example php-fpm8.3; the dpkg line below lists it
apachectl -M | grep -i php          # on RHEL-family use: httpd -M | grep -i php
ps -eo user,pid,ppid,etime,cmd --forest | grep -E 'php-fpm|php-cgi|lsphp|frankenphp|httpd|apache2' | grep -v grep | head -40
dpkg -l 'php*' | grep '^ii'         # Debian / Ubuntu: every installed PHP package
rpm -qa 'php*'                      # RHEL / Alma / Rocky / Remi: every installed PHP package
Enter fullscreen mode Exit fullscreen mode

Errors here matter; do not hide them. A command that is missing on your system is itself information.

Step 2: is each installed package patched? Ask the package. Do this for every package from Step 1, not just one version.

# Debian / Ubuntu (needs network access)
apt changelog php8.3-fpm | grep -i -m3 109618      # change php8.3-fpm to each package you found
# RHEL / Alma / Rocky (package names vary, for example php-fpm or php83-php-fpm)
rpm -q --changelog php-fpm | grep -i -m3 109618
dnf updateinfo list --cve CVE-2026-109618          # if your dnf supports it
Enter fullscreen mode Exit fullscreen mode

If the changelog names the CVE, the package contains a fix. A missing CVE line does not mean unpatched, and a CVE line does not mean the running process has it: the service must have been restarted after the update. If you cannot tell, check your OS vendor's security advisory before telling a client anything.
Managed hosts: Hostinger states that a PHP build date of 21 Oct 2026 or later means its fix is in. That rule is Hostinger's; other hosts have their own, so ask them (section 7).

Step 3: interim settings, only if you cannot update yet, and only with the client's consent. They reduce exposure; they do not make the server safe (Tenable).

  • For CVE-2026-109619: session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool config. Setting it with ini_set in code does not work (Hostinger). Side effect: applications that show upload progress bars may stop working.
  • For CVE-2026-109618: Tenable, quoting PHP, lists memory_limit=-1 set so applications cannot override it. Warning from us: an unlimited memory limit lets one runaway request exhaust the server's memory and take down every site on it. Use it only on a server you control, with consent, and prefer a container or cgroup memory cap alongside it (Tenable suggests one). On PHP 8.5 Tenable also lists fatal_error_backtraces=0.
  • Amazon also suggests blocking multipart file uploads for systems that cannot be patched quickly, after you assess the impact on the application (many sites need uploads).
  • Restart every PHP worker after any change (FPM, Apache, LiteSpeed).

Step 4: update. Move to a fixed release or your OS vendor's patched package, restart, then repeat Step 2.

Step 5: PHP 8.1 or older that cannot be updated. CISA's recommendation is to take such systems offline until they are patched or upgraded. Taking a client's site offline is the client's decision; give them the choice in writing. PHP 8.2 security support also ends on 31 Dec 2026 (Hostinger; php.net), so plan the move now.

4. Check for signs of compromise

The public sources give very little to search for. Here is all of it, and how to use it honestly.

  • Start your review from 17 Oct 2026, not from 21 Oct (Amazon).
  • Look for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads (Amazon). Standard access logs do not record POST bodies, so this needs a WAF or ModSecurity audit log. If you have none, say so in your client report instead of claiming the server is clean.
  • Look for unexpected process execution and unexpected file changes on web servers (Amazon). 
# GNU find (Debian / RHEL; not BusyBox, Alpine or macOS). Times follow the server's timezone.
# Files changed since 17 Oct 2026 with extensions attackers commonly use. Adjust the path. Read-only.
umask 077   # results file readable by you only
nice find /var/www -xdev -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.inc' -o -name '.htaccess' -o -name '.user.ini' \) \
  -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM  %u  %p\n' | sort > "$HOME/changed-since-17oct.txt"
wc -l "$HOME/changed-since-17oct.txt"        # then read the whole file; delete it when finished
# PHP processes' children (look for shells or unexpected binaries under php-fpm or apache)
ps -eo user,pid,ppid,etime,cmd --forest | head -80
Enter fullscreen mode Exit fullscreen mode

Limits you must state to the client: file times can be forged and legitimate deploys also change files, and files with other extensions or in other paths are not covered. The web user is www-data on Debian, apache or nginx on RHEL, and a per-account user on cPanel.

  • Amazon's honeypot saw attempts from 103.216.220.92 (17 Oct) and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37 (21 Oct). These are shared anonymising infrastructure. Investigate hits from them; do not simply block them (Amazon).
  • A clean result from these checks means "we found nothing by these checks", not "we are safe".

5. If you find something

Tell the client immediately and let them decide. With their written go-ahead and after a fresh backup of the current state (keep it as evidence): take the site out of service, restore from a backup made before 17 Oct (note this can lose newer client data), update PHP, rotate every credential the site could read (database, API keys, admin and hosting passwords), and report what you found in writing. If the client is regulated they may have notification duties; that is for their lawyer, not this pack.

6. What to tell the client

Use the one-page report and the emails below. Rules: say what you checked, what you changed, what you could not check, and the date. Never write "secure" or "hack-proof".

7. Ask your host these four questions

  1. Which PHP build is my account running, and does it include the fix for CVE-2026-109618 and CVE-2026-109619? How can I verify that myself?
  2. When did you roll it out, and was every PHP version on my plan patched, including 8.1 and older?
  3. Is session.upload_progress.enabled off at server level?
  4. Do you keep WAF or audit logs I can search from 17 Oct onward? Reference point: Hostinger reports it completed its rollout on 22 Oct at 06:44 UTC. We did not verify any other host's status.

9. One-page client report (copy it)

Client: [name] · Site(s): [domains] · Server: [host / IP] · Checked by: [your name] · Date: [date] · Authorised by: [client name, date of written go-ahead]

Summary (one sentence)

[Pick one and delete the others]

  • Per the package changelog / host statement dated date, your server runs a PHP build that includes the fix, and the service was restarted on [date].
  • Your server was running a vulnerable PHP build. We updated it on [date], restarted the service and re-checked the package.
  • Your host has not confirmed a fix. With your consent we applied temporary settings and asked them to confirm. The risk remains until they do.
  • Your server runs PHP [version], which the PHP project no longer fixes. We recommend moving it by [date]; taking it offline until then is your decision.

What we checked

Check Result How
PHP builds present (CLI and web) [list] commands run, date
Fix present in the package yes / no / could not verify changelog or host statement, and restart date
Temporary settings applied (session.upload_progress.enabled = 0) yes / no / not applied file and restart date
Files changed since 17 Oct 2026 none found by this search (limits below) / [list] file search of [paths and extensions]
Unexpected processes none seen at the time / [list] process list, time
Web firewall or audit log available for 17 Oct onward yes / no

What we changed

[date, time, what, who]

What we could not check

[for example: no request-body logs, so we cannot rule out attempts; file times can be forged; the host did not answer question 3]

What this means

Finding nothing is not proof that nothing happened. The first attack attempts were reported on 17 Oct 2026. [one honest sentence about the residual risk]

Next steps

  1. [action, cost] by [date]
  2. [action, cost] by [date]

This is a technical check, not legal or insurance advice.

10. Emails (copy and edit)

A.Check completed (to your client)

Subject: Your website server: PHP security check completed

Hi [name],
On [date] we checked your server for the PHP vulnerability announced on 21 Oct 2026 (CVE-2026-109618 and CVE-2026-109619). [One sentence from the report summary.] The attached one-page report lists what we checked and changed.
One honest limit: [for example: we do not have request logs from before 21 Oct, so we cannot prove nothing was attempted]. We recommend [next step, with cost] by [date].
[your name]

B.Your host has not confirmed the fix (to your client)

Subject: Decision needed: your hosting provider has not confirmed the PHP fix

Hi [name],
A serious PHP vulnerability was announced on 21 Oct 2026, and Amazon reported exploitation attempts from 17 Oct. Your host has not yet confirmed that your plan is fixed. We asked them on [date] and have not had a clear answer.
What we have done meanwhile, with your earlier consent: [temporary settings]. These reduce the risk; they do not remove it.
Options: [wait until X / move to a host that confirms / update by Y]. Each has a cost: [cost]. Please reply with the option you choose and the cost you approve, in writing, and we will start only the work you name.
[your name]

C.To the host's support

Subject: Please confirm PHP2Shell fix for account [id]

Hello,
Please confirm for the account [id]: (1) which PHP build it runs and whether it includes the fix for CVE-2026-109618 and CVE-2026-109619, and how we can verify that ourselves; (2) the rollout date and whether all PHP versions on the plan, including 8.1 and older, are covered; (3) whether session.upload_progress.enabled is off at server level; (4) whether WAF or audit logs from 17 Oct onward are available to us.
Thank you,
[your name]

Sources (read 26 Oct 2026)

Top comments (0)