> ## Documentation Index > Fetch the complete documentation index at: https://developer.upsun.com/llms.txt > Use this file to discover all available pages before exploring further. # Critical PHP security patches: Upsun rollout and what to check > PHP fixed two critical vulnerabilities on October 21, 2026. See the patched versions, how Upsun is rolling them out, and what to check in your projects. > [!NOTE] > > **In short:** > > * If your app uses Upsun's `php` runtime image on PHP 7.4 or later, you don't need to do anything. > Upsun is automatically redeploying these apps with the patched versions. > PHP 8.2 and later are patched first. > PHP 7.4, 8.0, and 8.1 follow later, and edge mitigations protect them until then. > Your site goes offline briefly while its environment redeploys. > Follow the rollout of the patched images on the [status page](https://status.upsun.com/incidents/2cdvc2ctv5jwb). > > * If your app runs PHP 7.3 or earlier, or uses the composable image, see [What you need to do](#what-you-need-to-do). On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. These versions fix two critical vulnerabilities that can allow unauthenticated remote code execution (RCE). For details, see the [PHP security advisory](https://www.php.net/index.php#2026-10-21-5) and the [advance notice](https://www.php.net/archive/2026.php#2026-10-20-1) on php.net. Upsun applied mitigations before the release and is now rolling out the patched versions. ## What was fixed The release addresses two vulnerabilities, both rated **9.2 (critical)** on the CVSS v4.0 scale. CVSS (Common Vulnerability Scoring System) rates the severity of vulnerabilities from 0 to 10, and scores of 9.0 or above are critical. | CVE | Description | CVSS v4.0 | | - | - | - | | CVE-2026-109618 ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)) | RCE via out-of-memory (OOM) corruption. OOM handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat the invalid data as valid. | 9.2 | | CVE-2026-109619 ([GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)) | RCE via stale global state. Request-owned internal state can survive after its memory is freed, and a later request handled by the same worker may use it. | 9.2 | The researchers who discovered the vulnerabilities call the pair "PHP2Shell". For their overview, see [php2shell.com](https://www.php2shell.com/). According to the PHP project, every PHP installation that serves web requests is at risk. This includes PHP-FPM, Apache with mod\_php, php-cgi, FrankenPHP, and LiteSpeed. The risk is highest for mod\_php, where an unauthenticated request can trigger the attack before any application code runs. ### How the vulnerabilities work Both vulnerabilities are memory-safety bugs in PHP itself, not in application code. Your app can be affected even if its own code is secure. * **CVE-2026-109618:** When PHP runs out of memory, it jumps straight out of the current operation. During request startup, for example while PHP parses the request body, some request memory is reachable before it's fully initialized. If memory runs out at that moment, PHP's cleanup code later treats the half-initialized data as valid. The fix replaces the immediate jump with a graceful out-of-memory error at a safe point. * **CVE-2026-109619:** PHP workers handle many requests in a row and keep some global state between them. If a request ends abruptly, for example with a fatal error, that state can still point to memory that's already been freed. Some operations at the start of the next request read this stale state before PHP resets it. The fix resets all global state before those operations run. The researchers used WordPress, Drupal, and Joomla to demonstrate the attacks, and apps built on them are affected like any other PHP app. Because the flaw is in PHP, updating your CMS, framework, or plugins doesn't fix it: only a patched PHP version does. The GitHub advisories linked in the table have the full technical details. ## Affected and patched versions The following table maps each PHP branch available on Upsun to its patched version: | PHP branch | Status on Upsun | Last vulnerable version | Patched version | | - | - | - | - | | 8.5 | [Supported](/docs/languages/php#supported-versions) | 8.5.11 | 8.5.12 | | 8.4 | [Supported](/docs/languages/php#supported-versions) | 8.4.26 | 8.4.27 | | 8.3 | [Deprecated](/docs/languages/php#deprecated-versions) | 8.3.35 | 8.3.36 | | 8.2 | [Deprecated](/docs/languages/php#deprecated-versions) | 8.2.34 | 8.2.35 | The PHP project released official patched versions for PHP 8.2 through 8.5. Upsun is rolling out the fixes for PHP 8.2 and later now. Fixes for PHP 7.4, 8.0, and 8.1 follow at a later stage (see [Retired PHP versions](#retired-php-versions)). ### Retired PHP versions PHP 8.1 and earlier are end of life and [retired on Upsun](/docs/languages/php#retired-versions). PHP 7.4, 8.0, and 8.1 are affected and no longer receive official releases. Instead, the PHP security team published minimal source backports for them. Upsun will use these backports to provide patched images for PHP 7.4, 8.0, and 8.1 at a later stage. Until then, Upsun's edge mitigations protect apps on these versions, but they don't replace a patched runtime. PHP 7.3 and earlier don't have backports, so upgrading is the only fix. **If you run PHP 7.3 or earlier,** upgrade to PHP 8.5 now. To upgrade, change the `type` of your app in your configuration file: ## How Upsun responded Upsun was aware of the vulnerabilities before the public announcement and responded on two fronts. ### Before the release: mitigation at the edge The edge is the network layer that handles traffic before it reaches your app. On Upsun, Upsun's own edge layer sits in front of every cluster and site. Some projects also route traffic through a [CDN](/docs/domains/cdn) such as Fastly, which adds another layer in front of the app. Self-service projects don't include a CDN by default. Mitigations on Upsun's edge layer block known attack patterns for every customer. Where a CDN such as Fastly is also in place, its mitigations add further protection. They work as a virtual patch: they protect your apps before PHP itself is upgraded. They also stay in place as an extra layer of protection on top of the patched PHP images. ### After the release: patched PHP images As soon as the PHP project published the patched versions, Upsun started building patched PHP images. Images for PHP 8.2 and later come first, because the PHP project released official versions for them. Images for PHP 7.4, 8.0, and 8.1 follow, based on the PHP project's source backports. Upsun automatically redeploys every environment that uses a `php` runtime image, project by project and region by region. Your site goes offline briefly while its environment redeploys. The redeploy doesn't change your code or configuration. ## What you need to do If your app uses a `php` runtime image on PHP 7.4 or later, you don't need to do anything to get the patched versions. Upsun redeploys your environments automatically. Check the [status page incident](https://status.upsun.com/incidents/2cdvc2ctv5jwb) to see when Upsun redeploys your project or region. If your app runs PHP 7.3 or earlier, see [Retired PHP versions](#retired-php-versions): upgrading is the only fix. If your app uses the composable image, see [If you use the composable image](#if-you-use-the-composable-image). ### Check your PHP version After Upsun redeploys your environment, you can confirm the specific PHP version your app runs: ```bash theme={null} upsun ssh --environment main --app myapp -- php -v ``` Replace `main` with your environment name and `myapp` with your app name. If your project has a single app, you can omit `--app`. The output should show a patched version from the [table above](#affected-and-patched-versions). If it still shows a vulnerable version, Upsun might not have redeployed your region yet. If you're unsure, [contact Upsun support](/docs/core-concepts/get-support). ### Optional: disable session upload progress For an extra layer of protection, disable the `session.upload_progress.enabled` PHP setting. According to the PHP project, this blocks the confirmed session-based attack paths for CVE-2026-109619, but not other variants. It reduces exposure but doesn't replace the patched versions. This setting is rarely needed: it only powers upload progress bars that rely on PHP sessions. To apply it across all environments in your project, use the Upsun CLI: ```bash theme={null} upsun variable:create --level project --name php:session.upload_progress.enabled --value "Off" ``` Project variables take effect after a [redeploy](/docs/troubleshooting/general#force-a-redeploy). Alternatively, set it in a custom `php.ini` file at your app root: ```ini {filename="php.ini"} theme={null} session.upload_progress.enabled = Off ``` Don't use `ini_set()` or a `.user.ini` file for this setting. They apply too late in the request to block the attack. If your app runs PHP 8.5, also set `fatal_error_backtraces` to `Off` the same way, for example: ```bash theme={null} upsun variable:create --level project --name php:fatal_error_backtraces --value "Off" ``` This blocks the confirmed fatal error backtrace path only. For more information, see how to [customize PHP settings](/docs/languages/php#customize-php-settings). For the complete list of interim measures, see the [PHP security advisory](https://www.php.net/index.php#2026-10-21-5). ### If you use the composable image If your app uses the [composable image](/docs/languages/php#modify-your-php-runtime-when-using-the-composable-image), PHP comes from the Nix channel set in your configuration. Upsun is updating PHP in the supported Nix channels with the patched versions. Until then, [disable session upload progress](#optional-disable-session-upload-progress) as an interim measure. ### Outside Upsun Upgrade PHP to the patched versions anywhere else you run it, including: * Local development machines * Docker images * CI pipelines Linux distributions and long-term support (LTS) vendors received the patches in advance, so check your vendor for updated packages. If you install PHP from `rpms.remirepo.net`, the PHP project recommends switching to distribution packages or building from source. That repository won't have updates on October 21, 2026. ## Acknowledgments Upsun thanks the researchers who discovered and responsibly disclosed these vulnerabilities: * **Wiz Research:** Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz * **OpenAI Codex Security:** Amy Burnett * **Calif:** Ryan A. Thanks also to the PHP security team for coordinating the disclosure and shipping fixes, including backports for end-of-life versions, and to the industry partners who helped prepare mitigations and guidance. ## Questions If you have questions about your project, [contact Upsun support](/docs/core-concepts/get-support). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.