PHP2Shell (CVE-2026-109618/109619) Emergency Response Plan

1. PHP2Shell Summary

Due to a vulnerability in the PHP engine itself, you can execute remote code on the server or read process memory without authentication. The issue is affected solely by the PHP version, regardless of the application code. A PoC demonstration video and patched binaries were leaked prior to the official release, and PoCs based on this are spreading rapidly. As the Xint team has finalized the attack code, we believe it is only a matter of time before other attackers create identical code; therefore, you must apply the patch immediately.

2. Methods to identify vulnerable environments

Consider unpatched PHP vulnerable even with its default settings. Changing settings can only reduce a limited number of attack vectors, and new vectors stemming from the same causes may continue to be discovered.

2.1 Vulnerabilities by Server Configuration

This summary is based on official analysis and reproduction results from the Xint team. We will continue to update it with newly confirmed information. (Last updated: 2026-10-21 KST)

O Vulnerable · N/A Not applicable.
- Applications where the initial informants confirmed remote code execution: WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony, WHMCS. This list is for demonstration purposes only, and the vulnerability lies within PHP itself.
- Additionally, a vulnerability that reads process memory, separate from remote code execution, has also been disclosed.

2.2 Configuration Check Script (Attachment: php2shell_check.php)

⚠️

Caution You should not check using the command line (php -v, php -i).

PHP on the command line reads different configuration files than the web service. Even if it appears that action has been taken on the command line, it may not have been applied to the actual web environment, leaving the system in a vulnerable state under the illusion that the issue has been resolved.

• Download: https://gist.github.com/xint-io/14630b00ed2ff90cdde3bb92162e316f

  • 87fd1076386a8c4fd0b3f9477eaf02debca1c36b54c9913e73b76fd18f562e08 php2shell_check.php

1. Replaces the $TOKEN value inside the script with an arbitrary string. If not replaced, it returns only 404.

2. Save it with a difficult-to-guess filename (e.g., chk-8f3a2c.php) and upload it to the same directory as the app entry point (index.php).

3. Access https://<domain>/<filename>.php?k=<TOKEN> in your browser.

4. Once verification is complete, delete it immediately.

If there are multiple sites (vhost, PHP-FPM pool), you must check each one individually. The results can be interpreted as follows.

⚠️

Caution Distribution packages (Ubuntu, RHEL, etc.) sometimes backport only security patches while keeping the version number intact. Even if the script determines that the patches are "not applied," please also check the distribution's security announcements.

3. Measures

A patch is the only fundamental measure. In addition to the disclosed bug, it is known that there are more variants following the same pattern, and the official patch can prevent variant attacks by fixing the root cause itself. Please be aware that the temporary mitigations and WAF below are merely measures to buy time until the patch is applied.

3.1 (P0) Patch Applied

1. Update PHP 8.2 through 8.5 to the revised versions (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35). For update instructions based on operating system and distribution, refer to the official PHP security announcement (Notice 1, Notice 2).

2. Please be sure to restart Apache or PHP-FPM after the update. If you do not restart them, you will continue to use the previous version.

3. The container rebuilds the base image and deploys it.

4. 2.2 Recheck the version with the script.

5. There are no official PHP releases for PHP 8.1 or lower. Please first check if your distribution or LTS support vendor provides security updates. If they do not, the general rule is to upgrade to a supported version; until then, apply the 3.2 temporary mitigation. Since security support for 8.2 also ends at the end of 2026, it is better to upgrade to 8.3 or higher.

Temporary relief (partial relief) until patch 3.2 (P1)

We have added Xint reproduction results to the temporary mitigation proposed by Calif. It blocks only some attack vectors and cannot block variants. It depends on the execution method (SAPI value in 2.2 scripts).

Why do I have to turn off auto_start as well?

Xint team reproduction results, session.auto_start = On. The server is session.upload_progress.enabled was found to be vulnerable even when turned off. This is because the setting automatically starts sessions, so the session processing required for an attack occurs on every request.

⚠️

Caution: memory_limit = -1 removes PHP's memory limit.

A single request can consume all of the server's memory, potentially leading to a Denial of Service (DoS) attack. Be sure to set an OS-level memory limit as well.

• Container: Memory limit (--memory, Kubernetes resources.limits.memory)

• systemd: service unit MemoryMax

• PHP-FPM: pm.max_children Adjust to fit server memory

• Apache: MaxRequestWorkers Adjust to fit server memory

⚠️

Caution: Please check before turning off auto_start.

If you are using session_start() without $_SESSION, session functions such as login or shopping cart stop the moment you turn off auto_start.

# File that uses sessions

grep -rln '\$_SESSION' /var/www

# File that directly calls session_start()

grep -rln 'session_start' /var/www

If in common include files (config, header, etc.) session_start() already exists, you can turn off auto_start immediately. If not, at the beginning of the common include file session_start(); Insert it, then change auto_start to 0. After changing it, be sure to test the login and session functions. If the server is turned off by default (off), there is nothing else to do.ob_start(); When using a series you need to make corrections by referring to: https://www.php.net/manual/en/function.session-start.php 

