Cisco Flags Critical PHP Vulnerability Affecting Its Products

What Happened

On October 30, 2026, Cisco published a security advisory for a critical PHP vulnerability affecting its products. The advisory covers CVE-2026-109618 and CVE-2026-109619, two remote code execution flaws in PHP that the PHP Foundation announced on October 21. Cisco rates the security impact as Critical.

CERT-EU also issued guidance on the same pair of flaws. It said the fixes landed on October 21 at 13:30 UTC in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and that both flaws can allow unauthenticated remote code execution. It also said technical details are being discussed publicly and initial proofs of concept have begun to circulate.

Timeline

The dates below come from the two advisories.

• 20 October 2026: PHP project announced an upcoming security release addressing two critical vulnerabilities, according to CERT-EU.
• 21 October 2026 at 13:30 UTC: PHP team released fixes in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• 23 October: PHP disclosed a new RCE vulnerability that affects web applications configured in an unusual way, according to CERT-EU.
• 30 October 2026: Cisco published its security advisory for CVE-2026-109618 and CVE-2026-109619 affecting its products.

Who Is Affected

Any organization running a PHP version older than the new releases is exposed to CVE-2026-109618 and CVE-2026-109619. That includes Cisco customers, because Cisco said the advisory covers vulnerabilities in PHP affecting its products. Cisco was explicit that products not listed in the advisory are not affected.

For MSPs, the affected population is broader than one vendor. PHP is everywhere, and this pair of flaws can be exploited without authentication. If one of your clients runs a PHP application, whether in your datacenter, in their office, or in a cloud VM, you need to know which PHP version it uses.

Why This PHP Vulnerability Matters

For you, the immediate issue is prioritization. A remote code execution flaw in a language as common as PHP can give an attacker a foothold in a client environment. When a vendor rates a runtime flaw Critical and a fix is already out, patch planning moves to the front of the queue.

The bigger picture is that PHP rarely runs alone. It sits behind web servers, talks to databases, and often supports the applications your clients depend on. That means patching PHP is not just a server job. It can require coordinating with the app owner, testing compatibility, and scheduling downtime.

General guidance for any critical RCE in a runtime like this is to patch first and verify after. If you cannot patch immediately, reduce exposure by keeping the vulnerable service off the public internet until the fix is in place.

Technical Details

CVE-2026-109618 is described by the PHP Foundation as RCE via OOM corruption. CVE-2026-109619 is described as RCE via stale global state. The Cisco advisory references the pair as PHP2shell. CERT-EU says both vulnerabilities can allow unauthenticated remote code execution.

The patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Cisco's advisory is specific to its products and states that any product not listed in the advisory is not affected.

Separately, CERT-EU reported that on October 23 PHP disclosed a new RCE vulnerability. It affects only web applications configured in an unusual way, PHP considers it an unlikely risk, and no out-of-band release is planned.

What to Do This Week

Work through this list in order. The first two items come straight from the advisories. The rest are standard steps for this class of problem.

1. Patch affected assets immediately. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
2. Where patching is not feasible, isolate internet-facing applications from public networks until a fix is applied and verified.
3. Inventory every client environment that runs PHP and record the exact version. Do not assume an application update covers the PHP runtime.
4. Check Cisco's advisory for the product list. Confirm which of your clients' Cisco products are listed and which are not.
5. Review whether any of your applications use the unusual configuration PHP described on October 23, and apply the mitigation if they do.
6. After patching, verify the running version on each system. As a standing practice, schedule a follow-up check in the next maintenance window.

What to Tell Clients

Your web application runs on PHP, and the PHP project has released fixes for two critical vulnerabilities that can allow remote code execution without a login. We are checking the exact PHP version on your servers and will schedule the update as soon as we have confirmed the application is compatible.

If we cannot patch right away, we will restrict access to the vulnerable application until the fix is in place. That means the app may be unavailable from the internet for a short window. That is the safer option while proof-of-concept code is circulating.

If you use Cisco products, we will compare your equipment against Cisco's advisory. Cisco has said products it does not list are not affected, and we will confirm that for anything you run.

Make This a Standing Check

Critical runtime advisories move fast. Make it a habit to review PHP and other runtime versions across your client base on a regular schedule, and watch vendor advisories for the products you manage. That way the next patch is planned and tested instead of rushed.

Frequently Asked Questions

Sources

• Vulnerabilities in PHP Affecting Cisco Products: October 2026Cisco Psirt · Official
• 2026-018: Critical Vulnerabilities in PHPCert Eu · Official
• GCP-2026-070Google Cloud Security Corrected · Official
• GCP-2026-072Google Cloud Security Corrected · Official
• AL26-026 - Critical vulnerabilities impacting PHP - CVE-2026-109618 and CVE-2026-109619 - Update 2Canada Alerts · Official