The PHP Security Saga: How Well Do You Really Know Your Software Dependencies?

Name: ISMS.online
Address: Nile House, Nile Street, Brighton, East Sussex, BN1 1HW, GB
Telephone: +441273041140
Price range: ££

By Phil Muncaster • 10 November 2026 • 5 min read

Two critical vulnerabilities in PHP seemed to set the world ablaze when they landed in late October. The incident shone a light on a persistent challenge in the open-source world; one that goes beyond these particular software flaws.

In these situations, the technical fix is usually fairly straightforward. The difficult part is governance: knowing how far dependencies stretch across the organisation, who is responsible for each affected system, and how to handle older versions that may never get patched. Organisations that tackled the governance challenge ahead of time are likely to be those that handled this crisis most effectively. And they’ll be best prepared for those that come after it.

A Tale of Two Vulnerabilities

The two CVEs in question, collectively described as “PHP2Shell”, were described by researchers at Wiz as one of the broadest reaching and most impactful vulnerabilities in recent years, reminiscent of the infamous Heartbleed and Log4j discoveries. With a CVSS score of 9.2 they are:

CVE-2026-109618: an out of memory corruption vulnerability
CVE-2026-109619: a use-after-free bug

They’re almost as bad as it gets, potentially enabling unauthenticated hackers to remotely hijack vulnerable web servers, steal secrets, install web shells or malware, and use them as a stepping stone into other enterprise systems. To make matters worse, PHP is a wildly popular programming language used in around 70% of the world’s websites, including content management systems (CMS) like WordPress, Drupal, Joomla and Magento.

Visibility and Dependency

Many reports have focused on the chaotic vulnerability disclosure process, which made a stressful situation even worse for sysadmins. Others pointed to what the case says about the power of AI to unearth new vulnerabilities. But the biggest challenge for security and IT teams will be to find all the places in their environment that vulnerable and exposed PHP runtimes exist. It could be in a long-forgotten microsite, a legacy server or virtual machine, an internal business application, or even inside a cloud container. Organisations may also own domains and content hosted by third-party partners where PHP is being used.

“From what’s been reported so far, the fix only applies to PHP 8.2-8.5. If you’re running 7.4, 8.0 or 8.1, there’s no patch coming for you,” explains Patrick Münch, chief security officer at Mondoo. “Not today, not later. And those old versions are still all over the place, usually in some internal app a developer built years ago that still works, so nobody wants to touch it.”

Where these versions exist, whether they can be patched, and how big a risk they represent are some of the key questions security teams will be scrambling to work out.

“This is a test of operational resilience, not just patch management,” argues Forrester senior analyst, Madelein van der Hout. “Organisations have to decide whether they can keep services running safely while they respond – and who has the authority to take them offline if they cannot. A temporary shutdown can be the right decision, but it shows how a software vulnerability can become a business disruption even without a confirmed breach.”

Getting Governance Right

Governance is therefore the key discipline here. Organisations need to know

Asset visibility: Can you identify everywhere PHP is being used, including technologies managed by suppliers?
Supplier accountability: If an external provider manages an affected application, do you know who’s responsible for assessing the exposure, patching it and communicating progress?
Business continuity: Who decides whether taking a website or service offline is an acceptable precaution, and what are the consequences?
Risk ownership: Who makes the decision to keep a system running if a patch isn’t immediately available, and what evidence supports that decision?
Assurance: Once the immediate crisis is over, how does the organisation establish that the risk has actually been addressed?

Chris Dimitriadis, chief global strategy officer at ISACA, argues that good governance “could have taken much of the panic out of the patching stampede” that followed the PHP vulnerability disclosures.

“Security starts with knowing what you’re securing. Many organisations only discovered they relied on PHP when the alert was released. A current inventory of assets and dependencies means teams can find their exposure in hours, not weeks,” he tells IO (formerly ISMS.online).

“Ownership is key. Every risk needs a named owner, and everyone involved needs to know their role. Without that clarity, every incident is a surprise that finds the organisation unprepared.”

Ownership must stretch from technical and cyber teams to the board and beyond, Dimitriadis continues.

“With open-source components like PHP, there is often no supplier to hold to account, so responsibility sits with whoever deployed it,” he says. “Where there is a supplier, contracts should set clear expectations on patching and disclosure, and businesses need a way to verify those commitments rather than take them on trust. Continuity plans should already set out how to isolate or replace a service if a fix isn’t immediately available.”

Preparing for the Next Crisis

For many organisations ISO 27001 offers the governance structure that they may have been missing. This can help to establish controls for maintaining accurate asset inventories, assigning clear ownership, continuous risk assessments, and proactive, ongoing vulnerability management, Dimitriadis says. There are also specific controls for monitoring suppliers and maintaining security and IT readiness during disruption, he adds.

“However, a framework is only as strong as the people running it. It works when organisations embed it properly, test it regularly, and have skilled, certified professionals to make that happen,” Dimitriadis concludes.

“Its principles offer a practical starting point for any business that wants to understand its dependencies before the next vulnerability forces the question.”