session.upload_progress.enabled = 0

If you apply this, the feature that queries the server to display the upload progress may not work. The way the browser (JavaScript) calculates the progress is unaffected.

Application Location

• If possible php_admin_value / php_admin_flag Insert it as follows. In the application code ini_set() If you lower memory_limit again, the mitigation effect disappears, but admin settings cannot be changed in the code.

• Virtual hosting If you are unable to change it directly, or if the script result remains unchanged even after making changes, it means the hosting provider has blocked configuration modifications. Please request a PHP update schedule and the application of a temporary relaxation from your hosting provider.

• After applying, please check again with the 2.2 script.

3.3 (P1) WAF/Web Server Configuration (Temporary Relaxation)

WAF

• First, check the managed rules provided by your WAF or CDN provider. Major vendors such as Cloudflare, Akamai, and AWS have prepared rules for this vulnerability in advance. You must verify through vendor announcements or the admin console whether these rules have actually been applied to your account.

• If you create your own rules, block the following patterns.

  • In the request body PHP_SESSION_UPLOAD_PROGRESS Block if the string is present. On the server session.upload_progress.name If you changed it, create a rule with the changed name.

  • Deeply nested square bracket field names(a[b][c][d]...)

  • filename=""A multipart request containing a large amount of empty upload parts.

⚠️

Caution It is very easy to evade WAF detection using methods such as charset modification, large amounts of data, and RFC 2231/5987 encoding. Rules alone cannot completely block this, so please consider them a temporary measure to use until a patch is applied.

Apache

• Apache passes chunked HTTP/1.1 or HTTP/2 multipart requests without length information to PHP as is. PHP's post_max_size Since the inspection only checks the declared length, it can be bypassed via this path. LimitRequestBody Please allow the request body size to be only as much as the web service requires.

Nginx + PHP-FPM

• Client_max_body_size Set this to the minimum value required by the web service, and only for paths requiring large uploads location Increase by unit.

• Fastcgi_request_buffering It maintains the default value (on).

3.4 Verification of Infringement

Verify this immediately after applying the patch. This vulnerability operates at a lower level of the application, so it leaves almost no trace in the application logs. You must check the PHP and web server logs. Traces remain even if the attack fails.

① Abnormal memory overflow log

For normal memory overflow errors, the PHP filename and line number are printed. in Unknown on line 0 If it is marked as such, it likely indicates an attack because it occurred before the request was processed. This mainly occurs in mod_php attacks.

grep -cE 'Allowed memory size of [0-9]+ bytes exhausted.*in Unknown on line 0' \

/var/log/php_errors.log /var/log/apache2/error.log /var/log/httpd/error_log \

  /var/log/php*-fpm.log 2>/dev/null

In PHP-FPM attacks, the actual filename is printed because a memory overflow occurs while the application is running. Session or unserialize() If memory overflows occur repeatedly in related locations, suspect them together.

② Crash and Worker Abnormal Termination Logs

grep -E "Segmentation fault|signal 11|SIGSEGV" \   /var/log/apache2/error.log /var/log/httpd/error_log /var/log/php*-fpm.log 2>/dev/null

dmesg | grep -i segfault | grep -E "php|httpd|apache2"

③ Signs of abnormal requests or responses

• If memory out errors or HTTP 500s occur repeatedly immediately after an abnormal multipart request

• If the PHPSESSID cookie in the response is abnormally long or has a corrupted value (a trace of a memory exposure attack. Check in WAF or proxy logs)

• Case of a surge in PHP worker restarts of unknown cause

④ Abnormally large session file

The session save path is of the 2.2 script. Session.save_path Write the value.

find <session save path> -name 'sess_*' -size +1M -exec ls -lh {} \;

⚠️

The session file is 24 minutes by default (session.gc_maxlifetime = 1440 It becomes a target for cleanup after seconds. It is difficult to verify using this method if time passes after an attack, so please check as soon as possible.

⑤ Traces after infringement

# Processes running under the web server account (Account name should match the environment: www-data, apache, nginx, etc.)

ps -u www-data -o pid,ppid,lstart,cmd

# PHP files changed within the last 3 days (check for web shells, tampering)

find /var/www -name '*.php' -mtime -3 -ls

# External connections of the web server and PHP processes

ss -tnp | grep -E "php|httpd|apache2|nginx"

If traces are found, isolate the server from the external internet and preserve the logs. There is a possibility of memory exposure. Secret information such as DB passwords, API keys, and session/encryption keys is also replaced. Please contact Xint after that.

4. Reference

• PHP Official Security Notice: https://www.php.net/archive/2026.php#2026-10-21-5

• PHP Foundation Description: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

• GitHub Security Advisory CVE-2026-109618: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

• GitHub Security Advisory CVE-2026-109619: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

• Calif Technical Analysis: https://calif.io/php2shell/

• Wiz Technology Analysis: https://www.wiz.io/blog/php2shell-php-rce

• OpenAI Announces Joint Response: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/