PHP2Shell: Agility CMS Is Not Affected. What To Do If You Run PHP
CVE-2026-109618 and CVE-2026-109619 are critical PHP remote code execution flaws. Here is where they apply, and where they do not.
Agility CMS is not affected by PHP2Shell. Our platform, our APIs and our CDN run on secure cloud infrastructure that does not execute PHP, so there is no PHP anywhere in the path that serves your content. There is nothing for you to patch on our side. If you run PHP anywhere else, including a PHP front end that reads from our Content Fetch API, that is where you need to act today.
What PHP2Shell actually is
PHP2Shell is the name the security community gave to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. Together they allow unauthenticated remote code execution, which means an attacker who can send a request to a PHP server can run their own code on it with no login required.
CVE-2026-109618 is an out-of-memory corruption flaw. Out-of-memory handling can interrupt PHP while request data is only partly initialized, and cleanup then treats that invalid data as valid. CVE-2026-109619 is a stale global state flaw, where request-owned internal state survives after its memory has been freed and a later request on the same worker picks it up.
The PHP project says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php highest, with a demonstrated exploit that fires before any application code runs. Fixes shipped on October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Why Agility services are not affected
Agility is a SaaS headless CMS. The content APIs, the management APIs, the editor and the CDN all run on secure cloud infrastructure that we manage, and none of it executes PHP. Neither CVE applies to the Agility platform or to the content delivery your sites depend on. Our SOC 2 Type II compliance program and our patching process cover this infrastructure, and no customer action is required.
Headless architecture matters here in a specific way. Your front end calls our API over HTTPS, and the runtime that front end happens to use is yours to patch, not ours. If your front end is Next.js, Astro or any other non-PHP runtime, PHP2Shell is irrelevant to you. If it is PHP, the vulnerability sits in your runtime, underneath your application, and the content layer behind it has nothing to do with the fix.
What to do today if you run PHP
- Patch immediately. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the patched build from your Linux distribution. Distributions and LTS vendors received the patches in advance, so check your vendor first.
- Find the PHP you forgot about. This is the step that catches most teams. Marketing microsites, an old WordPress or Drupal install, hosting control panels, internal tools, and appliances with bundled PHP all count.
- Treat PHP 8.1 and older as unfixable. Those branches are end of life and get no fix from the PHP project. Check whether your distribution backported one. If not, upgrade the runtime, or take the server off the public internet until you can.
- Do not rely on php.ini settings. PHP's advisory lists partial measures such as
memory_limit=-1, a lowpost_max_sizeandsession.upload_progress.enabled=0, and says plainly that none of them make an installation safe. They buy hours, not safety. - Restart every worker after patching. A running PHP-FPM or Apache worker keeps the old binary loaded, so an unrestarted pool is still vulnerable after the package update.
- Check for compromise if you were exposed. Look for new files in your web root, unfamiliar cron jobs, new accounts, and php-fpm or apache2 processes spawning shells or download tools.
Frequently asked questions
Does PHP2Shell affect Agility CMS?
No. Agility CMS runs on secure cloud infrastructure that does not execute PHP, and no part of the platform that serves or manages your content is exposed to these flaws. CVE-2026-109618 and CVE-2026-109619 only affect servers running the PHP runtime.
I use Agility CMS with a PHP front end. Am I at risk?
Yes, but the risk is in your own hosting, not in Agility. The PHP runtime serving your front end needs to be patched to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The Agility API you are calling needs nothing.
Is PHP2Shell being exploited in the wild?
Early attacks were reported around the time the patches shipped on October 21, 2026, and security researchers expected mass scanning to begin within minutes of the release. Treat any unpatched, internet-facing PHP server as a priority.
If you have questions about how Agility hosts and secures your instance, our hosting, security and compliance documentation covers it, or reach out to our support team.
About the Author
Joel is CTO at Agility. His first job, though, is as a father to 2 amazing humans.
Joining Agility in 2005, he has over 20 years of experience in software development and product management. He embraced cloud technology as a groundbreaking concept over a decade ago, and he continues to help customers adopt new technology with hybrid frameworks and the Jamstack. He holds a degree from The University of Guelph in English and Computer Science. He's led Agility CMS to many awards and accolades during his tenure such as being named the Best Cloud CMS by CMS Critic, as a leader on G2.com for Headless CMS, and a leader in Customer Experience on Gartner Peer Insights.
As CTO, Joel oversees the Product team, as well as working closely with the Growth and Customer Success teams. When he's not kicking butt with Agility, Joel coaches high-school football and directs musical theatre.
