For a company website or WordPress service, identify the PHP runtime that actually handles web requests and check its applicable security fixes. PHP2Shell concerns vulnerabilities in PHP itself, so updating one application plugin alone does not establish that the runtime is patched. Use the official advisory and the distribution’s package information to plan the response.
This article explains what operators should check based on KISA’s “Corporate Security Response Guidelines for PHP Security Vulnerabilities (PHP2Shell)” . The base date is October 22, 2026, and applies to website managers, server operators, and hosting users.
On this page
What’s wrong with PHP2Shell?
It’s easier to understand if you think of PHP as a worker that creates web pages. When a task fails midway, problems arise in the process of clearing up used memory, and an attacker can take advantage of the gap. PHP2Shell is the name given to the two vulnerabilities involved.
CVE-2026-109618: An issue that may use an incorrect memory state while handling out-of-memory errors.CVE-2026-109619: This is an issue where internal state used in a previous request remains and can be misused in the next request.
If the conditions are met, an attacker who is not logged in can execute commands with web server privileges or read authentication information remaining in memory. Both vulnerabilities have a severity rating of 9.2 based on CVSS 4.0. This doesn’t mean that attacks will succeed in the same way in all environments, but you shouldn’t skip checks just because you’re using PHP-FPM. (PHP Official Notice: Handling insufficient memory, PHP Official Notice: Handling status between requests)
Updating the WordPress main body and plugins does not change PHP at the same time. You must separately check for PHP security updates on your web server or hosting environment.
Which PHP version should I update to?
The revised version released by the PHP project on October 21, 2026 is as follows: Upgrade to the revised version or higher in the version series you are using, or apply the corresponding CVE security patch provided by the operating system/manufacturer. (PHP security update information)
| Series in use | official modified version |
|---|---|
| PHP 8.2 | 8.2.35 and higher |
| PHP 8.3 | 8.3.36 and higher |
| PHP 8.4 | 8.4.27 and higher |
| PHP 8.5 | 8.5.12 and higher |
For example, PHP 8.3.35 falls short of the fixes in the table above. However, some Linux distributions only apply security fixes while maintaining the existing version number. This is called Backport. These packages do not just compare numbers, but check the vendor’s security notices and package change history to see whether the two CVEs have been fixed.
Regular support for PHP projects below PHP 8.1 has ended. Patches from distribution/long-term support companies or source patches for some older versions can be used for temporary response, but a plan to move to a supported version is required. Security support for PHP 8.2 is scheduled to end on December 31, 2026, so if you are switching, it is best to check application compatibility and consider 8.3 or higher. (PHP official support period)
What should the operator check first?
1. Find PHP that is actually running
Start by checking the public homepage and also add the administrator page, test server, and outsourced production site to the list. If you only check PHP in the host operating system, you may miss PHP contained separately in containers or solutions. Version and patch status are recorded separately for each execution location. (PHP2Shell asset check data from NCSC-NL)
If you can connect to the server, you can check the default PHP version with the following command. The Docker Compose example assumes an environment with a service name of wordpress.
# 서버의 기본 PHP 확인
php -v
# Docker Compose로 운영하는 WordPress 컨테이너의 PHP 확인
docker compose exec wordpress php -vThis command reports command-line PHP, or CLI PHP. PHP-FPM or Apache may use a different runtime, so compare the executable, package or container that actually serves web requests. Use administrator tools or server configuration instead of leaving a public phpinfo() page online.
2. Update PHP and replace running processes
Check normal backup and recovery methods and, if possible, test whether login, main tasks, and file uploads operate normally in a separate environment. We will take action against services that are open on the Internet first, but for servers suspected of infringement, we will first follow the evidence preservation procedures below.
You should not assume that simply updating a package will automatically replace any old PHP running in memory. Restart the web service and PHP task process according to the method you are using, such as PHP-FPM or Apache mod_php. The container must be re-created and deployed as an image containing the modified PHP; simply restarting the old container will not change the image.
After restarting, check again whether the web service is actually using the modified PHP. If your hosting or equipment has PHP built-in, follow the update and restart procedures provided by your provider.
3. Review logs and replace potentially exposed authentication information
KISA recommends checking records at least after October 20, 2026, when vulnerability information was leaked, and if possible, checking records prior to that date as well. Look through request logs as well as PHP errors, processes executed, file changes, and external connection history.
- Repeated HTTP 500 errors, insufficient memory, and PHP abnormal termination for unknown reasons immediately after a large request is made.
- Traces of the web server executing a shell or download tool such as
sh·bash - New PHP files, changed pages, unfamiliar external scripts or communications in web/upload/temporary folders
Information leakage cannot be ruled out simply because there are no abnormal logs. For servers exposed to the Internet before the patch, review the replacement of authentication information accessed by PHP, such as DB password, administrator password, and API key. If there are any signs of infringement, we must preserve the evidence, maintain the server, and replace the relevant authentication information. The scope for discarding already issued tokens and sessions is also checked.
If it is difficult to update right away
Temporary measures are a means of reducing exposure until a patch is available. Check the latest rules of the web firewall (WAF) and limit the request size on the front-end web server/proxy. If your service does not use file uploads, consider blocking multipart requests.
PHP’s official setup instructions include the following: Since the application location varies depending on the service structure, the person in charge must check the official documentation before applying and restarting all PHP work processes.
- Upload progress:
session.upload_progress.enabled=0. Uses server settings that are applied before processing the request. - PHP Consider applying memory limit:
memory_limit=-1to prevent applications from changing it. Both front-end request limiting and resource protection are needed. - Request·Upload Size: Lower
post_max_sizeand keepupload_max_filesizesmaller than that. The front end also restricts requests without length information. - Apply PHP 8.5 Addendum:
fatal_error_backtraces=0. This is not a setting that is copied to other versions.
memory_limit=-1 is a value that removes PHP’s own memory upper limit. You should not just copy this value, as there is a greater risk of server resource exhaustion if you receive large requests as is. PHP’s official documentation guides you to review front-end limits and container/cgroup resource boundaries together. Even if you apply all of the above settings, it cannot replace the update. (PHP Official Temporary Response Guidelines)
If it is difficult to apply temporary measures, consider restricting external access or suspending the service until modifications are made. After patching, review the temporarily changed memory and upload settings and configure normal resource limits.
If a breach is suspected, evidence is preserved before restarting
A webshell is a file planted by an attacker to remotely manipulate a server. If you see these files or suspicious commands being executed, you must respond differently from the normal server update procedure.
- Isolation: Do not power off or restart the server, and isolate the network to prevent access from outside.
- Report: Protection Country‘s “Infringement Incident Report → Report” and respond with a security officer.
- Evidence Preservation: Obtain materials necessary for investigation, such as logs, running processes, and network connection information. Restarting may cause memory traces to disappear.
- Recovery: After securing evidence for , proceed with patching/restarting, removing the web shell, and replacing authentication information, and check whether it has been restored to a trustworthy state.
Do not run vulnerability verification code (PoC) whose source cannot be verified on the production server. It may be a fake tool mixed with malware. First, it is checked through version/supplier patch notices/operation records, and additional verification is conducted in an environment separate from the business network.
Ask your hosting company this:
If you do not manage PHP yourself, it is better to specify the items to be checked rather than asking “Is this the latest version?” The following are examples of things you can use when contacting us.
Please check which version of PHP our site actually uses and whether the patches CVE-2026-109618·CVE-2026-109619 have been applied. If it is a supplier patch, please provide a supporting notice or package information. Please let us know whether the PHP work process needs to be restarted after the update and the extent to which log checking and authentication information need to be replaced.
The first thing to record is “Actual PHP → Patch basis → Restart and redistribution completed → Service confirmation.” If there is a suspicion of infringement, we will respond first by securing evidence.
Confirmed official data
- KISA Protectorate: Corporate security response guidelines for PHP security vulnerabilities (PHP2Shell) — Posted on October 22, 2026
- PHP Project: PHP2Shell Security Update/Interim Measures — Announced on October 21, 2026
- PHP Official Security Notice: CVE-2026-109618
- PHP Official Security Notice: CVE-2026-109619
- PHP official support version and support period
- NCSC-NL: PHP2Shell operation support/software list
This article is an operational guide written after confirming the above official data on October 22, 2026. It is not the result of diagnosing a specific company’s server or determining whether it has been infringed. Patch and supplier information may change, so please re-check the original text when actually applying.
.jpg){kind=link}