PatchPHP

Example report. Example Agency is a fictional company. The hosts, sites, versions, findings and evidence below are invented to show the format and level of detail of a PatchPHP findings report. They do not describe a real customer.

Findings report: agency portfolio assessment

Prepared for Example Agency, covering three servers and seven client sites, in response to the PHP2Shell advisory.

Client
Example Agency (fictional)
Report reference
EX-2026-001
Report date
22 October 2026
Assessment
Agency portfolio assessment
In scope
3 servers, 7 sites
Advisory basis
PHP2Shell, published 21 October 2026

1. Summary

Four of the seven sites are served by a PHP runtime that does not include the PHP2Shell fix, one has a fix installed but not running, and one runs a distribution build whose fix status we could not confirm. Only www.example.test is confirmed fixed and running the fixed code.

4Exposed
1Unconfirmed
1Partly fixed
1Fixed

The most urgent action is a single restart on web2 (F-1), followed by the PHP 8.2 update on web1 (F-2). Example Agency’s own check had reported web1 as patched because the command-line version is fixed; the sites themselves are served by older PHP-FPM pools.

2. Scope and method

  • In scope: web1.example.test (Ubuntu 24.04, nginx), web2.example.test (Debian 12, Apache) and legacy1.example.test (Ubuntu, nginx), and the seven sites they serve.
  • Information basis: environment details submitted in the dashboard and command output supplied by Example Agency’s administrator on request. No credentials were shared with PatchPHP.
  • Method: for each site, identify the web server configuration, the SAPI and runtime that serves it, its package source and its process start time, then compare with the PHP advisory and the vendor’s advisory.
  • Not in scope: production changes, compromise assessment, application code review and hosts not listed above.

No production changes were made during this assessment.

3. Runtime inventory

HostSiteSAPIPHP serving requestsPackage sourceStatus
web1.example.testshop.example.testPHP-FPM (pool shop)8.2.29Third-party repositoryExposed
web1.example.teststaging.shop.example.testPHP-FPM (pool staging)8.2.29Third-party repositoryExposed
web1.example.testblog.example.testPHP-FPM (pool blog)8.2.29Third-party repositoryExposed
web1.example.testwww.example.testPHP-FPM (pool www)8.4.27Third-party repositoryFixed
web2.example.testportal.example.testApache mod_php8.2 (distribution build)Debian 12 archiveUnconfirmed
web2.example.testapi.example.testPHP-FPM (pool api)8.4.26 running, 8.4.27 installedThird-party repositoryPartly fixed
legacy1.example.testintranet.example.testPHP-FPM7.4.33Built from sourceExposed

Status compares the runtime serving requests with the fixed release for its branch: 8.2.35, 8.4.27, or the source backport for 7.4.

4. Findings, in priority order

F-1Critical

api.example.test is still served by workers started before the update

Affected
api.example.test on web2.example.test
What we found
The php8.4-fpm package was upgraded to 8.4.27 on 21 October at 14:02, but the PHP-FPM master process has been running since 3 October. The workers serving the API therefore still run the vulnerable 8.4.26 code.
Evidence
E-4
Recommended action
Restart php8.4-fpm, then confirm the master process start time is after the upgrade and run the API health check. This is the quickest fix in the estate.
F-2Critical

Three sites on web1 are served by PHP 8.2.29, below the 8.2.35 fix

Affected
shop.example.test, staging.shop.example.test and blog.example.test on web1.example.test
What we found
The command line on web1 reports PHP 8.3.36, which is fixed. The nginx configuration for these three sites passes requests to PHP-FPM 8.2 pools, which report 8.2.29.
Evidence
E-1, E-2
Recommended action
Update the php8.2 packages from the repository in use to 8.2.35, restart php8.2-fpm and confirm each pool reports the fixed version. Test checkout on staging before production.
F-3Critical

portal.example.test runs mod_php with an unconfirmed vendor fix

Affected
portal.example.test on web2.example.test
What we found
The portal runs under Apache with mod_php, the configuration the PHP project considers highest risk. The module comes from the Debian 12 archive, whose version numbers differ from upstream. We could not confirm from the package version alone whether the installed build includes the fix.
Evidence
E-3
Recommended action
Resolve unknown U-1 against the Debian security tracker. If a fixed package is available, update and restart Apache. If not, apply the interim measures from the PHP advisory and review the move to PHP-FPM.
F-4Critical

intranet.example.test runs PHP 7.4.33 built from source without the backport

Affected
intranet.example.test on legacy1.example.test
What we found
PHP 7.4 reached end of life on 28 November 2022 and gets no upstream releases. The PHP security team published a minimal source backport for 7.4, but this build predates it and Example Agency confirmed no patches were applied.
Evidence
E-5
Recommended action
Apply the official interim measures now. Then either rebuild with the 7.4 source backport as a stopgap or move the application to a supported branch. A legacy compatibility assessment is recommended before choosing.
F-5Medium

