Critical PHP Vulnerability "PHP2Shell": Impact and Countermeasures | RCE Verification of ARTEX×GLM App

PHP2Shell is the collective name for two critical vulnerabilities found in PHP core's request processing that lead to unauthenticated remote code execution (RCE). On October 21, 2026, emergency fixed versions addressing CVE-2026-109618 and CVE-2026-109619 were released. Operators of web systems using PHP are required to check their usage environment and promptly apply the fixes. PHP's official announcement

On the other hand, PHP applications also have issues that can lead to RCE through flaws in input handling and upload features. We used ARTEX and GLM to verify command injection and upload-based RCE in a custom-built PHP application. From task creation to finding registration, the measured times in the DB were 104 seconds and 305 seconds respectively.

This ARTEX verification targeted weaknesses intentionally embedded in the application side. It does not include reproduction of PHP2Shell itself. Emergency updates to PHP core and fixes on the application side must each be addressed according to their respective causes.

The two PHP2Shell vulnerabilities relate to memory management and request processing inside PHP. A path from unauthenticated HTTP requests to code execution has been confirmed, and both have a CVSS v4.0 severity of 9.2 (Critical).

The main difference between the two lies in the circumstances under which the invalid state arises.

A worker is a process on the server side that handles requests. The latter relates to state management when a single process handles multiple requests in sequence. Both have been reported as issues that can independently lead to RCE.

In particular, with Apache's mod_php, request parsing that occurs before the application's processing begins also serves as an attack entry point. PHP-FPM is also affected, and for the issue involving lingering stale internal state, an RCE path via FPM has been officially demonstrated as well. PHP official scope of impact

The impact extends to PHP environments that process web requests, including CGI and runtimes embedded in products. The actual conditions required for a successful attack vary depending on the PHP version, configuration, and worker behavior, but a response is also needed for configurations other than mod_php. CERT-EU advisory

IPA also issued a request on October 21 for organizations to identify systems in use and promptly prepare to apply the fixed versions. IPA's advance notice

The priority is applying the fix to the PHP actually used by your service. Do not wait for AI verification results—check the fix information for the OS, hosting, and products you are using.

The fixed versions released by PHP officially on October 21 cover the following four series. Update to the fixed version corresponding to your series in use, or to a later version that includes the fix.

Some distributors backport the fix into existing versions. Do not judge by version number alone—check the fixed package information provided by your distributor. PHP bundled within containers or products is not replaced simply by updating the host-side PHP, so it requires separate handling. NCSC-NL response information

Regular official support for PHP 8.1 and earlier has ended, but this time PHP's security team also provided limited source-level fixes for 7.4, 8.0, and 8.1. This is not a resumption of regular support, so while checking your distributor's response, proceed with migrating to a series that is still under support. PHP official guidance for older series

The workaround session.upload_progress.enabled=Off, which has been proposed, is a setting that mitigates some of the confirmed attack paths. It must be changed in a location that takes effect before request parsing, and all workers need to be restarted. However, this does not resolve the two vulnerabilities as a whole.

The permanent solution is applying the fix. If you cannot apply it immediately, consult with your service provider and decide on interim measures, including reducing exposure or temporarily suspending the service. CERT-EU mitigations and constraints

In our verification, we used a PHP training application with known weaknesses deliberately built into the application side, and confirmed server-side execution through two types of RCE. One finding was registered for each.

RCE refers to a state in which, through external manipulation, code or commands that are not normally permitted can be executed on the server. While the resulting RCE is common between PHP2Shell and this training application, the layer causing it differs. The PHP core issue requires a runtime update, while the training application's issue requires fixes to the application implementation and server configuration.

For the two training applications, we varied the information specified and the scope that the AI explored.

The time required is the value measured for one successful instance in each training application.

ARTEX is a penetration testing platform in which an LLM-powered agent operates tools, investigates targets, and reports results. This time, we used a verification configuration combined with GLM, examining the application's behavior based on HTTP requests and responses. Reading the internal code of the target application was not assumed as a prerequisite.

The first training application was a diagnostic feature that did not safely pass user input to OS commands. The second was a PHP application with screens such as image upload and image listing, containing weaknesses in file type restrictions and the execution settings of the storage destination. We progressed from tests that varied a single input to tests that chained multiple operations together.

The target was limited to a local verification environment managed by our company. Placing ARTEX and the target application locally, and making communication with the inference model fully offline, are separate configuration and verification matters.

A person prepared the app and environment in advance and manually confirmed that the intended weakness was reproducible. For the second training material, the verification files used for manual confirmation were deleted, restoring the state so that existing files would not affect the AI's results, before specifying the target and verification goal.

