> ## Documentation Index > Fetch the complete documentation index at: https://docs.sevalla.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > These are the docs for Sevalla, a platform for deploying applications, databases, static sites, object storage and load balancers. The dashboard is at https://app.sevalla.com. > Bold text in steps is an exact dashboard label. > To act on a Sevalla account, prefer the Sevalla MCP server (https://mcp.sevalla.com/mcp, see https://docs.sevalla.com/ai-agents/overview.md), then the Sevalla CLI (https://docs.sevalla.com/developer-tools/cli.md), then the REST API (https://api-docs.sevalla.com, OpenAPI spec at https://api.sevalla.com/v3/openapi.json). > Every page index is at https://docs.sevalla.com/llms.txt. # Protect PHP applications from CVE-2026-109618 and CVE-2026-109619 > Protect a PHP application from CVE-2026-109618 and CVE-2026-109619 with a quick PHP settings fix for every build strategy, then upgrade to the patched PHP release. CVE-2026-109618 and CVE-2026-109619 are two vulnerabilities in PHP itself that let an attacker run code on a server with a crafted HTTP request, without signing in. PHP rates both 9.2 (critical) and fixed them in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released Oct 21, 2026. Every PHP application on Sevalla that runs an older release is affected, whatever its framework or build strategy. Last updated Oct 21, 2026, 16:56 UTC. ## Apply the quick fix now Applications built with Buildpacks, or with a Dockerfile based on the official `php` images, can upgrade right away. See [Buildpacks](#buildpacks) and [Dockerfile](#dockerfile). For every other PHP application, the quick fix is three PHP settings. Add them now: it takes one deployment and no changes to your code, and file uploads, form posts and sessions keep working. The settings make the attack harder but don't fully fix it, so also [upgrade PHP](#upgrade-to-the-patched-php-release) when the patched release reaches your build. Pick the build strategy of the application. It's in the **Build strategy** section of the application's **Settings** tab. **Nixpacks** **1. Add the settings file** Add a `php-conf.d` folder to the build path, with this `php.ini` file in it: ```ini php-conf.d/php.ini theme={"theme":{"light":"github-dark-default","dark":"github-dark-default"}} session.upload_progress.enabled = 0 memory_limit = -1 fatal_error_backtraces = 0 ``` **2. Point PHP at it** Add the [environment variable](/applications/environment-variables) `PHPRC` with the value `/app/php-conf.d`, with **Available during runtime** and **Available during buildtime** both selected. **3. Deploy** [Deploy](/applications/deployments) the application. In the **Web terminal** tab, `php -i | grep -E "upload_progress|memory_limit"` prints `memory_limit => -1 => -1` and `session.upload_progress.enabled => Off => Off`. Use `PHPRC`, not `PHP_INI_SCAN_DIR`. Nixpacks loads PHP's extensions through `PHP_INI_SCAN_DIR`, so setting it removes them and the build fails with `The iconv OR mbstring extension is required and both are missing.` **Railpack** **1. Add the settings file** Add a `php-conf.d` folder to the build path, with this `php.ini` file in it: ```ini php-conf.d/php.ini theme={"theme":{"light":"github-dark-default","dark":"github-dark-default"}} session.upload_progress.enabled = 0 memory_limit = -1 fatal_error_backtraces = 0 ``` **2. Point PHP at it** Add the [environment variable](/applications/environment-variables) `PHPRC` with the value `/app/php-conf.d`, with **Available during runtime** and **Available during buildtime** both selected. **3. Deploy** [Deploy](/applications/deployments) the application. In the **Web terminal** tab, `php -i | grep -E "upload_progress|memory_limit"` prints `memory_limit => -1 => -1` and `session.upload_progress.enabled => Off => Off`. Railpack's own `php.ini` still loads, so its other settings, such as its upload limits, stay as they are. Don't put the settings in a `php.ini` at the root of the build path: Railpack uses that file in place of its own `php.ini`. **Buildpacks** Buildpacks applications don't need the quick fix. Heroku has published the patched PHP releases, so a new deployment upgrades PHP: [deploy the application again](#buildpacks). **Dockerfile** Dockerfile applications based on the official `php` images don't need the quick fix. Docker Hub has published the patched images, so [update the image](#dockerfile): deploy again, or change the `FROM` line if it pins an older release. If the image is based on `dunglas/frankenphp`, which has no patched images yet, add the settings until it does: **1. Add the settings file** Add this `php-security.ini` file to the Docker context: ```ini php-security.ini theme={"theme":{"light":"github-dark-default","dark":"github-dark-default"}} session.upload_progress.enabled = 0 memory_limit = -1 fatal_error_backtraces = 0 ``` **2. Copy it into the image** Add this line to the Dockerfile, after the `FROM` line of the image that runs the application: ```dockerfile Dockerfile theme={"theme":{"light":"github-dark-default","dark":"github-dark-default"}} COPY php-security.ini "$PHP_INI_DIR/conf.d/zz-security.ini" ``` **3. Deploy** [Deploy](/applications/deployments) the application. In the **Web terminal** tab, `php -i | grep -E "upload_progress|memory_limit"` prints `memory_limit => -1 => -1` and `session.upload_progress.enabled => Off => Off`. ## Check whether your application is affected In the application's **Web terminal** tab, run `php -v`. The application is affected if the version is older than the fixed release of its branch: | PHP branch | Fixed in | | - | - | | 8.5 | 8.5.12 | | 8.4 | 8.4.27 | | 8.3 | 8.3.36 | | 8.2 | 8.2.35 | | 8.1 and older | No fix. These branches are end of life: upgrade to PHP 8.2 or later. | See [Web terminal](/applications/web-terminal) to open a shell in a running instance. ## What the quick fix changes | Setting | What it does | Side effect | | - | - | - | | `session.upload_progress.enabled = 0` | Blocks the session path used in the demonstrated attack on CVE-2026-109619 | PHP's session-based upload progress stops working. Progress bars that track the upload in the browser keep working. | | `memory_limit = -1` | Removes PHP's memory limit, which CVE-2026-109618 relies on | One request can use all of its instance's memory. An instance that runs out of memory is stopped (exit code `137`) and Sevalla starts it again. | | `fatal_error_backtraces = 0` | Turns off the backtraces that CVE-2026-109619 uses on PHP 8.5 | Fatal errors no longer include a backtrace. PHP 8.4 and older ignore this line. | The settings don't change upload size limits. PHP's advisory asks for them in `php.ini`, the PHP-FPM pool or the web server configuration, which is what the quick fix uses. Don't set them with `ini_set()` or a `.user.ini` file instead, and don't let your code set `memory_limit` back to a number. If you pass PHP settings per request (`php_value` or `php_flag` in `.htaccess`, or `fastcgi_param PHP_VALUE` in an nginx configuration), move them to `php.ini`. Sevalla's Cloudflare network passes these requests to your application like any other request, so the settings must be in the application. > [!WARNING] > > The quick fix makes the attack harder but doesn't fully fix it. Upgrade to the patched PHP release as soon as your build can use it. ## Upgrade to the patched PHP release Upgrading PHP is the only complete fix. Keep the quick fix in place until the upgrade is deployed. | Build strategy | Patched PHP available | How to upgrade | | - | - | - | | [Nixpacks](/applications/builds/nixpacks) | No: each Nixpacks version installs PHP from a fixed, older set of packages | [Not available yet](#nixpacks) | | [Railpack](/applications/builds/railpack) | Not yet: FrankenPHP has no `php8.5.12`, `php8.4.27`, `php8.3.36` or `php8.2.35` images | [Deploy again](#railpack) when the image is published | | [Buildpacks](/applications/builds/buildpacks) (`heroku/builder:22`) | Yes: Heroku installs 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | [Deploy again](#buildpacks) | | [Dockerfile](/applications/builds/dockerfile) with the official `php` images | Yes: Docker Hub has the `8.5.12`, `8.4.27`, `8.3.36` and `8.2.35` images, and moving tags such as `php:8.4-apache` point to them | [Deploy again or update the image](#dockerfile) | Sevalla updates this table when patched builds become available. ### Nixpacks Nixpacks installs PHP from a fixed set of packages, so a new deployment doesn't get the patched release. Keep the quick fix in place. This page lists the upgrade steps for Nixpacks when they're available. ### Railpack Railpack picks the newest PHP release that matches `require.php` in `composer.json` and has a `dunglas/frankenphp` image, for example `dunglas/frankenphp:php8.4.26-bookworm` for `"php": "^8.4"`. When FrankenPHP publishes the patched images, deploy again. The **Packages** table at the start of the build log shows the PHP version the build uses, for example `php │ 8.4.27 │ composer.json > require > php (8.4)`, and `php -v` in the **Web terminal** tab prints it. ### Buildpacks Heroku has published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. [Deploy](/applications/deployments) the application again, with no other change: the build installs the newest PHP release that `require.php` in `composer.json` allows, even with the build cache on. The build log lists the installed version, for example `- php (8.5.12)`, and `php -v` in the **Web terminal** tab prints it. * If `require.php` pins an exact older release, such as `"php": "8.4.26"`, change it to a range such as `"^8.4"`, run `composer update --lock`, and commit both files before you deploy. * `heroku/builder:20` doesn't get the patched release: switch the pack builder to `heroku/builder:22` (see [Pack builders](/applications/builds/buildpacks#pack-builders)). * If you applied the earlier quick fix (`fpm_custom.conf`, `-F fpm_custom.conf` and `WEB_CONCURRENCY`), it can stay. To remove it, delete the file, the `-F fpm_custom.conf` option and the `WEB_CONCURRENCY` variable, then deploy. ### Dockerfile Docker Hub has published the patched `php` images (`8.5.12`, `8.4.27`, `8.3.36` and `8.2.35`), and the moving tags point to them. * If the `FROM` line uses a moving tag, such as `FROM php:8.4-apache`, [deploy](/applications/deployments) the application again with no other change. The build looks up the tag on every deployment, even with the build cache on, so it gets the patched image. * If the `FROM` line pins an older release, such as `FROM php:8.4.26-apache`, change it to the patched release of your branch, for example `FROM php:8.4.27-apache`, and deploy. After the deployment, `php -v` in the **Web terminal** tab prints the patched version. If you applied the quick fix (the `php-security.ini` file and its `COPY` line), it can stay. To remove it, delete both and deploy. `dunglas/frankenphp` images get the fix when FrankenPHP publishes new images. ## Check for signs of an attack A new deployment replaces the files in your instances, but not the files on a [disk](/applications/disks). If the application ran an affected PHP release, look for `.php` files on its disks that you didn't add, such as files in an uploads folder. If you find any, delete them, then change the secrets the application can read: [environment variables](/applications/environment-variables), database passwords and API keys. ## More information * [PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements](https://www.php.net/) * [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) (CVE-2026-109618) * [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) (CVE-2026-109619) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.