PHP2Shell Enterprise Server Security Response

Responding to PHP2Shell starts with identifying where PHP is used and applying a fixed version. Restart the services that run PHP after updating. If you suspect a compromise, preserve evidence before restarting. Log reviews and credential changes are also necessary after patching.

The versions and settings are based on the KISA notice dated October 22, 2026, and the additional PHP notice dated October 23.

What kind of vulnerability is PHP2Shell?

PHP2Shell is a PHP vulnerability that allows server-side code execution without authentication. It involves memory management while a web server processes requests. Whether an attack succeeds depends on the runtime environment and configuration.

KISA lists the severity of both vulnerabilities as CVSS 9.2. A successful attack could allow web shell installation or customer data theft. A web shell is a file used to gain unauthorized remote control of a server. Attacks could also lead to website defacement and intrusion into internal networks.

KISA reported information disclosure and attempted attacks before patches were released. The researchers disclosed how they used AI to discover the vulnerabilities. The issues are in PHP itself and are not limited to a particular website product. KISA response guidelines for businesses, Researchers' explanation of PHP2Shell

Response sequence by situation

The order of updating and preserving evidence depends on whether a compromise is suspected. For routine patching, test first, then update and restart. Isolate servers with a suspected compromise first.

Restarting after an update ensures that the fixed code runs. During incident response, restarting is delayed to preserve evidence. Even on the same server, follow the latter sequence if a compromise is suspected.

How to identify where PHP is used

Check both your asset inventory and the servers actually running. Checking only the main website can miss servers that have fallen outside routine management. Devices and containers that include PHP must also be checked.

1. List websites and systems exposed to the internet.
2. Check outsourced websites and older websites.
3. Check event servers, test servers, and admin pages.
4. Check whether device management interfaces and software solutions include PHP.
5. Check container images and running containers.
6. Record the PHP version and the person responsible for each environment.

If you use hosting, ask the provider to confirm whether patches have been applied. For PHP embedded in devices, check for manufacturer updates. Check internal systems too, but address internet-facing servers first.

Fixed PHP versions and end-of-support criteria

The fixed version for the 8.5 branch in the official PHP notice is 8.5.12. The original KISA notice lists the same version. This does not mean you must wait for 8.5.13 to patch.

The table is based on the fixed versions announced on October 21, 2026. Distribution packages may retain the same displayed version. In that case, check the changelog to see whether both CVEs have been fixed. PHP security release notice

Security support for PHP 8.2 ends on December 31, 2026. KISA recommends moving to PHP 8.3 or later. Test application compatibility before migrating. PHP support schedule

Regular security support has ended for PHP 8.1 and earlier. Patches from distributions or long-term support providers must be checked separately. The source patches released for older versions this time do not mean that regular support has resumed.

How to update and restart

After replacing the installed files, restart the services that run PHP. Existing processes may continue running code still in memory. If you suspect a compromise, preserve evidence before carrying out the steps below.

1. Review how the patch affects existing functionality.
2. Check service compatibility in a test environment.
3. Apply the fixed packages to internet-facing servers first.
4. Restart all services that run PHP.
5. For container environments, redeploy using fixed images.
6. Verify that the update is reflected in the PHP instance that handles actual web requests.

Services to restart include PHP-FPM and Apache mod_php. Also check php-cgi, FrankenPHP, and LiteSpeed. If a server has multiple PHP environments, check each one.

php -v shows the version of PHP running on the command line. It may differ from the PHP used by the web service. Do not judge an update complete based only on command-line output.

Temporary configuration guidelines before updating

Temporary measures reduce some attack paths. They do not resolve all the vulnerabilities. If applying the settings is difficult, consider blocking external access.

How should memory_limit be configured?

The official temporary recommendation for this vulnerability is memory_limit=-1. This value removes PHP's own memory usage limit. Do not treat it as a normal production setting.

Removing the limit reduces certain paths that trigger out-of-memory conditions. It does not prevent actual memory allocation failures. Request size limits and resource management measures must also be considered. PHP out-of-memory vulnerability advisory

The settings in the table are based on the official response notices from October 2026. 8M is an example given for services that do not need uploads. It is not a standard size to apply to every service.

1. Limit request sizes at the web application firewall, web server, and proxy.
2. Check whether limits also apply to requests without size information.
3. If uploads are unnecessary, block multipart requests upstream.
4. Check the latest blocking rules for your web application firewall.
5. Apply the settings in locations such as php.ini or the PHP-FPM pool configuration.
6. Check whether evidence must be preserved, then restart the PHP processes.

Do not apply temporary settings using only ini_set(). Settings needed before request processing may take effect too late. Do not expect PHP-FPM's .user.ini to serve that role either. Official PHP temporary measures

What to check in the additional October 23 notice

In its additional notice, PHP recommended disabling the upload progress feature. The notice addresses a separate execution path remaining under certain configuration combinations. If the feature is already disabled, the recommendation is to keep it disabled until the next regular bug-fix release.

The relevant conditions include changing the session serialization method at runtime. These conditions do not apply to every PHP installation. Check the additional notice before deciding whether to restore settings after patching. (Confirmed setting: recommendation to keep session.upload_progress.enabled=0 until the next regular bug-fix release · Source: php.net · Verified on 2026-10-23) Additional PHP Session upload progress notice

How to review logs and change credentials

KISA recommends reviewing, at a minimum, records from October 20, 2026 onward. Check earlier records too, if possible. Patching cannot undo a compromise or information leak that has already occurred.

Errors alone do not confirm a compromise. Conversely, the absence of unusual records does not confirm safety. KISA provides the following guidance.

Even if records show no anomalies, safety is not guaranteed, so carry out updates and credential changes together

KISA, “Business Security Response Guidelines for PHP Security Vulnerabilities (PHP2Shell)”

Credential changes are recommended for servers exposed to the internet before patching. Be sure to change credentials on servers where signs of compromise are found. This includes database passwords and administrator passwords. Also check whether API keys and access tokens may have been exposed.

For services connected to databases containing personal information, review database records too. Check for signs of bulk queries and data exfiltration. Also restrict direct internet access to phpMyAdmin. Reduce the web service account's database permissions to only what is needed. Personal Information Protection Commission preventive measures notice

Response sequence when a compromise is suspected

If you suspect a compromise, do not shut down the server or restart it immediately. Restarting may erase traces of an attack remaining in memory. Isolate the server from the network, then collect evidence.

1. Block the server's external access at the network level.
2. Businesses in South Korea should report the incident through the incident reporting menu on Boho Nara.
3. Preserve logs and a list of running programs.
4. Also preserve information about current network connections.
5. Update and restart after collecting evidence.
6. Remove web shells and change credentials.

The support contact in South Korea is KISA 118. The reporting menu is Boho Nara > Report a Security Incident > Submit a Report. If you operate overseas, check the reporting channel for that region.

Common mistakes compared

Verifying that a patch has been applied requires checking the running state and changelog too. An installation-complete message alone is not enough. Add the following assumptions to your checklist.

Do not run verification code found online on production servers. KISA warns of fake PoCs containing malware. A PoC is verification code that demonstrates whether a vulnerability can be exploited. Start by checking versions and patch histories to determine whether a system is vulnerable.

Completion checklist for outsourced and hosting environments

It is good practice to include supporting evidence for each service in a completion report. The table below groups the KISA response guidelines into operational check items. It is not a separate official submission form.

For example, suppose a provider reports only that package installation is complete. In that case, request the results of restart checks and verification of the web runtime environment. Log reviews and credential changes can be checked as separate items.