ARTEX was responsible for investigating the web app, trying candidate operations, checking responses and execution results, and registering findings. For the second one, it proceeded without being told the location of the upload function or the specific bypass method.

In the first training material, modifying the input to the diagnostic function returned OS command output in addition to the normal response. This is the result of command execution—not originally present in the app—being achieved through the specified input field.

With normal input, only the communication check result expected by the app was returned. When the input was changed, user information from a process run on the server appeared in the response. According to the record, the response size also changed from 251 bytes to 305 bytes.

The evidence of success is not the 54-byte increase itself, but the fact that output corresponding to the verification command was added. Response size or HTTP status alone cannot distinguish this from an error display or a reflected input string.

The AI's report is evaluated by comparing the requests and responses between normal and verification cases. Together with the verifier's prior manual confirmation, the ability to correlate the change in input with the server-side output is what supports the demonstration in this training material.

The returned user information shows that the command was executed with the privileges of the user running the web app. It is not a result confirming the acquisition of administrator privileges or a breach outside the container.

OS command injection is a problem in which the meaning of the command to be executed is altered by external input. The impact varies depending on the privileges of that process and the information it can access. CWE-78

When evaluating in a real service, in addition to execution privileges, one should check the data that can be referenced and the functions that can be operated. The results obtained in this training material should also be understood based on the processes that could be executed and their privileges.

In the second one, ARTEX found the upload function and confirmed RCE by combining a flaw in file restrictions with the execution settings of the storage destination. Starting from a state where no specific vulnerable point was disclosed, it proceeded to execution confirmation by connecting multiple operations.

For the teaching material, we prepared multiple entry points, including the top page, upload, image list, and guide pages. What we told ARTEX was the goal of investigating the target host and RCE; we did not disclose the location of the vulnerable feature or how to bypass its restrictions.

ARTEX examined the site and reached the upload feature. It then changed file types to check the differences between acceptance and rejection, and also accessed the saved files afterward. When a specific extension was rejected, it investigated how other names or extensions were handled, exploring the path leading to execution.

The achievement of this teaching material lies in the fact that it proceeded without being told the specific weakness. However, the target and the goal of RCE were specified; this was not a test in which any kind of problem could be freely searched for across the entire application.

In the teaching material, against the restriction that rejected certain extensions, a file with a different name ended up being saved. Furthermore, the destination where it was saved was configured so that the web server processed the file as PHP code. These two conditions connected, leading from upload to execution.

Accepting a file and executing its contents as code are separate stages. The names that get accepted and the formats that get executed depend on the server configuration and the destination directory. The behavior of this teaching material cannot simply be applied to all PHP environments as-is.

CWE-434 also addresses the problem of dangerous file types being uploaded and then processed by the environment. Restrictions must not be completed solely at the input field; they need to be verified as a path covering storage, delivery, and execution.

ARTEX accessed the uploaded verification code and confirmed the output of a command that returns information such as the executing user. It also compared this with the case of uploading a normal image, noting that the same output was not obtained.

This record allows us to trace the flow of file acceptance, access to the storage destination, and code execution on the server side. It is the result of confirming not just the stage where "the file was saved," but also how it was processed afterward.

The report also includes the reproduction conditions, impact, and countermeasures. During review, we check whether there is communication and output corresponding to what is described in the report, and use this to lead to fixing the underlying configuration or implementation.

For the two teaching materials, findings were registered in a short amount of time. To evaluate practical usefulness, in addition to the time required, it is necessary to also check the records of operations involving writes and of the review process.

What was used to confirm execution was a command that displays information such as the executing user and the environment. Operations aimed at data deletion or service disruption were not necessary for this confirmation.

On the other hand, in the test via upload, verification code was saved to the target. Even though the confirmation command was for reference purposes, the test as a whole involved writing a file.

When conducting similar verification, one should decide in advance where and which files may be placed, as well as how to delete or reset them afterward. If verification files from a previous test remain, it becomes unclear in the next attempt whether a new weakness was found or whether the existing file was simply used.

In the first test, there were 0 blocks and 0 rejections. In the second, there is 1 record of a review timing out due to a malformation in the response format of the model that judges operations.

This differs from a record of rejection due to a judgment that an operation was dangerous; it is an incident in which the judgment process did not complete normally. According to the verification records, the process proceeded to execution confirmation without relaxing the rules, but the two tests together cannot be evaluated as "zero issues in review."

During operation, we also check which operations were stopped or continued when judgment failed. Whether a vulnerability was discovered and whether the operation review functioned normally must each be judged from their respective records.

