Linode/Akamai PHP2Shell status: who patches, how to check

Linode (Akamai Cloud) does not patch PHP inside your Compute Instance. At our check on 26 October 2026, Linode's status page advised customers running vulnerable PHP on Linode instances to apply upstream PHP patches, and we found no statement saying Akamai patches it for you. If you run PHP on a Linode, update the PHP package for CVE-2026-109618 and CVE-2026-109619, restart the PHP workers, and confirm the service started after the update.

The bug and the full fix path are in the explainer on how the flaw works and in how to patch each channel. This page covers what is specific to Linode.

Who patches PHP on a Linode?

You do, on any instance where you installed or chose the PHP. A Compute Instance is a server with your operating system and your packages. Akamai's own operating system update guide (dated 30 July 2026) gives the update commands per distribution and calls frequent updates the single biggest security precaution for any operating system. It does not say Akamai applies them for you.

The one managed product we checked says the same in plain words. Linode Managed includes monitoring, incident response, backups and a cPanel licence. It states that it does not include assistance with maintenance, updates or the configuration of software on your Linodes.

If you are unsure which row you are in, the guide to who owns patching on your site walks through it. Other self-managed cloud hosts work the same way, for example DigitalOcean Droplets and AWS Lightsail instances, and the other host status pages cover the rest.

What have Linode and Akamai said about PHP2Shell?

Akamai published a 21 October 2026 write-up of both CVEs. It names one protection, Adaptive Security Engine rule 3000991 v1, in the App & API Protector product. It says existing command injection rules were already mitigating weaponized payloads. It does not mention Linode or Akamai Cloud Computing.

Linode's status page is the place a provider-wide statement would appear. At our check on 26 October 2026 it carried a "Customer Security Advisory: PHP Remote Code Execution Vulnerabilities" for both CVEs. Akamai opened it on 21 October 2026 and marked it resolved on 23 October 2026, saying its assessment and mitigation efforts were complete. The items it lists as affected are Akamai's own Quick Deploy Apps, speed test pages and parts of its website, with Cloud Infrastructure Speed Tests left offline. For customers it advises following the upstream PHP vendor's guidance and applying upstream patches to vulnerable PHP on Linode instances. On 24 October 2026 the page had returned a human-verification challenge to our automated check, so we had not read it then. Open the page in a browser to see its current wording.

The advisory puts patching of PHP on your instance with you, so "Linode patched it for me" has no source. The status of your instance is unknown until you read it from the instance.

Does Akamai's WAF rule or Cloud Firewall cover my Linode?

Probably not by default. The two products sit in different places.

Akamai says the most effective defense continues to be prompt application of vendor patches. The question does a WAF stop PHP2Shell covers what a rule can and cannot see, including direct access to the origin address.

How do I fix PHP2Shell on a Linode I run?

Three things must be true, in order.

• Find your distribution: cat /etc/os-release. Linode's guide gives apt update && apt upgrade for Ubuntu and Debian and dnf upgrade for RHEL family systems.
• Install the PHP package from your distribution. The changelog must name CVE-2026-109618 and CVE-2026-109619, because backports keep the old number.
• Restart the service that serves PHP: php8.x-fpm, apache2, httpd or your LiteSpeed setup. Canonical says the application that uses PHP would likely need a restart, or the system can be rebooted.
• Check every virtual host and pool if the instance runs more than one PHP version.
• Rebuild and redeploy any container image that bundles PHP.
• Check any instance you restored or cloned since 21 October. The PHP inside is whatever it had when it was saved.

Package status for the two distributions most Linode owners run, at our check on 24 October 2026:

The Ubuntu numbers look old on purpose. See the backport version trap. The tracker records a package fix, not a worker restart, and restarting PHP-FPM after an update is the step most often missed.

How do I check the running PHP, and what if SSH is not working?

Use the console. Akamai's Lish guide (dated 2 June 2026) gives the route: in Cloud Manager, select Linodes, choose the instance, then Launch LISH Console in the upper right. For the SSH gateway, the guide has you add your SSH public key in Cloud Manager's Lish settings. This is useful when a firewall rule or a broken SSH config has locked you out.

Once you have a shell, read state only:

• systemctl status for the PHP-FPM or Apache unit shows when it last started.
• The package install time (rpm -q --last php-fpm, or the dpkg log on Debian and Ubuntu) must be earlier than that start time.
• php -v shows the command line binary. The web service can be a different one, so ask the FPM binary itself or read the version your site reports.
• Do not leave a phpinfo() page online. Load it once and delete it.

Am I affected? A three-state self-test

What should I ask if someone else runs my Linode?

An agency, freelancer or reseller may hold the root login. Send them this and keep the reply:

For [your domain], on the Linode instance that serves it: which operating system and PHP package is running, does the package changelog name CVE-2026-109618 and CVE-2026-109619, and what time did PHP-FPM, Apache or LiteSpeed last restart? Is any other PHP version or container serving this site?

A reply that says "we patched" without a package name and a restart time is a claim, not evidence. Akamai Cloud support can speak to Linode platform and account questions. Software on the instance is outside what the Managed page says it covers.

What if my PHP is end of life?

The PHP project notice says PHP 8.1 and older no longer receive updates from the project. It published minimal source backports for 7.4, 8.0 and 8.1, and Ubuntu lists ESM packages for older releases. Prefer a vendor package that names both CVEs. Otherwise move to a supported branch and test first. What owners stuck on old PHP can do is on its own page.

If you cannot update today, the notice lists interim settings. For CVE-2026-109618 it suggests memory_limit=-1 set at server level and a low post_max_size. For CVE-2026-109619 it suggests session.upload_progress.enabled=0 in php.ini or the pool configuration. The PHP project's 23 October notice about a separate issue, CVE-2026-115560, recommends the same setting until the next bugfix release. These reduce exposure and do not replace the update. Restart every worker after changing them.

Was anything exploited before you patched?

AWS reported exploit attempts against its honeypots from 17 October, four days before disclosure, and broad attempts after proof-of-concept code appeared on 21 October (AWS, vendor-claimed). AWS says it is unclear whether any attempt would have worked on real systems. We found no primary source naming a compromised Linode or any other site. Neither CVE was among the CISA catalog entries we could read on 24 October, and that view was limited, so re-check it.

If your PHP was unpatched and reachable from 17 October, look for PHP files you did not upload, scheduled tasks you did not create, new administrator accounts and unexpected outbound connections. Patching does not remove anything planted earlier, and the full list of compromise indicators is on its own page. The wider October picture is in the tracker.

What can the free scan tell me about my Linode?

The free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup. It can say a version is affected. It cannot see a distribution backport, which runtime serves a virtual host, or whether workers restarted. Your instance can.