A useful report.
Not another black box.

1Executive summary

The production web server was running PHP 8.3.35, which is affected by both PHP2Shell vulnerabilities. During the agreed maintenance window we updated PHP to 8.3.36, restarted all PHP-FPM workers and confirmed that the application now serves traffic from the patched runtime. All agreed functional checks passed and no new errors were recorded.

The review also found an end-of-life PHP 7.4 pool outside the agreed scope, a pending kernel reboot and gaps in backup coverage. They do not affect the PHP2Shell fix, but they should be addressed. Each is listed with a priority in the recommendations.

PHP2Shell status

Patched

Functional checks

8 of 8 passed

Downtime

None observed

Follow-up actions

6, including 2 high priority

2Scope and method

Method

Read-only inventory over SSH with a time-limited key; package provenance checked against the vendor repository and the PHP advisory; a boot-verified snapshot before any change; the update applied through the system package manager; worker restarts; functional checks with the client’s test accounts. Temporary access was removed at 22:31.

3Server inventory

Recorded at the start of the work window, before any change.

4PHP runtimes

Every PHP binary and pool on the server was identified, including those outside the agreed scope.

PHP 7.4 has been end of life since November 2022 and receives no upstream security fixes. Exposure of the legacy pool could not be ruled out from version evidence alone; see recommendation R1.

Configuration observations

• expose_php is disabled and display_errors is off in production.
• OPcache is enabled with 128 MB of memory, sufficient for the application.
• session.upload_progress.enabled is on but not used by the application.
• Each pool runs as its own system user with a separate socket.

5Vulnerability status

A vendor-backported fix may have a different version number. The actual report uses the relevant vendor advisory. A successful patch verification does not establish that an environment was never compromised.

6Backups and recovery

Backups were reviewed before any change. The update could start only after a verified snapshot existed.

Findings

• The file backup excludes /var/www/shop/uploads, where about 6.2 GB of customer documents are stored.
• No restore test has been recorded for either scheduled backup. A backup that has never been restored cannot be relied on for recovery.
• Database dumps are encrypted and stored with a different provider, which protects them if the server or hosting account is lost.

Rollback plan for this change

Reinstall the previous PHP packages from the local package cache and reload PHP-FPM, or boot the pre-change snapshot. Estimated recovery time: 15 minutes. Rollback was not needed.

7Change log

8Post-change verification

9Findings and recommendations

Ordered by priority. None of these items blocks the PHP2Shell fix.

10Evidence and handover

• Environment identifiers and the agreed work window
• Package source, full version and applicable vendor advisory
• Backup reference, change log and process restart evidence
• Agreed functional checks, results and limitations
• Complete command transcript and package changelog excerpts

Prepared by

Patch Response

Reviewed with the client

2026-10-23

Snapshot reference

snap-20261022-2104

11Limitations

The report covers the agreed environment and checks at the recorded time. It is not a security certification, a guarantee against future vulnerabilities or a finding that no previous compromise occurred. Suspected compromise requires separate investigation.

Official PHP remediation guidance