Measuring the time from task creation in the DB to finding registration, the command injection material took 104 seconds, and the upload-based material took 305 seconds. This does not include the time for app creation, environment setup, manual verification, or initialization. These are values measured from one successful instance for each material.

In the second case as well, where no specific weakness was indicated in advance, the process reached from exploration to execution confirmation and registration in about 5 minutes. The verifier reported that exploration proceeded without the idle state in which processing appeared to stop, as seen previously. This is not a result of measuring CPU or GPU utilization.

In a separate past run, there is a record of it taking about 34 minutes to reach the first finding. However, since this is not a comparison with matched target, instructions, settings, and measurement starting point, we cannot calculate a performance improvement rate for GLM or a speedup factor for ARTEX. This result is an instance in which, under conditions where the connection to the target and the goal were set up, verification was obtained in a short time.

For the next comparison, it would be effective to repeat trials with the same initial state and instructions, measuring the variation in success rate and time required. By separately recording the time of the first verification and the final report, as well as the time for human preparation and review, it becomes possible to evaluate the AI's processing time and the overall workload of the task.

The weaknesses identified in this material require fixes to the process that passes external input to OS commands, and to the execution settings for uploaded files. Along with updating the PHP core, the application-side pathways will also be inspected.

First, we check whether the same processing can be implemented without calling OS commands. OWASP's defense guidelines also prioritize avoiding direct command calls when a library or API can be used as a substitute.

If it is necessary, we reconsider the design that concatenates input as a string, and use a mechanism that separates the program to be executed from its arguments. We also restrict values that users can specify according to their intended use, and check whether they could be interpreted as unintended arguments.

After the fix, we confirm that no improper processing occurs with input that reproduces the issue, and that normal functionality still works. Minimizing execution privileges also helps limit damage, but this is done together with the fix to the input handling.

For uploads, only the formats required for business use are allowed, and both the extension and the content are checked. As a basic rule, the Content-Type sent by the user is not trusted alone, and the filename for storage is generated on the application side. OWASP's upload guidelines

Settings that prevent scripts from being executed at the storage location are also necessary. If possible, files should be stored outside the web-accessible area, with the delivery method also factored into the design. In a configuration like this material's, where execution after storage is possible, simply rejecting a single extension is not sufficient as a countermeasure.

After the fix, in addition to confirming that dangerous formats are not accepted, we confirm that even if an unexpected file is placed, it is not executed as code. We also test that necessary functions, such as normal image display, still work. This verification record does not include a comparison test after the fix.

We organize the points that are easy to confuse between the application of fixes to PHP core itself and this app verification.

The fix for PHP2Shell addresses two issues in PHP core itself. It does not automatically fix dangerous input to OS commands or code execution at the upload destination, as seen in this teaching material. After updating PHP, you also need to fix the app's implementation and server configuration.

What was demonstrated this time were command injection and RCE via upload. The 104 seconds and 305 seconds are records for these two teaching materials, and are not the reproduction times for CVE-2026-109618 / CVE-2026-109619.

To evaluate the ability to respond to PHP2Shell, a separate verification is needed in an isolated environment that meets the impact conditions of the relevant CVE. Evaluation should be based on evidence that can identify the cause, together with comparison results showing that the issue does not occur in the fixed version.

For responding to PHP2Shell, the priority is to check the PHP version in use and the fix information from the distributor, and promptly apply the fixed runtime or package. There is no need to wait for the app's inspection results.

In this teaching material using ARTEX and GLM, command injection and RCE via upload on the app side were confirmed, taking 104 seconds and 305 seconds respectively from task creation to finding registration. It is an achievement that multi-stage verification could be carried out without disclosing the specific vulnerable location. Please evaluate the demonstration based on comparisons with the normal case and the operation logs, and proceed with both the PHP core update and the app-side fixes.

Reference materials (confirmed on: October 22, 2026)

• Our company's own verification records of the self-made PHP teaching material, and the measured DB values from task creation to finding registration. The success examples, time required, and operation review results for each method are based on these records.
• PHP official: Emergency fix and security advisory of October 21, 2026
• PHP official: Technical information on CVE-2026-109618
• PHP official: Technical information on CVE-2026-109619
• IPA: Request for advance preparation regarding PHP vulnerabilities
• CERT-EU: Advisory on critical PHP vulnerabilities
• Netherlands NCSC: PHP2Shell response information
• CWE-78: OS Command Injection
• CWE-434: Unrestricted Upload of File with Dangerous Type
• OWASP: OS Command Injection Defense Cheat Sheet
• OWASP: File Upload Cheat Sheet