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.

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 official fix is scheduled for October 21, 2026 at 14:00 UTC. Expected fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These numbers aren't officially confirmed yet, so check the PHP release announcement once it's out. PHP 8.1 and older are end-of-life and won't get a fix.

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. We'll lift the block once patched PHP versions are out and 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. 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, you need to upgrade to a supported branch, since there won't be a patch.

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.

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

3. Optional: disable session.upload_progress

If you want an extra layer of protection until you can patch, disable the session.upload_progress feature. Hardly any app needs it. Add a small ini file to your image:

FROM php:8.4-fpm

RUN echo "session.upload_progress.enabled = Off" > /usr/local/etc/php/conf.d/zz-php2shell.ini

This writes a config file that PHP loads on startup and turns the feature off. Verify it with:

php -i | grep session.upload_progress.enabled

The output should show Off. Keep in mind this only covers the part of the attack that's been linked to session.upload_progress so far. It's a mitigation, not a replacement for the patch.

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 the patched version and redeploy as soon as they're available. If you have any questions, we're here to help.

Sources: watchTowr FAQ, The Hacker News, Huntress, Phoenix Security