PHP2SHELL CHECK01 Summary

01 Executive Summary

Summary

1 serving paths · 2 verdicts

Serving paths

Reachable

Mitigated (temporary)

Undetermined 1 · Patched 0

Configuration changes are a temporary mitigation. PHP has stated that configuration alone does not fully mitigate (PHP_취약점_동향_2026-10.en.md:96). 'Mitigated (temporary)' does not mean 'safe'.

There are 1 indicator-of-compromise items to review (06). They are evidence that needs review, not verdicts.

Verdict criteria

Reachable	The preconditions of the attack path confirmed by the document hold given this server's SAPI and effective configuration.
Mitigated (temporary)	A temporary mitigation from the document is applied at a stage before request parsing. This is a measure until the upgrade.
Undetermined	Not concluded due to insufficient evidence or unreadable configuration. This is not "unreachable".
Patched	At or above the fixed version, or the package changelog records a backport.

PHP2Shell Exposure Check Report · php7403-u20-fpm-useriniConfidential02

PHP2SHELL CHECK02 Inspection targets

02 Scope

Inspection targets

Verdicts per web server → SAPI/FPM pool → PHP build

ID	Target	Version verdict	Running	Web server
U01	PHP 7.4 FPM pool [www] 7.4.3-4ubuntu2.29	PHP 7.4 has no official fixed release; only a source backport exists (PHP_취약점_동향_2026-10.en.md:69). No CVE backport recorded in changelog (/usr/share/doc/php7.4-fpm/changelog.Debian.gz).	running 2026-10-23 21:50:32	nginx lab-php7.4.localhost

PHP2Shell Exposure Check Report · php7403-u20-fpm-useriniConfidential03

PHP2SHELL CHECK03 Verdicts by CVE

03 Findings

Verdicts by CVE

CVSS v4.0 9.2 · two CVEs × serving paths

CVE	Target	Verdict	Confidence	Fixed version	Rationale
CVE-2026-109618	U01	Undetermined	medium	none (EOL)	FPM terminates the worker on startup failure, which blocks this path, but analysis suggests it may be vulnerable after startup, so it cannot be declared unreachable (DOC:44).
CVE-2026-109619	U01	Reachable	high	none (EOL)	session.upload_progress is enabled (PHP default), so the session lifecycle path holds even without session_start(). Applies to both mod_php and FPM (DOC:54).

Verdict basis (serving paths)

F01 CVE-2026-109618UndeterminedU01

nginx lab-php7.4.localhost (/etc/nginx/sites-enabled/default:1)

location ~ \.php$ (/etc/nginx/sites-enabled/default:7)

→ unix:/run/php/php7.4-fpm.sock

FPM pool [www] (/etc/php/7.4/fpm/pool.d/www.conf:4) listen=/run/php/php7.4-fpm.sock

PHP 7.4.3 (dpkg: php7.4-fpm 7.4.3-4ubuntu2.29)

memory_limit exceeded during multipart parsing → cleanup of partially initialized data

SAPI=fpm, memory_limit=128M (/etc/php/7.4/fpm/php.ini:409)

F02 CVE-2026-109619ReachableU01

nginx lab-php7.4.localhost (/etc/nginx/sites-enabled/default:1)

location ~ \.php$ (/etc/nginx/sites-enabled/default:7)

→ unix:/run/php/php7.4-fpm.sock

FPM pool [www] (/etc/php/7.4/fpm/pool.d/www.conf:4) listen=/run/php/php7.4-fpm.sock

PHP 7.4.3 (dpkg: php7.4-fpm 7.4.3-4ubuntu2.29)

fatal error aborts cleanup → the next request on the same worker consumes stale state

SAPI=fpm, session.upload_progress.enabled=1 (PHP default)

session.upload_progress.enabled=0 (/var/www/html/.user.ini:1) — .user.ini/ini_set is applied too late to have any effect (DOC:108).

PHP2Shell Exposure Check Report · php7403-u20-fpm-useriniConfidential04

PHP2SHELL CHECK04 Remediation

04 Remediation

Remediation

By priority · file and line level

