PHP2Shell: Critical PHP Vulnerability and What You Need to Do on Sliplane

On October 20, 2026 the PHP security team announced an emergency release for two critical vulnerabilities in PHP core: CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Security researchers call the pair PHP2Shell. Details leaked before a patch was available, so we're acting now instead of waiting.

This post sums up what we know, what we did on Sliplane, and what you should do with your PHP services.

Update (October 21, 2026): The fix is out. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities, see the official PHP security advisory. Update your PHP images and redeploy now.

What happened?

According to the advance notice and early analysis by researchers like watchTowr, the two flaws allow remote code execution. Here's the short version:

• Attack vector: Crafted multipart/form-data POST requests, the format browsers use for file uploads.
• Before your code runs: PHP parses multipart bodies before any application script is executed. So it doesn't matter whether your app actually accepts uploads. If a request reaches PHP, it can be attacked.
• Default config: Leaked details link at least one of the flaws to session.upload_progress, which is enabled by default.
• No login required: The attack is reported to work unauthenticated against stock configurations.
• Exploitation: As of writing, no exploitation in the wild has been confirmed, but proof-of-concept code is reportedly circulating.

The fix was released on October 21, 2026. According to the official PHP security advisory, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities:

• CVE-2026-109618, RCE via OOM corruption: Out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat that invalid data as valid.
• CVE-2026-109619, RCE via stale global state: Internal request state can survive after its memory has been freed. A later request handled by the same worker may use that stale state.

The PHP team considers every PHP installation that serves web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where a demonstrated exploit triggers before any application code runs.

PHP 8.1 and older don't get official releases anymore. Because of the severity, the PHP security team published minimal source backports for PHP 7.4, 8.0 and 8.1, but these only help if you build PHP from source. Upgrading to a supported version is the better option. Also keep in mind that PHP 8.2 reaches end of life on December 31, 2026.

What we did: temporarily blocking multipart uploads

As a hotfix, we're temporarily blocking multipart/form-data requests at the Sliplane proxy, before they ever reach your containers. That shuts down the known attack vector for every service on the platform, whether you've patched yet or not.

What this means for you:

• Regular traffic keeps working. Normal page views, JSON APIs and standard form submissions (application/x-www-form-urlencoded) aren't affected.
• File uploads won't work for now. Uploading media in WordPress, attaching files in Nextcloud, or any form with a file input will fail while the block is active.
• It's temporary. Patched PHP versions are out now. We'll lift the block once customers have had a chance to update. We'll announce this on our status page and by email.

We know broken uploads are annoying. But an unauthenticated RCE in PHP core is about as bad as it gets, and we'd rather be safe while patches roll out. If the block is a real problem for your business, reach out to our support and we'll find a solution together.

What you should do

The block on our side buys time, but it's not a fix. Your containers still run a vulnerable PHP version until you update them. The PHP team is clear that there are no complete mitigations and updating is the only safe choice. Here's how.

1. Check which PHP version you're running

Open a shell in your service (via the Sliplane SSH access) and run:

php -v

This prints the PHP version inside your container. Anything below the fixed versions listed above is vulnerable. If you're on PHP 8.1 or older, there's no official release for you, so upgrade to a supported branch.

2. Redeploy with the patched image

Most PHP apps on Sliplane are based on Docker images. How you update depends on how you deploy.

You use a prebuilt image (e.g. wordpress, nextcloud, phpmyadmin): Wait until the maintainers have published a new image with the patched PHP version. Then update the image tag in your service settings and redeploy. Check the image on Docker Hub for the newest release, and watch out for pinned tags that won't receive the update.

You build your own image from a Dockerfile (e.g. a Laravel app): Bump the base image to the patched version in your Dockerfile:

FROM php:8.4.27-fpm

Then push to your repo or trigger a redeploy in the dashboard. Sliplane rebuilds your image with the new base. If you use a floating tag like php:8.4-fpm, a redeploy pulls the newest version as soon as the official image is updated.

If your Dockerfile installs PHP from rpms.remirepo.net: the PHP team says this repo won't have updates on release day and recommends switching to distribution packages or building from source.

Afterwards, run php -v again to verify that the new version is live.

3. If you can't update right away

Maybe you're waiting for a prebuilt image to be updated. In the meantime, the advisory lists measures that reduce exposure to specific attack paths. They don't make your installation safe, so treat them as a bridge until you've patched.

Add a small ini file to your image:

FROM php:8.4-fpm

RUN printf "session.upload_progress.enabled = Off\npost_max_size = 8M\nupload_max_filesize = 4M\n" > /usr/local/etc/php/conf.d/zz-php2shell.ini

This writes a config file that PHP loads on startup:

• session.upload_progress.enabled = Off blocks the confirmed session paths of CVE-2026-109619. Hardly any app needs this feature.
• post_max_size = 8M reduces exposure to CVE-2026-109618. If your app needs file uploads, the PHP team recommends 32M instead. Keep upload_max_filesize below post_max_size.

These settings have to be in php.ini or the server config. Setting them with ini_set() or in a .user.ini file doesn't help. A redeploy restarts all PHP workers, so the new settings take effect everywhere. Verify them with:

php -i | grep -E "session.upload_progress.enabled|post_max_size"

The output should show Off and 8M. A few more measures from the advisory:

• On PHP 8.5: Also add fatal_error_backtraces = 0 to the ini file. This blocks the confirmed fatal backtrace path.
• memory_limit: Setting memory_limit = -1 removes the controllable memory limit failure behind CVE-2026-109618. Only do this if your container has a memory limit as a boundary, otherwise a single request can eat up your server's memory.
• Fatal errors: Fix fatal errors and execution timeouts that attackers can trigger, and remove invalid or deprecated per-request settings that emit warnings. Hiding errors with display_errors or @ doesn't help.

4. Check your logs

If your service was publicly reachable before our block went live, take a look at your service logs in the Sliplane dashboard. Unusual POST requests with large multipart bodies, unexpected crashes of PHP processes, or new files you don't recognize are worth investigating. If something looks suspicious, contact us.

Summary

PHP2Shell is serious: remote code execution, no login needed, and it hits default configurations. We've closed the known attack vector at the platform level for now, so file uploads are temporarily disabled. Your part: update your PHP images to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and redeploy now. If you use a prebuilt image, do it as soon as the maintainers have published an update. If you have any questions, we're here to help.

Sources: PHP security advisory, watchTowr FAQ, The Hacker News, Huntress, Phoenix Security