On October 21, 2026, PHP disclosed two critical vulnerabilities in the language runtime. Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws received a CVSS score of 9.2 and can allow unauthenticated remote code execution on vulnerable servers. Because the problem is in PHP itself, the permanent fix requires updating the runtime.
Azion’s security team built a hotfix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619). It is available on Azion Marketplace as a function you can apply to the Firewall of any application.
The hotfix inspects every request before it reaches your origin and blocks the attack vectors confirmed in the official PHP advisory. It needs no server access and no worker restarts.
Both flaws have a CVSS score of 9.2 and allow unauthenticated remote code execution, before a single line of your application runs. The hotfix closes those paths before the origin and gives your team time to apply the permanent fix: updating PHP.
What the hotfix covers
| Attack vector | Status | How it is mitigated |
|---|---|---|
| CVE-2026-109619 through the session path (upload progress), confirmed by PHP | Mitigated in Firewall | Full block of the PHP_SESSION_UPLOAD_PROGRESS field, including variations and disguises |
| CVE-2026-109618, memory exhaustion while building the request | Mitigated in Firewall | Official PHP limits for body size, fields, multipart parts, headers, and array depth |
Chunked uploads without Content-Length used to bypass limits | Mitigated in Firewall | Measures the real body size |
| Upload progress + LFI → RCE technique (Exploit-DB 50156) | Mitigated in Firewall | Same block on the upload progress field |
| Malformed or unreadable requests | Preventive block | Multipart without a boundary, or an unreadable body, is blocked |
The hotfix is the first line of defense. The permanent fix is still to update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. The update also closes variants of CVE-2026-109619 that start inside the server, such as fatal errors and timeouts.
What we know about the vulnerabilities
PHP2Shell combines two critical vulnerabilities in the PHP runtime, both rated CVSS v4.0 9.2. Specially crafted HTTP requests can exploit memory management flaws to cause downtime, expose data processed by the server, or execute code remotely without authentication.
Before the coordinated disclosure, the CVE identifiers began circulating publicly and a proof of concept video was published by mistake. Cloudflare and Fastly also identified tools and traffic attempting to exploit the flaws in the hours before the advisories were published. These records show malicious activity, but they do not mean every attempt resulted in successful exploitation.
Both vulnerabilities appear when a request is interrupted at a point where PHP’s internal state has not yet been safely initialized or torn down:
| CVE | Name | What happens |
|---|---|---|
| CVE-2026-109618 | RCE through out-of-memory (OOM) corruption | Out-of-memory handling interrupts PHP while the internal request data is only partly initialized. During cleanup, PHP treats that invalid data as valid, which opens a path to code execution. |
| CVE-2026-109619 | RCE through stale global state | Internal request state survives after its memory has been freed. A later request on the same worker can use that state before the normal reset. |
Every installation that serves web requests should be updated, including environments running PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Whether and how the flaws can be exploited depends on the server, the configuration, and the application flow. The risk is considered higher on mod_php, where an unauthenticated RCE path has been demonstrated.
Because the flaws are in the runtime, updating only your application code, framework, or plugins does not fix the problem. The only complete fix is to install a patched PHP version. Firewall controls help reduce exposure to known vectors, but they work as an additional layer of protection.
How the hotfix works
PHP2Shell exploits the moment PHP builds the request, before any application code runs. So Azion’s security team designed the hotfix to stop the malicious request before it reaches PHP.
It runs in Firewall, inspects each request, and makes exactly one decision: allow or block. The algorithm follows six principles.
One decision per request
Each request gets a single answer. Once the hotfix decides, no other decision is applied.
If the analysis ends without an answer for any reason, a safety net applies the default decision of the configured mode.
Cost proportional to risk
Inspection goes from the lightest step to the most complete, and most traffic is decided without opening the body:
- Count headers, query string parameters, and cookies, and measure array depth in names, such as
a[b][c]. Applies to every request. - Allow requests without a body, such as GET, HEAD, and OPTIONS.
- Block based on the declared
Content-Lengthwhen it exceeds the limit. - Allow JSON, XML, and similar types within the size limit, since PHP does not turn them into variables.
- Read the body only for multipart, urlencoded, and uploads with no declared size.
Measure what arrives, not what is declared
An attacker can omit Content-Length and send the body in chunks to bypass limits. In those cases, the hotfix reads a copy of the body and measures the real size, byte by byte. The original content reaches the origin untouched.
Detect the field, not the spelling
The confirmed path for CVE-2026-109619 goes through the PHP_SESSION_UPLOAD_PROGRESS field. The hotfix looks for that name in any multipart field declaration: with double quotes, single quotes, or no quotes, with extra spaces, and in any mix of uppercase and lowercase.
The search covers the entire body, not only the parts a parser would consider valid. That way, differences between parsers do not open a gap.
When in doubt, block
Multipart without a valid boundary, a body that cannot be read, or an unexpected error during analysis all result in a block. The policy is fail-closed: a request the hotfix cannot evaluate does not reach a vulnerable PHP.
Official PHP limits
The default limits follow the recommendations in the official PHP advisory and can be adjusted per application:
| Rule | Default limit | Basis |
|---|---|---|
| Upload body (multipart) | 32 MB | post_max_size = 32M with uploads |
| Body of all other types, including JSON and XML | 8 MB | post_max_size = 8M without uploads |
| Fields in query, cookies, and form | 1,000 | PHP default for max_input_vars |
| Array depth in field names | 32 | Below the PHP default for max_input_nesting_level (64) |
| Parts in a multipart body | 500 | Limit recommended by PHP |
| Request headers | 100 | Limit recommended by PHP |
PHP_SESSION_UPLOAD_PROGRESS field | Full block | Confirmed session path for CVE-2026-109619 |
Each detection records the reason, the related CVE, the measured value against the limit (for example, 501 parts against 500), the IP, the host, and the path. The content sent by the user is not stored.
How to apply the hotfix
The hotfix is available on Azion Marketplace and can be applied to each application’s Firewall in a few minutes. We recommend starting in observation mode, so you can measure its behavior on real traffic before blocking:
- Install the PHP2Shell hotfix from Azion Marketplace.
- Apply the hotfix to the application’s Firewall with a rule that covers every path on the domain (for example, URI starts with
/), not just the home page. - Turn on observation mode and watch detections in Real-Time Events for a few hours.
- If detections show up on legitimate traffic, adjust the limits in the configuration.
- Turn on protection mode to block malicious requests.
| Mode | Behavior |
|---|---|
| Observation | Logs each detection and allows the request |
| Protection (default) | Logs each detection and blocks the request |
Each detection reaches Real-Time Events with the PHP2SHELL tag, the reason, and the related CVE:
| Reason | Meaning | CVE |
|---|---|---|
UPLOAD_PROGRESS_FIELD | PHP_SESSION_UPLOAD_PROGRESS field in the multipart body | CVE-2026-109619 |
BODY_TOO_LARGE_DECLARED | Content-Length above the limit | CVE-2026-109618 |
BODY_TOO_LARGE_ACTUAL | Real body above the limit, for example in chunked uploads | CVE-2026-109618 |
TOO_MANY_HEADERS, TOO_MANY_QUERY_VARS, TOO_MANY_COOKIES, TOO_MANY_BODY_VARS | Count above the limit | CVE-2026-109618 |
TOO_MANY_PARTS | Multipart parts above the limit | CVE-2026-109618 |
NESTING_TOO_DEEP | Array depth above the limit | CVE-2026-109618 |
MULTIPART_NO_BOUNDARY, BODY_READ_ERROR | Malformed or unreadable request | Preventive |
Some legitimate scenarios may need fine-tuning:
- APIs that receive JSON or XML above 8 MB: raise the body limit for other types.
- Uploads above 32 MB, such as videos and backups: raise the upload body limit.
- Admin panels with forms of more than 1,000 fields: raise the field limit.
Update PHP and keep the hotfix on
The safest strategy is defense in depth: update PHP to a fixed version and keep the hotfix applied before, during, and after the update.
| Layer | Action |
|---|---|
| 1. Fix | Update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply the patched package from your distribution. PHP 8.1 and earlier get no official update, but minimal source-code fixes exist for 7.4, 8.0, and 8.1. If a hosting provider manages your PHP, ask them to update it. |
| 2. Firewall (Azion) | Keep the hotfix applied to the Firewall of every application that uses PHP. |
| 3. PHP configuration (CVE-2026-109619) | Set session.upload_progress.enabled=0 in php.ini or in the FPM pool and restart all workers, without using ini_set() or .user.ini. On PHP 8.5, also set fatal_error_backtraces=0. |
| 4. PHP configuration (CVE-2026-109618) | Use a low post_max_size (8M without uploads, 32M with uploads) and limit memory per container or cgroup. |
| 5. Host detection | Alert when php-fpm, php-cgi, httpd, or apache2 start shells, interpreters, or tools such as curl, wget, and nc. |
Azion’s security team keeps evolving its defense mechanisms to respond to new threats, including zero-day attacks.
Install the hotfix from Azion Marketplace or talk to an Azion expert to protect your PHP applications.
Frequently asked questions
Does updating the application code or plugins fix PHP2Shell? No. The flaws are in the PHP runtime, so only a PHP update fixes the problem. The hotfix blocks the confirmed vectors until then.
Does the hotfix replace the PHP update? No. It is the first line of defense. The update also closes variants of CVE-2026-109619 that start inside the server, such as fatal errors and timeouts.
Does the hotfix add latency? The impact is minimal. Inspection goes from the lightest step to the most complete, and requests without a body, or with JSON and XML within the size limit, are allowed without reading the body.
Does the hotfix change the content sent to the origin? No. It reads a copy of the body, and the original content reaches the origin untouched. The logs do not store the content sent by the user.
References
- PHP security advisory, October 21, 2026
- CVE-2026-109618: GHSA-w8hw-w9fx-j79w (PHP Security Advisories)
- CVE-2026-109619: GHSA-6wmf-4rv5-p3rp (PHP Security Advisories)
- Sansec: PHP2Shell
- Exploit-DB 50156: PHP_SESSION_UPLOAD_PROGRESS Session Data Injection