ImmediatePHP 7.4: check whether the package source provides a backport

Problem

PHP 7.4 has no official fixed release; only a source backport exists (PHP_취약점_동향_2026-10.en.md:69). No CVE backport recorded in changelog (/usr/share/doc/php7.4-fpm/changelog.Debian.gz).

Current

php7.4-fpm 7.4.3-4ubuntu2.29

Location

official distribution package · targets U01

Fix

Check the package source for security updates; if there are none, move to a supported branch.

Verify

zcat /usr/share/doc/php7.4-fpm/changelog.Debian.gz | grep -E 'CVE-2026-109618|CVE-2026-109619'

References

PHP_취약점_동향_2026-10.en.md:69

Temporary mitigationCVE-2026-109619 temporary mitigation: disable session.upload_progress

Problem

Upload progress, enabled by default, opens the stale state consumption path.

Current

session.upload_progress.enabled=1 (PHP default)

Location

/etc/php/7.4/fpm/pool.d/www.conf · targets U01

Fix

Add to the [www] section of /etc/php/7.4/fpm/pool.d/www.conf:
php_admin_value[session.upload_progress.enabled] = 0
※ ini_set() and .user.ini have no effect

Verify

sudo systemctl restart php7.4-fpm
sudo python3 php2shell_host.py  # re-run the check to confirm the verdict changed

Impact

Session-based upload progress display will not work.

References

PHP_취약점_동향_2026-10.en.md:54, :108

Temporary mitigationCVE-2026-109618 temporary mitigation: lock memory_limit + limit request size

Problem

When memory_limit is exceeded during multipart parsing, partially initialized request data is cleaned up and memory corruption occurs.

Current

memory_limit=128M (/etc/php/7.4/fpm/php.ini:409)
post_max_size=8M (/etc/php/7.4/fpm/php.ini:694)
upload_max_filesize=2M (/etc/php/7.4/fpm/php.ini:846)
nginx client_max_body_size=1m (default) (/etc/nginx/sites-enabled/default:1)

Location

/etc/php/7.4/fpm/pool.d/www.conf · targets U01

Fix

Add to the [www] section of /etc/php/7.4/fpm/pool.d/www.conf:
php_admin_value[memory_limit] = -1

memory_limit=-1 removes the per-request cap, so also set a service-level memory cap:
sudo systemctl edit php7.4-fpm
  [Service]
  MemoryMax=<value for this server's memory>
(do not use RLIMIT_AS/RLIMIT_DATA)

Verify

sudo systemctl restart php7.4-fpm
sudo python3 php2shell_host.py  # re-run the check to confirm the verdict changed

Impact

If the app does not use multipart, blocking multipart requests entirely in front of the web server is the most reliable option (DOC:105).

References

PHP_취약점_동향_2026-10.en.md:101-105

Temporary mitigationClean up ineffective mitigation settings

Problem

Settings in this location are applied after request parsing and have no effect.

Current

session.upload_progress.enabled=0 (/var/www/html/.user.ini:1)

Location

/var/www/html/.user.ini:1 · targets U01

Fix

Remove the line and move the setting to the pool/php.ini level.

Verify

sudo python3 php2shell_host.py  # re-run the check to confirm the verdict changed

References

PHP_취약점_동향_2026-10.en.md:108

HardeningStop exposing the PHP version header (expose_php)

Problem

X-Powered-By discloses the PHP version, which is used to select attack targets.

Current

expose_php=On (/etc/php/7.4/fpm/php.ini:379)

Location

/etc/php/7.4/fpm/php.ini:379 · targets U01

Fix

/etc/php/7.4/fpm/php.ini:379: expose_php = Off

Verify

sudo systemctl restart php7.4-fpm
curl -sI https://<host>/ | grep -i x-powered-by   # should print nothing

PHP2Shell Exposure Check Report · php7403-u20-fpm-useriniConfidential05

PHP2SHELL CHECK05 Indicators of compromise · Appendix

05 Compromise & Appendix

Indicators of compromise · Appendix

Items to review, not verdicts · disclosure of the check method

