Does the PHP RCE (PHP2Shell) affect my AI-built app?

On October 21, 2026, PHP released fixes for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (php.net security advisory). Amazon's threat intelligence write-up calls the pair "PHP2Shell". PHP's own announcements don't use that name. These bugs are in PHP itself, so they matter only if PHP runs somewhere your app is served from.

1. Quick self-check: does your app run PHP?

Most apps built with Lovable or Bolt, and most Next.js apps on Supabase, are JavaScript or TypeScript on the front end, with Supabase or Node.js on the back end. No PHP is involved. Check anyway, because PHP is often present without the builder knowing:

• WordPress runs on PHP. WordPress recommends "PHP version 8.3 or greater" (WordPress requirements). A marketing site, blog or landing page on WordPress counts, even if your main app doesn't use PHP.
• Laravel (and other frameworks such as Symfony) are PHP. Laravel lists "PHP >= 8.2" as a server requirement (Laravel deployment docs).
• cPanel or shared hosting: most of these plans run PHP for the whole account. Check your hosting control panel for a PHP version setting.
• PHP in a Docker image, such as a FROM php:… base image or an image that installs PHP packages.
• A composer.json file in your repo. Composer is PHP's package manager.

Commands to check (Verified: we ran each one on a test machine using official php and node Docker images):

# On the server or in a shell where your app runs
php -v                        # "command not found" means no PHP CLI in that shell

# In your repo
grep -i '^FROM' Dockerfile    # e.g. FROM php:8.3-fpm-alpine means PHP
ls composer.json              # present means a PHP project

# Inside a Docker image you deploy (replace IMAGE)
docker run --rm IMAGE php -v
docker run --rm --entrypoint php IMAGE -v   # if the image has its own entrypoint

# From outside (only if the header is exposed)
curl -sI https://your-site.example | grep -i x-powered-by

On our test machine, PHP's built-in server sent X-Powered-By: PHP/8.4.27 by default. With expose_php=0, the header was gone even though PHP was still running (Verified). A missing header doesn't prove you're not running PHP. Proxies, CDNs and hosts often remove it. Check the server, the image or the repo instead.

If none of these turn up PHP anywhere you serve from, this advisory doesn't apply to that stack. If you're not sure what your host runs, ask the host.

2. The fix: update PHP

If you run PHP, updating is the fix. PHP's release notes say "There are no complete mitigations, updating is the only safe choice" (php.net).

The versions in this table come from the PHP GitHub advisories (GHSA-w8hw-w9fx-j79w for CVE-2026-109618, GHSA-6wmf-4rv5-p3rp for CVE-2026-109619), the PHP 8 ChangeLog and NVD (CVE-2026-109618, CVE-2026-109619). Both CVEs are rated Critical, CVSS 4.0 score 9.2.

PHP 8.1 and older: php.net says these versions "no longer receive updates from the PHP project". It suggests contacting your Linux distribution or LTS vendor about backported fixes, or upgrading to a supported version. The PHP security team also published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source (php.net).

Who is at risk: php.net names "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". It considers mod_php the highest risk, because an unauthenticated request can trigger the attack "before any application code runs" (php.net).

Check your version against the table (Verified: on our test machine this printed OK 8.4.27 for php:8.4-cli, UPDATE 8.4.26 for php:8.4.26-cli, and NO UPSTREAM FIX ON 8.1.34 for php:8.1-cli):

php -r '$f=["8.2"=>"8.2.35","8.3"=>"8.3.36","8.4"=>"8.4.27","8.5"=>"8.5.12"];$b=PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;echo isset($f[$b])?(version_compare(PHP_VERSION,$f[$b],">=")?"OK ":"UPDATE ").PHP_VERSION:"NO UPSTREAM FIX ON ".PHP_VERSION,"\n";'

How to update depends on where PHP comes from:

• Linux packages: php.net says distributions and LTS vendors "received the patches in advance, so check your vendor for updated packages". Vendors sometimes backport fixes without changing the version number, so check your vendor's security notice if php -v still shows an older version. (Docs-only)
• Docker: rebuild with a fresh base image, for example docker build --pull …, or pin the patched tag, such as FROM php:8.3.36-fpm-alpine. Then redeploy. Verified: on October 23, 2026, the official php:8.3-apache and php:8.4-cli images reported 8.3.36 and 8.4.27, and a build pinned to php:8.3.36-fpm-alpine reported 8.3.36.
• cPanel, shared or managed hosting: check the host's PHP version setting or its status page, and ask the host if the version isn't listed. (Docs-only)
• Source builds: the downloads are linked from the php.net advisory. (Docs-only)

After updating, restart PHP-FPM or Apache, or redeploy the container, so the new version is actually serving requests. Then run the version check again where the site runs.

3. If you can't update right away (stopgap, not a fix)

• Blocking multipart requests: the official advisory for CVE-2026-109618 says: "If the application does not use multipart form data, block such requests at the frontend before they reach PHP" (GHSA-w8hw-w9fx-j79w). This only helps apps that never accept form uploads, and it only addresses that one CVE's attack paths. Amazon's write-up also suggests considering it, but says to "determine how this would affect your application prior to deploying" (AWS Security Blog).
• Other per-CVE settings: php.net lists more measures for each CVE, such as memory_limit, post_max_size and session.upload_progress.enabled=0, each with caveats. Read the full list in the php.net advisory before changing anything.

4. Why update quickly

Amazon's threat intelligence team reported exploitation attempts against its honeypots starting October 17, 2026, four days before public disclosure. It also saw new proof-of-concept exploits "within hours" of the patch release (AWS Security Blog, Oct 21, 2026). Amazon also says it's unclear whether any of these attempts would have succeeded against real systems. More generally, the post argues that "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit." It also recommends measuring patch timelines for critical, internet-facing systems "in hours". If you run PHP, don't wait for a routine maintenance window. And if your site was exposed before you updated, the post suggests investigating from at least October 17, not from the disclosure date.

What not to do

• Don't treat a missing X-Powered-By header as proof that you don't run PHP.
• Don't treat multipart blocking or ini settings as a fix. The official sources say they aren't one.
• Don't forget side sites. A WordPress blog or marketing site on the same domain or account counts too.

AI prompt

Check whether this project or its deployment uses PHP anywhere: a Dockerfile FROM line
or installed php packages, composer.json, WordPress or Laravel files, or hosting
config that mentions PHP. List every place you find. If PHP is used, report the
version each place pins or installs, and compare it with the patched releases
8.5.12, 8.4.27, 8.3.36 and 8.2.35 (PHP 8.1 and older get no upstream fix).
Propose the minimum change (e.g. a pinned base-image tag) and show the diff.
Do not change anything else. Show the plan first and wait for my OK.

How to verify

1. Run the self-check in step 1 and write down each place PHP runs, or confirm it runs nowhere.
2. Where PHP runs, the version check in step 2 prints OK, or your vendor's security notice confirms the fix is backported.
3. After you restart or redeploy, check the running version again where the site is served from, not only on your laptop.

Related

Next.js security update · Poisoned dependency · Pre-launch checklist