TL;DR

PHP2Shell refers to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which may allow remote code execution in affected applications. Both are rated CVSS v4.0 9.2. See the CERT-EU advisory 2026-018.

Scalingo first updated the PHP buildpack to disable PHP session upload progress in php.ini and the PHP-FPM pool. It later blocked multipart HTTP requests at the router for all PHP applications. The router block is active and does not require a deployment. Requests with a multipart/* content type return 403 Forbidden, including file uploads and forms using multipart/form-data. Applications that require multipart requests can re-enable them with the Scalingo CLI 1.51.0 or later.

Action required: rebuild and redeploy applications using the Scalingo PHP buildpack to apply the workaround. The fixed PHP versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are now available on Scalingo. The workaround and router block reduce exposure but do not replace the PHP update.

What Happened?

On October 20, 2026, the PHP project announced an upcoming security release addressing two critical vulnerabilities, scheduled for October 21, 2026 at 14:00 UTC (16:00 UTC+2). The CVE identifiers and scores above are those reported by CERT-EU.

At 15:20, PHP had not yet published technical details or fixed versions, and the affected versions remained unconfirmed. We were assessing the impact on PHP applications hosted on Scalingo.

PHP published the fixed releases at 16:00 UTC+2 on October 21, as scheduled. The versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP’s security advisory states that updating is the only complete solution.

Incident Analysis

CERT-EU reports that the vulnerabilities could allow remote code execution in affected PHP applications. The actual impact on a given application depends on its deployment and permissions.

What We Did

We updated the PHP buildpack to disable session upload progress in php.ini and enforce this setting in the PHP-FPM pool. The updated buildpack is available for application deployments.

Existing applications using the Scalingo PHP buildpack must be rebuilt and redeployed to receive the update. Restarting an application does not update its embedded PHP runtime or configuration. Applications using a custom, forked or pinned buildpack do not receive the change automatically.

Scalingo’s router now rejects requests with a multipart/* content type and returns 403 Forbidden before they reach the application. The rule applies to existing applications without a rebuild or restart.

Multipart requests can now be re-enabled per application with the router-multipart-upload command, available in the Scalingo CLI 1.51.0 and later.

What You Should Do

Some failed deployments can leave the previous version running without the buildpack workaround; the router protection remains separate. See deployment error behavior.

1. Check the PHP versions available for your stack: scalingo-22, scalingo-24 or scalingo-26. Check stack status to confirm your stack is supported.
2. Rebuild and redeploy each application with the Scalingo PHP buildpack to disable PHP session upload progress (session.upload_progress.enabled); see Git deployment instructions or manual GitHub deployment.
3. To temporarily stop long-running application processes, scale all long-running process types to zero using the scaling instructions. This makes the web/tcp endpoints unavailable, but does not stop Scalingo Scheduler tasks or one-off containers.
4. Check that your PHP version constraint and buildpack pin allow the fixed version for your branch: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Redeploy, then run scalingo --app my-app run php -v to check the deployed PHP version in a one-off container. This second deployment is required even if you already applied the workaround.

The buildpack workaround alone disables PHP upload progress tracking without disabling file uploads. The router protection additionally blocks multipart requests: uploads and form submissions using multipart/form-data now return 403 Forbidden and do not reach the application. Other request content types are not blocked by this rule.

If your application requires multipart requests, contact support to discuss the impact and available options. Do not assume that redeploying or applying the buildpack workaround removes the router restriction.

If your application requires multipart requests, you can re-enable them with the Scalingo CLI. The CLI must be updated to version 1.51.0 or later; run scalingo --version to check the installed version. We recommend re-enabling multipart requests only after deploying a fixed PHP version.

scalingo --app <app-name> router-multipart-upload --enable

Redeploying or applying the buildpack workaround does not remove the router restriction.

If you manage your own PHP runtime, disable session upload progress in php.ini:

session.upload_progress.enabled = Off

If you use PHP-FPM, you can also enforce it in the pool configuration (this syntax is only valid in PHP-FPM pool files, not in php.ini):

php_admin_flag[session.upload_progress.enabled] = off

These temporary measures reduce exposure to specific attack paths. Only updating PHP fully addresses both vulnerabilities.

What We Will Do in the Future

Scalingo will make the upstream fixed PHP versions available as soon as possible and update this bulletin when they are ready for deployment. Check this bulletin for Scalingo availability and deployment instructions.

We will update this bulletin when PHP 8.2.35 becomes available on Scalingo.

All four fixed PHP versions are now available on Scalingo.

Product Impacts

Scalingo PaaS

PHP applications hosted on Scalingo are potentially affected. PHP identifies installations serving web requests, including PHP-FPM, as at risk. For older PHP branches, see the upstream advisory.

Multipart request blocking can interrupt file uploads and multipart form submissions. It does not change the PHP runtime inside existing applications. It can be lifted per application with the Scalingo CLI 1.51.0 or later.

Contact

If you have questions about this bulletin or need help applying the workaround, contact Scalingo support at support@scalingo.com or through the in-dashboard chat.

Timeline

Changelog

• 2026-10-21 13:40: Initial publication of SSB-2026-005. The updated PHP buildpack was available; patched PHP versions were pending.
• 2026-10-21 15:20: Clarified PHP and stack requirements, deployment failures, process shutdown limits, upload progress impact, and the need to redeploy with a patched PHP version.
• 2026-10-21 16:40: Updated the bulletin with the active router block and availability of PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• 2026-10-21 18:50: Explained how to re-enable multipart requests with the Scalingo CLI 1.51.0 or later.