Needs reviewCheck for indicators of compromise: .php files changed since 2026-10-17

These may be legitimate changes from deployments. Compare with the deployment history and check any files that cannot be explained.

1 files

2026-10-23 01:52  /var/www/html/index.php

find /var/www/html -name '*.php' -newermt 2026-10-17 -ls

Transparency appendix

Non-destructive	0 commands executed · 0 network requests · writes only to the report directory (/tmp/php2shell_report)
Files read	40 (full list in report.json)
Files not read	0
Limitations	Effective values are based on configuration files, and whether a restart applied them is estimated from file modification times. Apache php_* directives are treated globally. RHEL-family package versions, php-cgi/LiteSpeed/FrankenPHP, and exploitation success conditions (AC:H/AT:P) are not assessed.

PHP2SHELL CHECK2026-10-23 22:41:26

PHP2Shell Exposure Check Report · php7403-u20-fpm-useriniConfidential06

PHP2SHELL CHECK06 Handling running legacy servers

06 Operating Guidance

Handling running legacy servers

Today · This week · Upgrade path · When upgrading is impossible

Most people already know that upgrading is the answer. The problem is how to handle the running server until then.

1. Today: what you can do without stopping the service

Identify PHP paths and upload/admin screens exposed to the internet, and close unnecessary exposure first.
Apply the temporary mitigations in §Remediation and restart all workers. Configuration alone does not fully mitigate (DOC:96, :108).
Limit request size and the number of multipart parts in front of the web server/proxy, and block multipart for apps that do not use it (DOC:103, :105). A WAF is a stopgap that only affects traffic passing through it (DOC:115).
Scope the compromise investigation from 2026-10-17, not from the disclosure date (DOC:125). The absence of logs does not mean safe (DOC:126).

2. This week: obtain packages that include the security fix

Check distribution and LTS vendor packages for security updates. For distribution packages, check the changelog for backports (DOC:69, :72, :172).
Check whether a fixed build is available through extended support services (e.g. paid extended security support from the distribution, commercial PHP long-term support). Confirm availability directly with the provider.
PHP 7.3 and earlier have neither a PHP-side patch nor a source backport (DOC:70). Skip this step and go to steps 3 and 4.

3. Upgrade path: migrate without downtime

The target is a branch with active security support. 8.2 reaches end of support on 2026-12-31, so 8.3 or later is recommended (DOC:161).
Check compatibility first with static analysis (e.g. the PHPCompatibility rules for PHP_CodeSniffer) and automated refactoring tools (e.g. Rector), and confirm that the extensions, frameworks, and CMS in use support the target version.
Run the new version side by side in a separate FPM pool or container, migrate in the order staging → partial traffic → full cutover, and keep a path to roll back to the previous version.

4. When you cannot upgrade right away

Remove direct internet exposure: move the server behind an access-controlled internal network or VPN, or publish only the strictly necessary functions through a reverse proxy.
CISA has recommended taking systems that cannot be patched or run 8.1 or earlier offline (DOC:114).
If you still continue to operate it, document the risk acceptance: approving owner, compensating controls applied, and review deadline.

5. When you find it on another organization's server

Do not inspect or verify it directly without permission. Notify the operator or the official reporting channel of the system's country (e.g. CISA in the US, NCSC in the UK, JPCERT/CC in Japan, KISA / KrCERT/CC in Korea).
Do not disclose the vulnerability or the target until remediation is complete.

DOC in the references refers to PHP_취약점_동향_2026-10.en.md.

PHP2SHELL CHECK2026-10-23 22:41:26

PHP2Shell Exposure Check Report · php7403-u20-fpm-useriniConfidential07

PHP2ShellExposure Check Report

Summary

Verdict criteria

Inspection targets

Verdicts by CVE

Verdict basis (serving paths)

Remediation

Indicators of compromise · Appendix

Transparency appendix

Handling running legacy servers

1. Today: what you can do without stopping the service

2. This week: obtain packages that include the security fix

3. Upgrade path: migrate without downtime

4. When you cannot upgrade right away

5. When you find it on another organization's server

PHP2Shell
Exposure Check Report