The Industry Reacts: PHP2shell, patching drama, and advice for CISOs

I would not let a successful patch close the ticket. Any internet-facing PHP system exposed before the update may have been targeted. Teams should preserve their web server, reverse proxy, WAF, endpoint and operating system logs, then look across them for suspicious POST or multipart requests, memory exhaustion, repeated PHP worker crashes and unexpected processes launched by PHP or the web server. New files in web directories, unfamiliar scheduled tasks and outbound connections from the web process also deserve investigation.

CVE-2026-109618 can be triggered before application code runs in some mod_php configurations. A clean application log does not clear the host. Where the evidence points to code execution, I would isolate and rebuild the system, then rotate any database credentials, API tokens or other secrets the PHP process could reach.

PHP often becomes almost invisible inside the environment because teams think in terms of the website or content management system running above it. The application may look current while the interpreter underneath it is years out of support. Production servers are only part of the inventory. Old services, development systems and reusable container images need the same attention.

Shane Fry|
Chief Technology Officer, RunSafe Security

Historically, turning a complex memory-safety bug into a reliable attack required significant expertise and time, repeated testing, and a detailed understanding of the vulnerable software. AI is dramatically reducing that effort, as can be seen by working proof-of-concepts being deployed within hours of the CVE details being leaked. We can no longer assume that a vulnerability is relatively safe simply because exploitation appears too difficult.

Organisations need to harden software at runtime so attackers cannot reliably turn memory corruption into control of a system.

VIEW ALL

Ramy Rahman
Senior principal solutions engineer at ArmorCode

The exposure is broad, covering PHP installations serving web requests, including PHP-FPM, Apache and LiteSpeed. Apache’s mod_php carries the highest stated risk. But the roughly 70% figure measures PHP usage, not how many sites are vulnerable. Exploitation has been observed through a honeypot network.

The broad exposure brings comparisons to Heartbleed. It’s too early to say whether the actual impact will compare. What’s different today is that AI can help attackers move faster, giving defenders less time to patch.

Attackers could steal data, alter websites or reach other systems through exposed credentials. At scale, a credible worst case is an automated campaign compromising unpatched sites, leading to data theft, fraud and outages.

AI makes it easier to examine large amounts of code and revisit flaws previously considered too difficult to exploit. It also helps attackers reverse-engineer patches, shortening the window between a fix becoming public and an exploit becoming available.

Flaws we once thought were impractical to exploit are back on the table. The underlying risks aren’t new, but exploiting them is becoming easier and accessible to more people. We need to revisit old assumptions and get faster at patching.

Manoj Nair
CTO at Snyk

AI is changing the math of cybersecurity. Security teams can no longer afford to fix only the highest-priority vulnerabilities and leave the rest in the backlog. When attackers can use AI to find and chain weaknesses at machine speed, defenders need to use AI to accelerate remediation and fix more vulnerabilities before they can be exploited.

Raghu Nandakumara
Vice president of industry Strategy at Illumio

There’s an important paradox here. We want AI to move quickly enough to find vulnerabilities humans might miss, while also making sure that increasingly autonomous systems operate within boundaries we understand and control. The faster AI becomes at finding weaknesses, the more important it becomes to think about what happens after those weaknesses are exposed, especially when organisations can’t immediately patch every affected system. The lesson isn’t that AI is inherently dangerous or inherently protective. It’s that speed without control creates a new kind of security problem.

Gunnar Hellekson
Vice president and general manager, Lightwell, Red Hat

Much of the critical software running the world is also the least visible. Stable production code 'that just works' is now at risk due to the speed and volume of new vulnerabilities found via AI-driven discovery. The issues facing PHP are a reminder of just how deeply open source is woven into the systems that run global business.

The ripple effects from vulnerabilities in foundational software like PHP can extend across entire industries. This makes it critical to have a trusted software source that helps manage this risk and, ideally, quickly responds to these new threats as they emerge.

Given the potential impact of these vulnerabilities, Red Hat recommends that customers deploy validated, tested patches as soon as they are available from trusted sources, even outside of normal patching windows.

Professor Asha Rao
RMIT’s School of Science

With the increased deployment of AI, risk management of information systems becomes more critical.

The vulnerability in PHP was probably decades old, though it was only discovered now.

Companies need an information security policy that is aware of all systems, along with a critical incident response plan which details who is alerted and how the response is going to be coordinated and escalated.

It is possible that similar vulnerabilities will come to light, and while being proactive is often best, in many cases being reactive may be the only option.

If a reactive response is required, acting fast will provide the best protection.

Jake Moore
Global Cybersecurity Advisor at ESET

When vulnerabilities are leaked before a patch is available, it is usually a scramble to do whatever is possible to mitigate the damage, but the sheer scale of PHP across the internet makes this far more serious than the usual exploit. A serious vulnerability in technology used by millions of websites could immediately give cybercriminals an enormous number of potential targets.

A situation like this gives attackers a huge head start, which is worrying when it feels like they always have a head start as it is. Criminals are known to be extremely quick to exploit any given opportunity, and even a short delay in patching could leave lots of businesses exposed.

Businesses should try to identify their vulnerable systems and apply the patch immediately.

Niv Lanyado
JFrog Security Research team

One thing organisations must keep in mind with PHP2Shell is that because this flaw triggers inside the core PHP engine before any application code executes, traditional application-level safeguards won't stop it. Organisations cannot rely on code-level workarounds; automated visibility across all environments – especially identifying legacy or end-of-life PHP installations that won't receive vendor binary updates – is essential to ensuring every endpoint is patched or isolated immediately.