PHP 8.2 reaches end of life on 31 December 2026

Affected
shop, staging.shop, blog and portal
What we found
After that date the PHP project will publish no further 8.2 releases. Four of the seven sites depend on it.
Evidence
E-2, E-3
Recommended action
Plan the move to PHP 8.4 or 8.5 for these sites in the first quarter. This is outside the proposed remediation scope.
F-6Low

The command-line PHP on web1 differs from every web runtime

Affected
web1.example.test
What we found
The default php binary is 8.3, while the sites run 8.2 and 8.4. Scheduled tasks using php run under a different version from the sites they maintain, and checks based on php -v give a misleading answer.
Evidence
E-1
Recommended action
Pin scheduled tasks to the same version as their site and record the per-site runtime in the inventory.

5. Remaining unknowns

These could not be confirmed from the evidence available. They are not assumed to be safe.

RefOpen questionWhat would resolve it
U-1Whether the installed Debian build of mod_php for PHP 8.2 includes the PHP2Shell fix.Package version output and the matching Debian security tracker entry.
U-2Whether staging.shop.example.test is reachable from the internet.Confirmation of the firewall or access rules for the staging hostname. This changes priority, not the fix.
U-3Whether any other hosts or containers in the agency’s deployment pipeline run PHP.Example Agency’s list of build and deployment hosts. Only the three servers listed were in scope.
U-4Whether any exposed system was compromised before this assessment.A log review. Compromise assessment was outside scope; we recommend it for the four exposed sites.

6. Proposed remediation scope

ItemAffectsChangeVerification
R-1api.example.testRestart php8.4-fpmMaster start time after the upgrade, API health check
R-2shop, staging.shop, blogUpdate php8.2 packages to 8.2.35 and restart php8.2-fpm, staging firstEach pool reports 8.2.35, checkout and sign-in journeys pass
R-3portal.example.testUpdate the Debian mod_php package and restart Apache, once U-1 is resolvedModule version matches the vendor fix, sign-in journey passes
R-4intranet.example.testNot included. Interim measures and a legacy compatibility assessment recommendedNot applicable
  • Prerequisites: a verified backup for web1 and web2, an agreed maintenance window, and access arranged separately for this job.
  • Recovery: if a check fails, the previous package is restored and the affected site is isolated rather than left publicly exposed on a vulnerable runtime.
  • Price: quoted in the dashboard with this scope. Standard remediation starts at $2,499, and the assessment fee is credited once.

7. Evidence appendix

Command output as supplied, trimmed to the relevant lines.

E-1: web1.example.test: command-line version and installed branches

Supplied by Example Agency’s administrator on 21 October.

$ php -v | head -n 1
PHP 8.3.36 (cli) (built: Oct 21 2026 09:12:40) (NTS)
$ ls /etc/php
8.2  8.3  8.4

E-2: web1.example.test: runtime serving shop.example.test

The same check was repeated for staging.shop and blog, with the same result.

$ grep -h fastcgi_pass /etc/nginx/sites-enabled/shop.example.test
        fastcgi_pass unix:/run/php/php8.2-fpm-shop.sock;
$ grep -l php8.2-fpm-shop.sock /etc/php/*/fpm/pool.d/*.conf
/etc/php/8.2/fpm/pool.d/shop.conf
$ php-fpm8.2 -v | head -n 1
PHP 8.2.29 (fpm-fcgi) (built: Jul  4 2026 08:01:55)

E-3: web2.example.test: PHP module loaded by Apache

Package version recorded; vendor fix status not yet confirmed (U-1).

$ apache2ctl -M 2>/dev/null | grep php
 php_module (shared)
$ dpkg-query -W -f='${Package} ${Version}\n' libapache2-mod-php8.2
libapache2-mod-php8.2 8.2.29-1+example1

E-4: web2.example.test: package upgrade time against process start time

The master process predates the upgrade, so its workers run the old code.

$ grep " upgrade php8.4-fpm" /var/log/dpkg.log
2026-10-21 14:02:17 upgrade php8.4-fpm:amd64 8.4.26-1+example1 8.4.27-1+example1
$ ps -o lstart= -p "$(cat /run/php/php8.4-fpm.pid)"
Sat Oct  3 06:14:52 2026

E-5: legacy1.example.test: source-built runtime

Example Agency confirmed in writing on 22 October that no patches were applied to this build.

$ /opt/php-7.4/sbin/php-fpm -v | head -n 1
PHP 7.4.33 (fpm-fcgi) (built: Nov 14 2022 10:21:07)

This was an example. A real report is written for your environment and published in your dashboard.

Assess a portfolioCompare assessments