PHP "php2shell" Flaw: What It Means for Our Customers

•Byrnu Team•3 min read

Since October 21, 2026, a large part of the web has been busy patching two critical PHP flaws. You may have heard about them from your own IT teams. Here is what happened and, above all, what it means for Byrnu customers.

In short: Byrnu does not use PHP. Our products are not exposed to these flaws, and continuous monitoring alerts us in real time to any new CVE of the same kind.

What Happened

On October 21, 2026, the PHP project released emergency fixes for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed "php2shell":

  • they allow unauthenticated remote code execution: an attacker can take control of a server without holding an account;
  • each is rated 9.2 (CVSS 4.0), meaning critical;
  • they affect any PHP installation serving web requests: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed;
  • the fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; any earlier version is vulnerable.

Why So Many Sites Are Affected

PHP powers a considerable share of the web: corporate sites, e-commerce, content management systems, and extensions and plugins of every kind. A flaw in the core of the language therefore reaches both the sites you know about and the ones you have forgotten: an old campaign site, an internal tool, a component embedded in other software. That is why CISA first recommends taking inventory of everything that uses PHP, then patching, starting with whatever is exposed to the Internet.

What This Means for Our Customers

Byrnu does not use PHP. Our products do not rely on this technology: the "php2shell" flaws do not apply to them, and there is nothing you need to do on your side for your Byrnu services.

Continuous Monitoring, Not After-the-Fact Reaction

Not using a technology does not excuse us from watching it. At Byrnu:

  • continuous monitoring makes sure our products are never affected by this type of problem;
  • real-time notifications reach us as soon as a new CVE of this format is published, meaning a critical flaw in a web component, whether or not it concerns us;
  • every advisory is assessed by our team and classified according to whether it affects our technology stack.

So the question "are we affected?" is answered in minutes, not days.

What About Your Other Systems?

Even if your Byrnu services are not concerned, other systems in your organization may be. If you host PHP sites or applications, here are the recommended steps:

Take Inventory

Identify every system that uses PHP, including those embedded as a component of other software.

Patch

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply the patched packages from your operating system vendor. Prioritize whatever is exposed to the Internet.

Mitigate in the Meantime

If the update has to wait, disable session.upload_progress.enabled in php.ini. A web application firewall can provide temporary protection.

Monitor

Watch for PHP processes that launch shells or download tools. Systems that cannot be updated, notably PHP 8.1 and earlier, should be taken offline.

ℹ️ Need a Hand?

Our team can help you assess your exposure. Get in touch.

Sources

Related articles