Is AWS Lightsail patched for PHP2Shell? How to confirm

AWS says it cannot update running Amazon Lightsail instances in place, and that updated Lightsail blueprints for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) are available in all regions. Your instance is patched only if its own PHP packages were updated and the PHP workers were restarted, or if it was built from an updated blueprint. Check the instance, not the dashboard.

What exactly did AWS say about Lightsail?

The bulletin has one Lightsail paragraph. It says updated blueprints are available in all regions, that AWS cannot update running instances in place, and that customers running PHP workloads should create new instances from the updated blueprints and migrate their applications. At our check on 26 October 2026 the bulletin still read as last updated on 23 October.

Three things the bulletin does not say. It does not list which blueprints were refreshed. It does not say that any existing instance is patched. It gives no guidance on restarting PHP workers. Lightsail's separate update guide, added 21 October 2026, does cover package updates and a web server restart for Lightsail-packaged blueprints, and says the PHP bundled in Bitnami blueprints is not updated by apt upgrade. Those gaps are the reason this page exists: the sentence "blueprints are updated" describes a template, and your site runs on an instance.

Why is "Lightsail is patched" the wrong question?

On Lightsail you rent a virtual server. The operating system, the web server and PHP on it are yours to maintain, which is the same position as any other VPS. AWS patches its blueprints for new instances. It does not reach into your running one.

That produces three separate states for a Lightsail site:

1. Built before 21 October and never touched. It runs the PHP it was built with. It is exposed until someone updates it.
2. Built before 21 October and updated since. It is patched only if the installed package contains the fix and every worker started after the install.
3. Built from an updated blueprint. The PHP in the image should include the fix. You still confirm it on the instance, because a blueprint is a template and you may have changed PHP afterwards.

Our host-by-host pages treat a status the same way everywhere: only what the host's own dated page says. AWS's page says blueprints are updated. It says nothing about your instance. The same logic applies to Cloudways and Kinsta's managed setup, where the host manages more of the stack than AWS does here. Other unmanaged VPS rentals have the same split, as in the DigitalOcean and Linode answers, and the other host-by-host answers cover the rest.

How do I see which PHP my Lightsail instance runs?

Open the instance in the Lightsail console and connect over SSH, either with the browser-based connection or your own client. Everything below is read-only.

• Find which PHP serves the site. Many instances have more than one PHP installed. The command-line php -v can be a different binary from the one answering web requests.
• Read the installed package and its changelog. On Debian and Ubuntu use apt changelog or the dpkg log. On Amazon Linux use rpm -q --changelog against the PHP package. The changelog should name both CVE ids.
• Find when the web service last started: systemctl status for the PHP-FPM or Apache unit. That time must be later than the package install time.
• If the instance came from an application blueprint, check whether PHP lives in the OS package manager or in a bundled application directory. A bundled PHP is not updated by the OS package manager, so check it separately.
• Repeat for every virtual host if the server runs more than one site.

The version number alone misleads, because distributions backport fixes and keep the old number. The Ubuntu and Debian backport trap explains how to read it, and the restart guide shows why a fixed package that nobody restarted keeps serving the old code.

What is the fix status for the operating system underneath?

Your instance runs a Linux distribution, and its package state decides whether "update the packages" gives you a fix. These are the dated vendor records for Amazon Linux at our check on 26 October 2026; the Ubuntu and Debian rows were last read on 24 October.

Amazon Linux rates both CVEs lower (CVSS 8.1 on its own pages) than the PHP project's 9.2. The two scores describe the same pair of bugs, scored by different parties, and the PHP advisories stay the reference we use (every fixed version in one table). These rows move, so open the linked page before you act. Whether a given Lightsail blueprint image uses Amazon Linux, Ubuntu or Debian is shown in the console for your instance.

Should I patch in place or rebuild from a new blueprint?

AWS recommends new instances from updated blueprints. In-place updates are still an option for people who manage their own packages. This table is how we would decide.

A snapshot does not fix anything. It copies the disk as it was, including the old PHP. If you restore or clone from a snapshot taken before the update, update the packages and restart the workers afterwards.

What should I send to AWS support, or to my own developer?

If the instance was built by an agency or freelancer, the same question works for them. Keep the reply.

For my Lightsail instance [instance name, region], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the installed package and changelog entry that names both CVEs, the time the PHP-FPM or Apache workers last started, and say whether this instance was built from a blueprint dated after 21 October 2026.

AWS support can speak to which blueprint was refreshed. It cannot tell you what a previous owner installed on top. For the split of duties on a VPS, see who patches what on a VPS.

Am I affected? A three-state self-test

Was a Lightsail instance exploited before the patch?

AWS reported honeypot attempts from 17 October, four days before disclosure, and says it is unclear whether those attempts would have worked on real systems. At our 24 October check we found neither CVE among the visible entries of the CISA Known Exploited Vulnerabilities catalog, and no primary source naming a compromised site. Attempts are not compromises.

If an instance ran unpatched PHP and was reachable from 17 October, look for unexpected PHP files in upload directories, cron entries you did not create, new administrator accounts, and unfamiliar outbound connections. Patching does not remove anything planted earlier. The look-back guide covers the checks, and the rotate-secrets guide applies if you find evidence.

A web application firewall in front of the instance is a stopgap. Read what a WAF can and cannot do here.

What does the free scan show for a Lightsail site?

The free scan identifies the technologies your site serves, the way Wappalyzer does, then looks each version up in public vulnerability records. It is a lookup: it can say a version is affected, not whether your setup is exposed. It cannot see a backport, which runtime serves a virtual host, or whether workers restarted. Your instance can. Use the scan to find out what your site shows to the outside, and the checks above for the answer.

The scan requires you to prove you own the domain with a DNS record first. The wider context is in the October 2026 tracker, and if you run PHP on more than one server, an inventory of every PHP runtime is the first job. The overview of both bugs is on the PHP2Shell write-up, and the generic fix steps are in the patch guide.