PHP2Shell

Upgrade PHP Install a fixed PHP release on every runtime, then restart Apache, PHP-FPM and any long-running PHP workers. This is the only complete fix. Updating an application does not update the PHP runtime beneath it. Official PHP releases are available from php.net. Downstream distributions will make corresponding package updates available through their normal update channels. If you cannot upgrade immediately Upgrading PHP is the only complete remediation. The measures below may reduce exposure to specific exploitation paths while you prepare to upgrade, but they do not address every variant. Some measures can affect application functionality, performance or availability. Test configuration changes against your application's requirements and apply the PHP security update as soon as possible. Consider disabling PHP's finite memory limit Setting memory_limit = -1 can prevent some attack paths that rely on PHP's memory-limit handling, but it transfers memory-exhaustion handling to the operating system. With this configuration, memory-exhausted workers may be terminated, interrupting requests and affecting stability and availability of the server. If you decide to enable this, use Linux cgroup v2 memory.max, or an equivalent operating-system mechanism, to help contain resource consumption and limit the availability impact to PHP processes. Apply configuration changes administratively and restart the affected workers. Do not use RLIMIT_AS or RLIMIT_DATA as replacement memory limits. The PHP advisory warns that these can trigger the same vulnerable failure paths. This measure does not cover application-specific large-allocation paths or non-memory-related triggers. In threaded deployments, terminating a process can also interrupt requests running on other threads. Reduce attacker-controlled memory pressure Lower post_max_size to a value compatible with your application's upload requirements. This also constrains file uploads, so test legitimate upload flows. Lower max_input_nesting_level where the application permits it. Complex forms may require a higher limit. Set session.upload_progress.enabled = 0 if the application does not depend on upload-progress tracking. These settings limit particular sources of memory pressure. Other attacker-controlled paths to memory exhaustion remain. Disable PHP error display Set display_errors = 0 in production and restart the affected workers to prevent PHP error output from being exposed to remote users. This reduces an additional information-disclosure path but does not remediate the underlying vulnerabilities. Disable fatal-error backtraces where applicable Set fatal_error_backtraces = 0 where supported and restart the affected workers. This addresses the demonstrated fatal-backtrace mechanism, but other mechanisms can still trigger the vulnerability family. Reduce worker reuse Lower PHP-FPM pm.max_requests to recycle workers more frequently. This can reduce persistence of corrupted state across requests, but it has a performance cost and does not address mechanisms that do not rely on multiple requests. Constrain the impact of exploitation Use SELinux or AppArmor policies, where compatible with the application, to restrict worker capabilities and execution of other programs. These controls can constrain impact but should not be treated as preventing all exploitation or memory disclosure. Hardening after upgrading The PHP advisory describes a new hard memory limit in the fix. Reaching that limit terminates the process and prevents shutdown handlers from running. Review the operational effect on your application as part of the upgrade. After patching: Review memory_limit together with request-size limits and expected application memory use. Revisit any temporary memory_limit = -1 setting used before the upgrade and follow the final PHP recommendations. Keep post_max_size appropriately below the configured memory budget while supporting legitimate uploads. Limit max_input_nesting_level to the depth your application requires, and test complex forms. Consider expose_php = 0 to reduce PHP version disclosure. This is optional hardening and does not remediate PHP2Shell. These steps support application resilience after the security update. They do not replace patching.