Protect PHP applications from CVE-2026-109618 and CVE-2026-109619

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.

The Sevalla team redeployed every running and hibernated PHP application that used an affected release, without the build cache and with no change to your code. A hibernated application stays asleep and runs the patched release when it wakes. Suspended applications weren’t redeployed: redeploy one right after you activate it. On the application’s Deployments tab, the Sevalla team’s deployment shows Sevalla team as the person who started it, with the note Important PHP security patch: CVE-2026-109618 and CVE-2026-109619. The team couldn’t redeploy every application: if the deployment failed or is missing, see If the Sevalla team deployment failed. A redeploy doesn’t upgrade a PHP release your code pins (If redeploying does not upgrade PHP) or PHP 8.1 and older (If you cannot upgrade PHP).

Last updated Oct 22, 2026, 15:03 UTC.

Redeploy your application

Redeploy the live deployment without the build cache: the new build installs the patched PHP release, with no change to your code. This works for Nixpacks, Railpack and Buildpacks, and for most Dockerfile builds. Do it for every PHP application.

Open the latest successful deployment

In the sidebar, click Applications, then click the application. On the Overview tab, in Recent deployments, click the most recent deployment with the status Deployed.

The Recent deployments card on the Overview tab, with the most recent Deployed deployment outlined as step 1

Click Redeploy

On the deployment’s page, click Redeploy.

A deployment's page with the Redeploy button outlined as step 2

Skip the build cache

In the Redeploy dialog, select Skip build cache.

Redeploy

Click Redeploy. A new deployment of the same commit starts.

Skip build cache appears only when the application has the build cache turned on. Without the build cache, every build starts from scratch, so a plain redeploy is enough. When the deployment finishes, run php -v in the application’s Web terminal tab. It prints the fixed release of your PHP 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, or add the PHP settings.

If it still prints an older release, see If redeploying does not upgrade PHP.

If the Sevalla team deployment failed

When the Sevalla team deployment fails, the application keeps running its previous deployment, so it still runs the affected PHP release. Open the deployment on the application’s Deployments tab, find the error in its log, fix the cause, then redeploy the application. If the application has no Sevalla team deployment, Sevalla couldn’t read its Git repository. Check the repository in the application’s Source settings and give Sevalla access to it again (GitHub, Bitbucket, GitLab), then redeploy it.

Error in the deployment log	Cause	Fix
`Repository not found` or `could not read Username for 'https://github.com'`	Sevalla can no longer read the repository	Give Sevalla access to the repository again, or update it in the Source settings
`Remote branch <name> not found in upstream origin`	The branch the application deploys no longer exists	Deploy a branch that exists
`404 Not Found` for `deb.debian.org` packages	The Dockerfile builds from an end-of-life image, such as `php:7.4-apache`, whose Debian packages were removed	Build from a supported image, such as `php:8.4-apache`
`affected by security advisories`	The repository has no `composer.lock`, and Composer no longer installs package versions with known security advisories	Update the dependencies and commit `composer.lock`
`Vite requires Node.js version 20.19+ or 22.12+`	The build uses Node.js 18	Add the environment variable `NIXPACKS_NODE_VERSION` with the value `22`, with Available during buildtime selected
`mysql-client has been replaced by mariadb.client`	`nixpacks.toml` installs a Nix package that the patched package set no longer has	Replace `mysql-client` with `mariadb.client` in `nixPkgs`

Check for signs of an attack

A new deployment replaces the files in your instances, but not the files on a disk. 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, database passwords and API keys.

If redeploying does not upgrade PHP

A redeploy keeps the PHP release your code pins. Change the pin, commit it, and deploy the new commit:

Dockerfile: the FROM line pins a full release, such as FROM php:8.4.26-apache. Change it to the patched release of your branch, such as FROM php:8.4.27-apache. Moving tags, such as php:8.4-apache and dunglas/frankenphp:1-php8.4, already point to the patched images.
Railpack and Buildpacks: require.php in composer.json pins an exact release, such as "php": "8.4.26". Change it to a range such as "^8.4" and run composer update --lock, then commit both files.
Buildpacks on heroku/builder:20: this builder doesn’t get the patched releases. Switch the pack builder to heroku/builder:22 (see Pack builders).

If you cannot upgrade PHP

When you can’t upgrade PHP yet, for example on PHP 8.1 or older, add three PHP settings. They make the attack harder but don’t fully fix it, so upgrade PHP as soon as you can. Adding them takes one deployment and no changes to your code.

Nixpacks
Railpack
Buildpacks
Dockerfile

Add the settings file

Add a php-conf.d folder to the build path, with this php.ini file in it:

php-conf.d/php.ini

