{"content_id":"vufynon7qa","slug":"php2shell-enterprise-security-patch-response-guide","locale":"en","schema_type":"HowTo","category":"how_to","category_name":"How-to","title":"PHP2Shell Enterprise Server Security Response","summary":"Start responding to PHP2Shell by updating PHP and restarting it on the live web service. If a breach is suspected, preserve evidence first. Log checks and credential rotation are needed even after patching.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["Check PHP usage on production servers and in products that include it.","If a breach is suspected, isolate the server and preserve evidence before restarting.","Apply a fixed version, or use the official temporary measures until you can update.","Restart the service running PHP, then verify that the patch has taken effect on the live web service.","Review past logs and rotate credentials on exposed servers."],"content_markdown":"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.\n\nThe versions and settings are based on the KISA notice dated October 22, 2026, and the additional PHP notice dated October 23.\n\n## What kind of vulnerability is PHP2Shell?\n\nPHP2Shell 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.\n\n| Category | Identifier | Nature of the issue |\n| --- | --- | --- |\n| Out-of-memory handling issue | CVE-2026-109618 | Processes incomplete internal data under out-of-memory conditions |\n| State left between requests | CVE-2026-109619 | Uses state pointing to freed memory in subsequent requests |\n\nKISA 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.\n\nKISA 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](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230), [Researchers' explanation of PHP2Shell](https://www.php2shell.com/)\n\n## Response sequence by situation\n\nThe 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.\n\n| Current status | What to do first | What to do next |\n| --- | --- | --- |\n| Public-facing server with no signs of compromise | Review compatibility and apply a fixed version | Restart, verify the version actually running, and review logs |\n| Web shell or suspicious connection found | Isolate the server from the network and report the incident | Preserve evidence, then take recovery measures |\n| Server that cannot be updated immediately | Apply official temporary settings and upstream request limits | Schedule and apply the patch |\n| Server where even temporary measures are difficult | Consider blocking external access or temporarily suspending service | Decide whether to resume after patching |\n| Environment managed by a hosting provider or manufacturer | Ask the provider whether the fix has been applied | Obtain evidence that the runtime environment reflects the fix |\n\nRestarting 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.\n\n## How to identify where PHP is used\n\nCheck 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.\n\n1. List websites and systems exposed to the internet.\n2. Check outsourced websites and older websites.\n3. Check event servers, test servers, and admin pages.\n4. Check whether device management interfaces and software solutions include PHP.\n5. Check container images and running containers.\n6. Record the PHP version and the person responsible for each environment.\n\nIf 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.\n\n## Fixed PHP versions and end-of-support criteria\n\nThe 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.\n\n| Branch in use | Versions with fixes for both vulnerabilities | Response criteria |\n| --- | --- | --- |\n| PHP 8.5 | At least 8.5.13 | Check the latest security release for this branch |\n| PHP 8.4 | At least 8.4.27 | Check the latest security release for this branch |\n| PHP 8.3 | At least 8.3.36 | Check the latest security release for this branch |\n| PHP 8.2 | At least 8.2.35 | Patch and prepare to move to a newer branch |\n| PHP 8.1 or earlier | Regular security support has ended | Move to a supported branch or check for vendor patches |\n\nThe 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](https://www.php.net/archive/2026.php)\n\nSecurity 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](https://www.php.net/supported-versions.php)\n\nRegular 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.\n\n## How to update and restart\n\nAfter 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.\n\n1. Review how the patch affects existing functionality.\n2. Check service compatibility in a test environment.\n3. Apply the fixed packages to internet-facing servers first.\n4. Restart all services that run PHP.\n5. For container environments, redeploy using fixed images.\n6. Verify that the update is reflected in the PHP instance that handles actual web requests.\n\nServices 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.\n\n`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.\n\n## Temporary configuration guidelines before updating\n\nTemporary measures reduce some attack paths. They do not resolve all the vulnerabilities. If applying the settings is difficult, consider blocking external access.\n\n### How should memory_limit be configured?\n\nThe 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.\n\nRemoving 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](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)\n\n| Item | Official temporary measure | What to check when applying it |\n| --- | --- | --- |\n| `memory_limit` | Set to `-1` | Apply an administrator-level setting so the application cannot change it |\n| `session.upload_progress.enabled` | Set to `0` | Use a configuration location that takes effect before request processing |\n| `post_max_size` | `8M` is an example when uploads are unnecessary | Review actual service requirements together with upstream limits |\n| `upload_max_filesize` | Set to less than `post_max_size` | Check the impact on file upload functionality |\n| `fatal_error_backtraces` | Set to `0` in PHP 8.5 | Do not apply indiscriminately to other branches |\n\nThe 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.\n\n1. Limit request sizes at the web application firewall, web server, and proxy.\n2. Check whether limits also apply to requests without size information.\n3. If uploads are unnecessary, block multipart requests upstream.\n4. Check the latest blocking rules for your web application firewall.\n5. Apply the settings in locations such as `php.ini` or the PHP-FPM pool configuration.\n6. Check whether evidence must be preserved, then restart the PHP processes.\n\nDo 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](https://www.php.net/archive/2026.php)\n\n### What to check in the additional October 23 notice\n\nIn 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.\n\nThe 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](https://www.php.net/archive/2026.php)\n\n## How to review logs and change credentials\n\nKISA 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.\n\n| Review target | Signs to look for |\n| --- | --- |\n| Web server logs | Repeated HTTP 500 errors |\n| PHP execution records | Abnormal termination and segfaults |\n| Web, upload, and temporary folders | New or modified PHP files |\n| Process execution records | The web server running sh, bash, or download tools |\n| Network connections | Signs of new connections to unfamiliar external addresses |\n| Website and admin pages | External scripts added without authorization |\n\nErrors alone do not confirm a compromise. Conversely, the absence of unusual records does not confirm safety. KISA provides the following guidance.\n\n\u003e Even if records show no anomalies, safety is not guaranteed, so carry out updates and credential changes together\n\u003e\n\u003e KISA, “Business Security Response Guidelines for PHP Security Vulnerabilities (PHP2Shell)”\n\nCredential 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.\n\nFor 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](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588)\n\n## Response sequence when a compromise is suspected\n\nIf 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.\n\n1. Block the server's external access at the network level.\n2. Businesses in South Korea should report the incident through the incident reporting menu on Boho Nara.\n3. Preserve logs and a list of running programs.\n4. Also preserve information about current network connections.\n5. Update and restart after collecting evidence.\n6. Remove web shells and change credentials.\n\nThe support contact in South Korea is KISA 118. The reporting menu is Boho Nara \u003e Report a Security Incident \u003e Submit a Report. If you operate overseas, check the reporting channel for that region.\n\n## Common mistakes compared\n\nVerifying 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.\n\n| Common assumption | What to verify |\n| --- | --- |\n| The job is done once `php -v` changes | Check the PHP actually used by the web service |\n| Installing the package is enough | Confirm that the services running PHP have been restarted |\n| An unchanged version number means no action was taken | Check the distribution changelog for the CVE fixes |\n| Having a web application firewall means patching can be skipped | Check the latest rules and update PHP as well |\n| Clean logs mean no data was leaked | Also review the possibility of credential exposure |\n| The vendor will handle outsourced websites on its own | Request evidence of the fix for each service |\n\nDo 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.\n\n## Completion checklist for outsourced and hosting environments\n\nIt 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.\n\n| Check item | What to request from the provider or person responsible |\n| --- | --- |\n| Missing targets | A checklist covering websites, admin pages, and test servers |\n| Vulnerability fixes | The applied version or a package changelog listing both CVEs |\n| Running state | Records of service restarts or container redeployments |\n| Actual application of the fix | The PHP runtime environment verified through the web service |\n| Compromise review | The period of logs reviewed and any findings |\n| Credentials | Credentials to be changed and whether the changes are complete |\n| Remaining work | Servers with only temporary measures applied and follow-up patch plans |\n\nFor 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.","content_html":"\u003cp\u003eResponding 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.\u003c/p\u003e\n\u003cp\u003eThe versions and settings are based on the KISA notice dated October 22, 2026, and the additional PHP notice dated October 23.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#what-kind-of-vulnerability-is-php2shell\" class=\"anchor\" id=\"what-kind-of-vulnerability-is-php2shell\"\u003e\u003c/a\u003eWhat kind of vulnerability is PHP2Shell?\u003c/h2\u003e\n\u003cp\u003ePHP2Shell 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategory\u003c/th\u003e\n\u003cth\u003eIdentifier\u003c/th\u003e\n\u003cth\u003eNature of the issue\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eOut-of-memory handling issue\u003c/td\u003e\n\u003ctd data-label=\"Identifier\"\u003eCVE-2026-109618\u003c/td\u003e\n\u003ctd data-label=\"Nature of the issue\"\u003eProcesses incomplete internal data under out-of-memory conditions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eState left between requests\u003c/td\u003e\n\u003ctd data-label=\"Identifier\"\u003eCVE-2026-109619\u003c/td\u003e\n\u003ctd data-label=\"Nature of the issue\"\u003eUses state pointing to freed memory in subsequent requests\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eKISA 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.\u003c/p\u003e\n\u003cp\u003eKISA 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. \u003ca href=\"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026amp;menuNo=205020\u0026amp;nttId=72230\"\u003eKISA response guidelines for businesses\u003c/a\u003e, \u003ca href=\"https://www.php2shell.com/\"\u003eResearchers' explanation of PHP2Shell\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#response-sequence-by-situation\" class=\"anchor\" id=\"response-sequence-by-situation\"\u003e\u003c/a\u003eResponse sequence by situation\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCurrent status\u003c/th\u003e\n\u003cth\u003eWhat to do first\u003c/th\u003e\n\u003cth\u003eWhat to do next\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Current status\"\u003ePublic-facing server with no signs of compromise\u003c/td\u003e\n\u003ctd data-label=\"What to do first\"\u003eReview compatibility and apply a fixed version\u003c/td\u003e\n\u003ctd data-label=\"What to do next\"\u003eRestart, verify the version actually running, and review logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Current status\"\u003eWeb shell or suspicious connection found\u003c/td\u003e\n\u003ctd data-label=\"What to do first\"\u003eIsolate the server from the network and report the incident\u003c/td\u003e\n\u003ctd data-label=\"What to do next\"\u003ePreserve evidence, then take recovery measures\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Current status\"\u003eServer that cannot be updated immediately\u003c/td\u003e\n\u003ctd data-label=\"What to do first\"\u003eApply official temporary settings and upstream request limits\u003c/td\u003e\n\u003ctd data-label=\"What to do next\"\u003eSchedule and apply the patch\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Current status\"\u003eServer where even temporary measures are difficult\u003c/td\u003e\n\u003ctd data-label=\"What to do first\"\u003eConsider blocking external access or temporarily suspending service\u003c/td\u003e\n\u003ctd data-label=\"What to do next\"\u003eDecide whether to resume after patching\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Current status\"\u003eEnvironment managed by a hosting provider or manufacturer\u003c/td\u003e\n\u003ctd data-label=\"What to do first\"\u003eAsk the provider whether the fix has been applied\u003c/td\u003e\n\u003ctd data-label=\"What to do next\"\u003eObtain evidence that the runtime environment reflects the fix\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eRestarting 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#how-to-identify-where-php-is-used\" class=\"anchor\" id=\"how-to-identify-where-php-is-used\"\u003e\u003c/a\u003eHow to identify where PHP is used\u003c/h2\u003e\n\u003cp\u003eCheck 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eList websites and systems exposed to the internet.\u003c/li\u003e\n\u003cli\u003eCheck outsourced websites and older websites.\u003c/li\u003e\n\u003cli\u003eCheck event servers, test servers, and admin pages.\u003c/li\u003e\n\u003cli\u003eCheck whether device management interfaces and software solutions include PHP.\u003c/li\u003e\n\u003cli\u003eCheck container images and running containers.\u003c/li\u003e\n\u003cli\u003eRecord the PHP version and the person responsible for each environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eIf 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#fixed-php-versions-and-end-of-support-criteria\" class=\"anchor\" id=\"fixed-php-versions-and-end-of-support-criteria\"\u003e\u003c/a\u003eFixed PHP versions and end-of-support criteria\u003c/h2\u003e\n\u003cp\u003eThe fixed version for the 8.5 branch in the official PHP notice is \u003cstrong\u003e8.5.12\u003c/strong\u003e. The original KISA notice lists the same version. This does not mean you must wait for 8.5.13 to patch.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eBranch in use\u003c/th\u003e\n\u003cth\u003eVersions with fixes for both vulnerabilities\u003c/th\u003e\n\u003cth\u003eResponse criteria\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Branch in use\"\u003ePHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"Versions with fixes for both vulnerabilities\"\u003eAt least 8.5.13\u003c/td\u003e\n\u003ctd data-label=\"Response criteria\"\u003eCheck the latest security release for this branch\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Branch in use\"\u003ePHP 8.4\u003c/td\u003e\n\u003ctd data-label=\"Versions with fixes for both vulnerabilities\"\u003eAt least 8.4.27\u003c/td\u003e\n\u003ctd data-label=\"Response criteria\"\u003eCheck the latest security release for this branch\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Branch in use\"\u003ePHP 8.3\u003c/td\u003e\n\u003ctd data-label=\"Versions with fixes for both vulnerabilities\"\u003eAt least 8.3.36\u003c/td\u003e\n\u003ctd data-label=\"Response criteria\"\u003eCheck the latest security release for this branch\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Branch in use\"\u003ePHP 8.2\u003c/td\u003e\n\u003ctd data-label=\"Versions with fixes for both vulnerabilities\"\u003eAt least 8.2.35\u003c/td\u003e\n\u003ctd data-label=\"Response criteria\"\u003ePatch and prepare to move to a newer branch\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Branch in use\"\u003ePHP 8.1 or earlier\u003c/td\u003e\n\u003ctd data-label=\"Versions with fixes for both vulnerabilities\"\u003eRegular security support has ended\u003c/td\u003e\n\u003ctd data-label=\"Response criteria\"\u003eMove to a supported branch or check for vendor patches\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eThe 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. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003ePHP security release notice\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eSecurity support for PHP 8.2 ends on December 31, 2026. KISA recommends moving to PHP 8.3 or later. Test application compatibility before migrating. \u003ca href=\"https://www.php.net/supported-versions.php\"\u003ePHP support schedule\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eRegular 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#how-to-update-and-restart\" class=\"anchor\" id=\"how-to-update-and-restart\"\u003e\u003c/a\u003eHow to update and restart\u003c/h2\u003e\n\u003cp\u003eAfter 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eReview how the patch affects existing functionality.\u003c/li\u003e\n\u003cli\u003eCheck service compatibility in a test environment.\u003c/li\u003e\n\u003cli\u003eApply the fixed packages to internet-facing servers first.\u003c/li\u003e\n\u003cli\u003eRestart all services that run PHP.\u003c/li\u003e\n\u003cli\u003eFor container environments, redeploy using fixed images.\u003c/li\u003e\n\u003cli\u003eVerify that the update is reflected in the PHP instance that handles actual web requests.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eServices 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.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ephp -v\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#temporary-configuration-guidelines-before-updating\" class=\"anchor\" id=\"temporary-configuration-guidelines-before-updating\"\u003e\u003c/a\u003eTemporary configuration guidelines before updating\u003c/h2\u003e\n\u003cp\u003eTemporary measures reduce some attack paths. They do not resolve all the vulnerabilities. If applying the settings is difficult, consider blocking external access.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#how-should-memory_limit-be-configured\" class=\"anchor\" id=\"how-should-memory_limit-be-configured\"\u003e\u003c/a\u003eHow should memory_limit be configured?\u003c/h3\u003e\n\u003cp\u003eThe official temporary recommendation for this vulnerability is \u003ccode\u003ememory_limit=-1\u003c/code\u003e. This value removes PHP's own memory usage limit. Do not treat it as a normal production setting.\u003c/p\u003e\n\u003cp\u003eRemoving 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. \u003ca href=\"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w\"\u003ePHP out-of-memory vulnerability advisory\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem\u003c/th\u003e\n\u003cth\u003eOfficial temporary measure\u003c/th\u003e\n\u003cth\u003eWhat to check when applying it\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003ememory_limit\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Official temporary measure\"\u003eSet to \u003ccode\u003e-1\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"What to check when applying it\"\u003eApply an administrator-level setting so the application cannot change it\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003esession.upload_progress.enabled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Official temporary measure\"\u003eSet to \u003ccode\u003e0\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"What to check when applying it\"\u003eUse a configuration location that takes effect before request processing\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003epost_max_size\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Official temporary measure\"\u003e\n\u003ccode\u003e8M\u003c/code\u003e is an example when uploads are unnecessary\u003c/td\u003e\n\u003ctd data-label=\"What to check when applying it\"\u003eReview actual service requirements together with upstream limits\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003eupload_max_filesize\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Official temporary measure\"\u003eSet to less than \u003ccode\u003epost_max_size\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"What to check when applying it\"\u003eCheck the impact on file upload functionality\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003efatal_error_backtraces\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Official temporary measure\"\u003eSet to \u003ccode\u003e0\u003c/code\u003e in PHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"What to check when applying it\"\u003eDo not apply indiscriminately to other branches\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eThe settings in the table are based on the official response notices from October 2026. \u003ccode\u003e8M\u003c/code\u003e is an example given for services that do not need uploads. It is not a standard size to apply to every service.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eLimit request sizes at the web application firewall, web server, and proxy.\u003c/li\u003e\n\u003cli\u003eCheck whether limits also apply to requests without size information.\u003c/li\u003e\n\u003cli\u003eIf uploads are unnecessary, block multipart requests upstream.\u003c/li\u003e\n\u003cli\u003eCheck the latest blocking rules for your web application firewall.\u003c/li\u003e\n\u003cli\u003eApply the settings in locations such as \u003ccode\u003ephp.ini\u003c/code\u003e or the PHP-FPM pool configuration.\u003c/li\u003e\n\u003cli\u003eCheck whether evidence must be preserved, then restart the PHP processes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eDo not apply temporary settings using only \u003ccode\u003eini_set()\u003c/code\u003e. Settings needed before request processing may take effect too late. Do not expect PHP-FPM's \u003ccode\u003e.user.ini\u003c/code\u003e to serve that role either. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eOfficial PHP temporary measures\u003c/a\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#what-to-check-in-the-additional-october-23-notice\" class=\"anchor\" id=\"what-to-check-in-the-additional-october-23-notice\"\u003e\u003c/a\u003eWhat to check in the additional October 23 notice\u003c/h3\u003e\n\u003cp\u003eIn 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.\u003c/p\u003e\n\u003cp\u003eThe 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) \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eAdditional PHP Session upload progress notice\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#how-to-review-logs-and-change-credentials\" class=\"anchor\" id=\"how-to-review-logs-and-change-credentials\"\u003e\u003c/a\u003eHow to review logs and change credentials\u003c/h2\u003e\n\u003cp\u003eKISA recommends reviewing, at a minimum, records from \u003cstrong\u003eOctober 20, 2026 onward\u003c/strong\u003e. Check earlier records too, if possible. Patching cannot undo a compromise or information leak that has already occurred.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eReview target\u003c/th\u003e\n\u003cth\u003eSigns to look for\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Review target\"\u003eWeb server logs\u003c/td\u003e\n\u003ctd data-label=\"Signs to look for\"\u003eRepeated HTTP 500 errors\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Review target\"\u003ePHP execution records\u003c/td\u003e\n\u003ctd data-label=\"Signs to look for\"\u003eAbnormal termination and segfaults\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Review target\"\u003eWeb, upload, and temporary folders\u003c/td\u003e\n\u003ctd data-label=\"Signs to look for\"\u003eNew or modified PHP files\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Review target\"\u003eProcess execution records\u003c/td\u003e\n\u003ctd data-label=\"Signs to look for\"\u003eThe web server running sh, bash, or download tools\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Review target\"\u003eNetwork connections\u003c/td\u003e\n\u003ctd data-label=\"Signs to look for\"\u003eSigns of new connections to unfamiliar external addresses\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Review target\"\u003eWebsite and admin pages\u003c/td\u003e\n\u003ctd data-label=\"Signs to look for\"\u003eExternal scripts added without authorization\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eErrors alone do not confirm a compromise. Conversely, the absence of unusual records does not confirm safety. KISA provides the following guidance.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eEven if records show no anomalies, safety is not guaranteed, so carry out updates and credential changes together\u003c/p\u003e\n\u003cp\u003eKISA, “Business Security Response Guidelines for PHP Security Vulnerabilities (PHP2Shell)”\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eCredential 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.\u003c/p\u003e\n\u003cp\u003eFor 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. \u003ca href=\"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026amp;mCode=C010010000\u0026amp;nttId=12588\"\u003ePersonal Information Protection Commission preventive measures notice\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#response-sequence-when-a-compromise-is-suspected\" class=\"anchor\" id=\"response-sequence-when-a-compromise-is-suspected\"\u003e\u003c/a\u003eResponse sequence when a compromise is suspected\u003c/h2\u003e\n\u003cp\u003eIf 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eBlock the server's external access at the network level.\u003c/li\u003e\n\u003cli\u003eBusinesses in South Korea should report the incident through the incident reporting menu on Boho Nara.\u003c/li\u003e\n\u003cli\u003ePreserve logs and a list of running programs.\u003c/li\u003e\n\u003cli\u003eAlso preserve information about current network connections.\u003c/li\u003e\n\u003cli\u003eUpdate and restart after collecting evidence.\u003c/li\u003e\n\u003cli\u003eRemove web shells and change credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe support contact in South Korea is KISA 118. The reporting menu is Boho Nara \u0026gt; Report a Security Incident \u0026gt; Submit a Report. If you operate overseas, check the reporting channel for that region.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#common-mistakes-compared\" class=\"anchor\" id=\"common-mistakes-compared\"\u003e\u003c/a\u003eCommon mistakes compared\u003c/h2\u003e\n\u003cp\u003eVerifying 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCommon assumption\u003c/th\u003e\n\u003cth\u003eWhat to verify\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eThe job is done once \u003ccode\u003ephp -v\u003c/code\u003e changes\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eCheck the PHP actually used by the web service\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eInstalling the package is enough\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eConfirm that the services running PHP have been restarted\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eAn unchanged version number means no action was taken\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eCheck the distribution changelog for the CVE fixes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eHaving a web application firewall means patching can be skipped\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eCheck the latest rules and update PHP as well\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eClean logs mean no data was leaked\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eAlso review the possibility of credential exposure\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eThe vendor will handle outsourced websites on its own\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eRequest evidence of the fix for each service\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDo 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#completion-checklist-for-outsourced-and-hosting-environments\" class=\"anchor\" id=\"completion-checklist-for-outsourced-and-hosting-environments\"\u003e\u003c/a\u003eCompletion checklist for outsourced and hosting environments\u003c/h2\u003e\n\u003cp\u003eIt 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCheck item\u003c/th\u003e\n\u003cth\u003eWhat to request from the provider or person responsible\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eMissing targets\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eA checklist covering websites, admin pages, and test servers\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eVulnerability fixes\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eThe applied version or a package changelog listing both CVEs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eRunning state\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eRecords of service restarts or container redeployments\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eActual application of the fix\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eThe PHP runtime environment verified through the web service\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eCompromise review\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eThe period of logs reviewed and any findings\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eCredentials\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eCredentials to be changed and whether the changes are complete\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Check item\"\u003eRemaining work\u003c/td\u003e\n\u003ctd data-label=\"What to request from the provider or person responsible\"\u003eServers with only temporary measures applied and follow-up patch plans\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eFor 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.\u003c/p\u003e\n","tags":["Personal data protection","PHP","Security updates"],"faqs":[{"question":"Can PHP2Shell be blocked by changing the login password?","answer":"It can be exploited without logging in, so changing the password alone does not resolve the issue. A PHP security update is required. Rotating credentials is a separate measure to address possible exposure."},{"question":"For PHP 8.5, do I need to wait until 8.5.13?","answer":"The original PHP and KISA notices list 8.5.13 as the fixed version for both vulnerabilities. This does not mean you need to wait for 8.5.13. When applying an update, also check the latest official release in that version series."},{"question":"If I use PHP-FPM, can I skip the checks?","answer":"PHP-FPM also needs to be checked. The conditions required for an attack may vary depending on how PHP is run. Do not judge safety based solely on the environment's name."},{"question":"If php -v shows a fixed version, is remediation complete?","answer":"The command-line PHP version may differ from the PHP version used by the web service. Check the environment that actually handles web requests. You must also check whether the running service has been restarted."},{"question":"If the version number stays the same after patching, did the patch fail?","answer":"Distribution or vendor packages may incorporate fixes into existing versions. Check the package changelog to see whether fixes for both CVEs have been included."},{"question":"Is memory_limit=-1 prohibited as part of the response to these vulnerabilities?","answer":"The official temporary guidance for these vulnerabilities includes this setting. It must be distinguished from general operational recommendations. Also review request limits and resource management measures."},{"question":"Are sites without file uploads also affected?","answer":"A site cannot be ruled out as affected simply because it has no upload feature. These are vulnerabilities in PHP itself, so check the version in use and its patch status. Blocking unnecessary multipart requests is a temporary measure."},{"question":"If a vendor patch is available for PHP 8.1 or earlier, can I keep using it?","answer":"Vendor patches must be checked separately from the end of regular support. Even if you apply such a patch temporarily, make a plan to move to a supported version."},{"question":"If there is nothing unusual in the logs, can I keep the existing credentials?","answer":"Logs alone cannot establish that no information was leaked. KISA recommends rotating credentials for servers that were exposed to the internet before patching. If there are signs of compromise, you must rotate them."},{"question":"If I suspect a compromise, should I update first?","answer":"First, isolate the system from the network. Report the incident and preserve evidence before updating. Restarting may erase traces of the attack remaining in memory."},{"question":"What should hosting users check?","answer":"Ask the provider for evidence that patches have been applied to each service. Also request the results of checks confirming restarts and the actual web runtime environment. Separately confirm whether logs have been checked and credentials rotated."},{"question":"Can I re-enable the upload progress setting after patching?","answer":"Check PHP's additional notice dated October 23, 2026. Keeping the feature disabled is recommended because of additional issues with some combinations of settings. Decide whether to restore the settings after checking subsequent fixes."}],"sources":[{"url":"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230","title":"KISA Boho Nara: Corporate security response guidelines for the PHP security vulnerability (PHP2Shell), October 22, 2026","type":"source"},{"url":"https://www.php.net/archive/2026.php","title":"PHP 2026 notices: October 21 security update and October 23 additional guidance on Session upload progress","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w","title":"PHP security advisory: RCE via OOM corruption","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp","title":"PHP security advisory: RCE via stale global state","type":"source"},{"url":"https://www.php.net/supported-versions.php","title":"PHP Supported Versions: Official support period","type":"data_point"},{"url":"https://www.php2shell.com/","title":"PHP2Shell: Researchers' explanation of the vulnerability and the scope of its impact","type":"source"},{"url":"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588","title":"Personal Information Protection Commission: Call for measures to prevent personal information leaks related to the PHP security vulnerability, October 22, 2026","type":"source"}],"images":[{"id":2106,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.","caption":"침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존해야 합니다.","description":null},"en":{"alt":"A woman holds a blue Ethernet cable connector near a rack server’s network port in a server room.","caption":"If a compromise is suspected, isolate the server and preserve evidence before restarting.","description":null},"ja":{"alt":"サーバールームで、女性がラックサーバーのネットワークポートの前に青いLANケーブルのコネクターを持っている。","caption":"侵害が疑われる場合は、サーバーを隔離し、再起動前に証拠を保全する必要があります。","description":null},"es":{"alt":"Una mujer sostiene el conector de un cable Ethernet azul junto al puerto de un servidor en una sala de servidores.","caption":"Si se sospecha una intrusión, hay que aislar el servidor y preservar las pruebas antes de reiniciarlo.","description":null},"id":{"alt":"Seorang perempuan memegang konektor kabel Ethernet biru di dekat port jaringan server rak di ruang server.","caption":"Jika dicurigai terjadi penyusupan, isolasi server dan amankan bukti sebelum memulai ulang.","description":null},"pt":{"alt":"Uma mulher segura o conector de um cabo Ethernet azul perto da porta de um servidor em uma sala de servidores.","caption":"Se houver suspeita de invasão, isole o servidor e preserve as evidências antes de reiniciá-lo.","description":null},"zh-hant":{"alt":"一名女子在伺服器機房內，手持藍色網路線接頭，靠近機架式伺服器的網路埠。","caption":"若懷疑遭到入侵，應先隔離伺服器，並在重新啟動前保全證據。","description":null},"de":{"alt":"Eine Frau hält den Stecker eines blauen Netzwerkkabels vor den Netzwerkanschluss eines Rackservers.","caption":"Bei Verdacht auf einen Angriff muss der Server isoliert und müssen vor dem Neustart Beweise gesichert werden.","description":null}}},{"id":2107,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습","caption":"PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스에 패치가 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"An older technician checks a tablet status screen beside an open network equipment cabinet in a factory.","caption":"After restarting PHP services, verify that the patch has taken effect on the live web service.","description":null},"ja":{"alt":"工場で、開いたネットワーク機器盤の横にあるタブレットの状態画面を確認する年配の技術者","caption":"PHP実行サービスの再起動後、実際のWebサービスにパッチが反映されていることを確認してください。","description":null},"es":{"alt":"Un técnico mayor revisa una tableta junto a un armario abierto con equipos de red en una fábrica.","caption":"Tras reiniciar los servicios de PHP, compruebe que el parche se haya aplicado al servicio web en producción.","description":null},"id":{"alt":"Teknisi senior memeriksa layar status tablet di samping kabinet perangkat jaringan yang terbuka di pabrik.","caption":"Setelah memulai ulang layanan PHP, pastikan patch telah diterapkan pada layanan web yang beroperasi.","description":null},"pt":{"alt":"Um técnico mais velho verifica um tablet ao lado de um armário aberto com equipamentos de rede numa fábrica.","caption":"Após reiniciar os serviços PHP, confirme que a correção foi aplicada ao serviço web em produção.","description":null},"zh-hant":{"alt":"一名年長技術人員在工廠內，查看開啟的網路設備櫃旁平板電腦上的狀態畫面","caption":"重新啟動 PHP 執行服務後，應確認實際運作的網頁服務已套用修補程式。","description":null},"de":{"alt":"Ein älterer Techniker prüft ein Tablet neben einem offenen Netzwerkschrank in einer Fabrik.","caption":"Prüfen Sie nach dem Neustart der PHP-Dienste, ob der Patch im laufenden Webdienst wirksam ist.","description":null}}}],"published_at":"2026-10-24T16:09:48+09:00","updated_at":"2026-10-24T16:09:48+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide"}