Skip to main content
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, 15:58 UTC.

​
Apply the quick fix now

Applications built with Buildpacks can upgrade right away: deploy them again and the build installs the patched PHP release. 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 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.
1

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
2

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

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.

​
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: See Web terminal to open a shell in a running instance.

​
What the quick fix changes

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.
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. 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 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).
  • 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

When Docker Hub publishes the patched tags, change the FROM line to the exact patched release of your branch, for example FROM php:8.4.27-apache instead of FROM php:8.4-apache, and deploy. An exact version shows which release the build uses. dunglas/frankenphp images get the fix when FrankenPHP publishes new images. After the deployment, php -v in the Web terminal tab prints the patched version.

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

​
More information