session.upload_progress.enabled = 0
memory_limit = -1
fatal_error_backtraces = 0

Point PHP at it

Add the environment variable PHPRC with the value /app/php-conf.d, with Available during runtime and Available during buildtime both selected.

Deploy

Deploy 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.

Add the settings file

Add a php-conf.d folder to the build path, with this php.ini file in it:

php-conf.d/php.ini

session.upload_progress.enabled = 0
memory_limit = -1
fatal_error_backtraces = 0

Point PHP at it

Add the environment variable PHPRC with the value /app/php-conf.d, with Available during runtime and Available during buildtime both selected.

Deploy

Deploy 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.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.

Add a PHP-FPM configuration file

Add fpm_custom.conf to the build path. Keep the last line only on PHP 8.5.

fpm_custom.conf

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_flag[fatal_error_backtraces] = off

Load it from the start command

Add -F fpm_custom.conf to the command that starts the web process, before the document root if there is one, for example heroku-php-apache2 -F fpm_custom.conf public/. Put it in the web process’s Custom start command on the Processes tab, or in the web entry of the Procfile when the start command is empty.

Keep the number of PHP-FPM workers

heroku-php-apache2 sizes the PHP-FPM pool from memory_limit, and with no limit it starts 1 worker. In the Logs tab, find the line that starts with Starting php-fpm with from the current deployment, then add the environment variable WEB_CONCURRENCY with its number of workers, for example 4 on a 512 MB instance.

Deploy

Deploy the application.

The runtime logs of the new deployment show Using PHP-FPM configuration include 'fpm_custom.conf' and Starting php-fpm with 4 workers.... php -i in the Web terminal tab still shows the old values, because the terminal doesn’t read the PHP-FPM pool configuration.

This works with the official php images (-apache and -fpm) and with dunglas/frankenphp.

Add the settings file

Add this php-security.ini file to the Docker context:

php-security.ini

session.upload_progress.enabled = 0
memory_limit = -1
fatal_error_backtraces = 0

Copy it into the image

Add this line to the Dockerfile, after the FROM line of the image that runs the application:

Dockerfile

COPY php-security.ini "$PHP_INI_DIR/conf.d/zz-security.ini"

Deploy

Deploy 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.

Setting	Side effect
`session.upload_progress.enabled = 0`	PHP’s session-based upload progress stops working. Progress bars that track the upload in the browser keep working.
`memory_limit = -1`	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`	Fatal errors no longer include a backtrace. PHP 8.4 and older ignore this line.

Set them only as shown, not with ini_set() or a .user.ini file, 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. Once PHP is upgraded, you can remove the settings.

Update history

Time	Update
Oct 21, 2026, 14:57 UTC	Sevalla published this advisory, with PHP settings that make the attack harder for every build strategy.
Oct 21, 2026, 15:58 UTC	Heroku published the patched PHP releases: Buildpacks applications upgrade with a new deployment.
Oct 21, 2026, 16:24 UTC	Sevalla emailed every company with a PHP application about this advisory.
Oct 21, 2026, 16:56 UTC	Docker Hub published the patched official `php` images: Dockerfile applications upgrade with a new deployment, or by updating a pinned `FROM` line.
Oct 21, 2026, 17:59 UTC	FrankenPHP published the patched images: Railpack applications, and Dockerfile applications based on `dunglas/frankenphp`, upgrade with a new deployment.
Oct 22, 2026, 05:32 UTC	Sevalla’s Nixpacks builds install the patched PHP releases. Redeploying without the build cache now upgrades every build strategy, so this page starts with it.
Oct 22, 2026, 06:28 UTC	The Sevalla team started redeploying every running PHP application on an affected release, without the build cache. Applications with no running instance aren’t included for now.
Oct 22, 2026, 15:03 UTC	The Sevalla team redeployed the hibernated PHP applications on an affected release too, without the build cache. Suspended applications are not redeployed.

More information

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements
GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)

Get started

AI agents

Applications

Pipelines

Databases

Static sites

Object storage

Load balancers

Domains

Git providers

Projects

Developer tools

Company

Billing

Account

Platform

Security and compliance

Support

Protect PHP applications from CVE-2026-109618 and CVE-2026-109619

Redeploy your application

If the Sevalla team deployment failed

Check for signs of an attack

If redeploying does not upgrade PHP

If you cannot upgrade PHP

Update history

More information

​Redeploy your application

​If the Sevalla team deployment failed

​Check for signs of an attack

​If redeploying does not upgrade PHP

​If you cannot upgrade PHP

​Update history

​More information

Redeploy your application

If the Sevalla team deployment failed

Check for signs of an attack

If redeploying does not upgrade PHP

If you cannot upgrade PHP

Update history

More information